SG #55

Radar SG55

sg — Thu, 08 Mar 2018 04:53:45 +0000

Radar SG55 sg Wed, 03/07/2018 - 22:53

Publicado en

SG #55

Lo que viene

WebAssembly

Crecientemente, JavaScript ha estado jugando dos roles distintos: uno como lenguaje de programación, y otro como destino de transpilación —es decir, si tienes código en el lenguaje X y quieres ejecutarlo en el navegador, usas un transpilador que “traduce” tu código hacia JavaScript. Como podrás imaginarte, esto no es una solución óptima.

Es por ello que se creó WebAssembly, que consiste en un nuevo formato de código binario que funciona como destino de compilación para otros lenguajes y que puede ser ejecutado por el motor de JavaScript del navegador. La ventaja de tener un formato de código expresamente diseñado con este propósito es que permite optimizarlo extensivamente para que su ejecución sea muy rápida. Así que podrás tener código JavaScript que pueda interactuar de forma transparente con componentes programados en otros lenguajes (por ejemplo C++ o Rust) que tengan muy alto desempeño y aprovechen capacidades de hardware a bajo nivel. Actualmente WebAssembly es soportado en Chrome y Firefox, y se espera que sea soportado en Safari y Edge antes de que termine el año.

https://webassembly.org

.NET Core 2 y .NET Standard 2

Microsoft liberó oficialmente la versión 2 del .NET Core SDK, y de manera conjunta publicó la versión 2.0 de .NET Standard.

Si no te queda claro qué significa esto, te explicamos: En 2016, con el afán de permitir que los desarrolladores pudieran usar el .NET Framework para construir aplicaciones para distintas plataformas, Microsoft decidió soportar distintas implementaciones de .NET, entre ellas el .NET Framework (Windows), .NET Core (cross-platform y open source), y Xamarin (enfocado a móvil). Para facilitar la portabilidad, se definió una capa abstracta llamada .NET Standard que básicamente especifica las APIs que deben ser soportadas a través de las distintas implementaciones de .NET. En un inicio, .NET Standard definía menos de 10 mil APIs (extraídos del .NET Framework en Windows) que debían ser soportados, y esto ha ido creciendo hasta que la versión 2.0 del .NET Standard especifica alrededor de 32 mil APIs.

Después de ese breve contexto, sigamos con los detalles de .NET Core 2. Esta versión agrega soporte de ejecución en nuevas versiones de sistemas operativos tales como Ubuntu 17.04, macOS High Sierra, Fedora 26 y Linux Mint 18. También agrega Visual Basic como lenguaje fuente (limitado a componentes no visuales). Así que si por alguna extraña razón algunas vez has querido programar una biblioteca en Visual Basic para Linux, ya puedes hacerlo.

https://www.microsoft.com/net/core

ARKit

En el WWDC 2017, Apple dio a conocer ARKit, un framework para construir apps de realidad aumentada (AR) para iOS.

La realidad aumentada no es nada nuevo, y es un hecho que Apple viene tarde a la fiesta. Pero en realidad la fiesta todavía no ha comenzado, y todo parece indicar que lo que realmente iniciará la fiesta de AR será ARKit, que es parte de iOS 11 y llegará este otoño.

Mientras que empresas como Google y Microsoft siguen tratando de crear visores sofisticados y/o buscando “killer applications” para AR, Apple está tomando un camino distinto: habilitar a su extensa base de desarrolladores con un framework que les permita fácilmente construir aplicaciones de AR para cientos de millones de dispositivos que ya están en el mercado. ARKit brinda soporte para capacidades tales como detección de movimiento, detección de planos horizontales, estimación de luz y tamaño.

https://developer.apple.com/arkit

LabView NXG

LabView es un ambiente de programación visual hecha por National Instruments para construir sistemas electrónicos. Tiene cerca de 20 años en el mercado y a lo largo de este tiempo ha sido una herramienta de nicho, utilizada principalmente por ingenieros eléctricos para captar y registrar mediciones de instrumentos con alta precisión.

La novedad es que National Instruments está lanzando una nueva generación de esta herramienta, llamada LabView NXG. El objetivo es hacerla mucho más amigable de usar, y con ello poder atraer a personas que no tengan una educación formal en diseño de sistemas electrónicos.

La estrategia tiene bastante sentido, considerando que la necesidad por este tipo de herramientas aumentará conforme las empresas se involucren en proyectos de IoT e internet industrial.

https://ni.com/labviewnxg

Prueba de Software: Lenguajes de Computación

sg — Mon, 21 Aug 2017 21:12:11 +0000

Prueba de Software: Lenguajes de Computación sg Mon, 08/21/2017 - 16:12

Publicado en

SG #55

Prueba de Software

Autor

Ahora que ya cubrimos algunos fundamentos teóricos, podemos abordar aspectos más prácticos que nos ayuden en nuestro objetivo original de obtener elementos para desarrollar lenguajes propietarios de propósito particular que nos ayuden a incrementar nuestra productividad en el desarrollo de software. Doy la bienvenida a Aarón Moreno, con quien estaré escribiendo en los siguientes números.

Todos estamos familiarizados con el concepto de Lenguajes de Programación (LPs) y existe bastate literatura sobre el tema (pueden profundizar en mucho de lo que veremos aquí en cualquier libro sobre “Lenguajes de Programación”). Sin embargo, si buscamos incrementar nuestra productividad deberíamos abrir nuestra panorámica y considerar no solo los LPs, sino lo que llamaremos aquí “Lenguajes de Computación” (LCs), concepto que incluye los LPs, pero también los Lenguajes de Documentación (como LaTeX y HTML), de Arquitectura (como ABACUS y CBabel), de Especificación (v.gr. de sanners/parsers como lex/YACC), de Documentación de Procesos (como XPDL y JPDL), y para la Prueba (como LoadRunner y Selenium), entre otros; desarrollar lenguajes propietarios para estas áreas también puede incrementar nuestra productividad. (El tema de este número es “El auto como plataforma de software”; el pasado marzo estuvimos en el CeBIT –exposición tecnológica en Alemania, tal vez la más grande del mundo–, y en ella se mostraron avances en el sector automotriz que por supuesto implican LCs de propósito particular para ese sector.)

Los LCs (y los LPs en particular) se desarrollan a lo largo de un proceso de sistematización–formalización–automatización durante el cual se va conociendo mejor el área para la cual se diseña el lenguaje (el “Application Domain”).

Procedamos a abordar nuestro tema apoyándonos en el desarrollo histórico de los LPs, lenguajes por antonomasia entre los LCs.

Lenguajes de Programación (LPs)

Cuando los LPs son de propósito general (general purpose languages) tienen constructos que son comunes a muchos otros LPs, tales como mecanismos de secuenciación, alternación y repetición de instrucciones, definidos en el marco de lo que llamamos un Sistema de Control (Control System); y mecanismos de composición de tipos, definidos en el marco de un Sistema de Tipos (Type System). Cuando los LPs son de propósito particular (special purpose languages) tienen además una parte diseñada especialmente para abordar más efectivamente problemas del Dominio de Aplicación, como tipos de datos y estructuras de control ad hoc (v.gr. si el dominio fuera la Matemática, el LP podría tener construcciones y operaciones sobre matrices, entre otras cosas).

Hoy tenemos LPs incluso para programar videojuegos. Sin embargo, la inquietud que nos llevó a tener LPs no era generar una industria de entretenimiento, ni siquiera una industria de software. Los trabajos sobre los que finalmente se basa esta tecnología fueron principalmente de lógicos-matemáticos-filósofos que querían construir máquinas que pensaran… o “calcularan” (en el sentido lógico-matemático) como decía Leibniz (que por cierto, es lo que aún se busca, varios siglos después).

El Sistema de Control

La estructura del Sistema de Control está fuertemente influenciada por el paradigma con el que fue desarrollado el LP (ver sección “Paradigmas” más adelante), pero podemos hablar en general de constructos (o “abstracciones”) como los descritos en la siguiente tabla.

Abstracciones de Control

Primitivas

Compuestas

De Unidad

Instrucciones simples como:

goto’s,
return’s,
Asignaciones
Llamadas a

subrutinas o macros

Instrucciones definidas en términos de otras instrucciones, en particular para construir…

Altenación: if’s, switch’s
Repetición: while’s, for’s
Secuenciación: bloques begin – end
Bloques de instrucciones en forma de subrutinas (procedimientos, funciones, módulos, etc.) o clases

Mecanismos para almacenar, en archivos distintos y utilizando mecanismos como include’s, uses’, y sees’, segmentos de código con operaciones relacionadas entre sí bajo algún criterio (“librerías”, clases o Abstract Data Types )

El Sistema de Tipos

La estructura del Sistema de Tipos también está influenciada por el paradigma del LP, pero podemos igualmente hablar en general de construcciones (o “abstracciones”) como las descritas en la siguiente tabla.

Abstracciones de Datos

Primitivas

Compuestas

De Unidad

Tipos de datos básicos (y predefinidos) como:

Ordinales: char, int, boolean, enumerated
Continuos: real (con distintas precisiones)
Apuntadores
“Tipo nulo” o “comodín” (como el void de C)
Rangos
Archivos

Tipos de datos definidos en términos de otros tipos utilizando Constructores de Tipos como los siguientes:

Registros (“clásicos” o variables)
Conjuntos
Secuencias (v.gr. arreglos y strings)
Tipos no lineales (v.gr. listas, árboles y grafos)
Clases

Mecanismos para almacenar, en archivos distintos, segmentos de código con declaraciones/ definiciones de datos y de tipos de dato relacionados entre sí bajo algún criterio (incluyendo clases y Abstract Data Types) utilizando mecanismos como include’s, uses’, y sees’

El diseño del Sistema de Tipos es una actividad en sí misma por su complejidad y relevancia (define elementos vitales de la semántica del lenguaje).

La definición del Sistema de Tipos incluye cuestiones muy importantes como las siguientes:

Chequeo de tipos: Distinguimos entre strongly-typedy weakly-typed languages, dependiendo de la menor o mayor tolerancia a que a las variables de un programa no se les haya asociado explícitamente un tipo de dato. Si el chequeo de esta asociación se realiza en tiempo de compilación hablamos de statically-checked languages; si ocurre en tiempo de ejecución hablamos de dynamically-checked languages.
Equivalencia de tipos: Se definen criterios para determinar cuándo se considera que dos variables tienen el mismo tipo, aunque eventualmente hayan sido declaradas de manera distinta. Algunas alternativas son:

Declaration Equivalence: dos variables tienen tipos equivalentes cuando remiten a la misma declaración de tipo.
Name Equivalence: dos variables tienen tipos equivalentes si fueron declaradas usando el mismo nombre de tipo en el mismo ámbito (scope).
Structural Equivalence: dos variables tienen tipos equivalentes si fueron definidas partiendo de los mismos tipos básicos y utilizando los mismos constructores de tipos.

Conversión de tipos: Para combinar variables de varios tipos se aplican mecanismos como los siguientes:

Conversión implícita (promotion): como cuando una variable entera es convertida automáticamente a real por aparecer en una expresión real.
Conversión explícita (casting): la que realiza el programador ya sea mediante la utilización de funciones predefinidas, o utilizando facilidades del lenguaje para “asignar tipos”, como el conocido casting.
Generalización de un tipo de una variable a un tipo genérico, como el void del lenguaje C.

Inferencia de Tipos: Permite deducir el tipo adecuado de v.gr. una subexpresión dentro de una expresión. Es particularmente importante en los weakly-typed languages; el conocido mecanismo de Unificación juega aquí un papel importante.

Clasificaciones de Lenguajes de Programación

Una manera de ganar perspectiva es mediante una clasificación, pero una taxonomía presupone criterios bajo los cuales clasificar. Para los LP podríamos tomar alguno(s) de los siguientes:

Su aspecto ante el programador, lo que permite v.gr. distinguir entre lenguajes visuales y textuales.
Su “composición estructural” (y la complejidad de procesar cada lenguaje), lo cual es el origen de jerarquías como la Jerarquía de Lenguajes de Chomsky.
El “marco conceptual” detrás de los programas que se escriben en un lenguaje particular, lo que facilita la clasificación en Paradigmas de LPs.
El “origen cronológico” en el que fueron creados, lo que da pie al concepto de Generaciones de LPs.

Vamos a poner en perspectiva algunos LPs relevantes considerando los 2 últimos criterios (ver figura más adelante).

Paradigmas

La primera división usual en términos de paradigmas es la distinción entre lenguajes procedurales y no-procedurales. En los primeros, el programador debe especificar con precisión cómo debe ejecutarse la solución; en los segundos se busca que más bien se especifique qué es lo que debe solucionarse.

Dentro de los Lenguajes Procedurales tenemos los lenguajes no-estructurados, los estructurados, y losorientados a objetos, que fueron desarrollándose más o menos en ese orden. Podemos observar un incremento en la estructura que se le fue imponiendo al programador para accesar los datos y para escribir (bloques de) instrucciones:

En los Lenguajes no-Estructurados el programador tenía amplia libertad –aunque no muchas facilidades– para definir datos y manipularlos como y donde le pareciera mejor; tenía también mucha libertad para escribir instrucciones de salto (los famosos goto’s o sus equivalentes), incluso del interior de un bloque de instrucciones al interior de otro.

Esta libertad, o mejor dicho, esta falta de estructura al escribir instrucciones y definiciones de datos (que generaba lo que suele llamarse “código spaghetti”) comenzó a causar grandes problemas en el desarrollo de software. (Ya en 1968, en la First Software Engineering Conference de la OTAN, personalidades de los medios académico e industrial dejaron ver que una “Crisis del Software” era patente. En esa misma reunión se acuñó el término “Software Engineering”.)

Los Lenguajes Estructurados ofrecen un Sistema de Tipos con tipos básicos y constructores para especificar de manera sistemática tipos compuestos a partir de los básicos. Ofrecen también un conjunto de instrucciones básicas y mecanismos para agruparlas y formar instrucciones (o bloques de instrucciones) compuestas que pueden ejecutarse solo de una manera: comenzando en su único punto de inicio y terminando en su único punto de cierre (Single-Entry, Single-Exit), sin permitir que a través de instrucciones goto (o sus equivalentes) la ejecución del programa salte del interior de una instrucción al interior de otra.
En los Lenguajes Orientados a Objetos ya no se especifica solamente la definición de datos estructurados, sino que se vinculan esos datos con las operaciones (secuencias de instrucciones) válidas aplicables a los mismos. Ya no se puede entonces aplicar una operación cualquiera sobre los datos, sino que debe ser una de las explícitamente vinculadas a éstos.

Los Lenguajes no-Procedurales, por su parte, suelen clasificarse en lenguajes declarativos y lenguajes aplicativos. Suelen ser altamente expresivos (ver sección “Criterios de Diseño” más adelante), weakly-typed y dynamically-checked, y en ellos tanto los datos como los programas suelen tener una representación uniforme común, todo lo cual los hace aptos para el desarrollo de prototipos:

En los Lenguajes Declarativos (llamados también Lenguajes Lógicos), el qué debe hacer la computadora se suele especificar en términos de conjunciones, disyunciones, negaciones, e implicaciones lógicas. La repetición del equivalente a las “instrucciones” suele realizarse mediante de recursión.
En los Lenguajes Aplicativos (llamados también Lenguajes Funcionales), la especificación de la solución se hace en términos de procesos llamados funciones (asemejando las utilizadas en las matemáticas). Una representación común para datos y programas son las listas (como en LISP, lenguaje prototipotípico de este paradigma), y usualmente tienen la recursión como un mecanismo de repetición.

Generaciones

Utilizando esta clasificación, los LPs se suelen agrupar como sigue:

La 1ª Generación de LPs la componen los primeros lenguajes de bajo nivel (low-level Languages) como los lenguajes ensambladores y los “lenguajes máquina”.

Los primeros programas de software fueron escritos en lenguaje máquina. La inserción de una nueva instrucción podía requerir tener que revisar manualmente el programa completo, lo cual motivó el desarrollo de Ensambladores Simbólicos, que hacían actualización automática de referencias y permitían utilizar nemónicos en lugar de códigos de operación de instrucciones. Los posteriores Procesadores de Macros fueron más allá y permitieron que un solo símbolo fuera sustituido por una secuencia de instrucciones.

La 2ª Generación la conforman los primeros lenguajes de alto nivel (high-level Languages) de propósito general (general purpose Languages) (aunque prácticamente solo se usaban en la ciencia). Para desarrollarlos se habían detectado patrones de construcciones comunes, como la evaluación de expresiones aritmético-algebraicas, el llamado a subrutinas, y las instrucciones de alternación (como el “if”) y de repetición (como el “while”).

La 3ª Generación incluye lenguajes de propósito general de alto nivel estructurados, en los que solo se permiten instrucciones estructuradas (Single-Entry, Single-Exit) y no instrucciones goto. Para desarrollarlos se habían detectado también patrones en el uso de datos, que condujeron al desarrollo de Sistema de Tipos que incluían tipos básicos y constructores de tipos. Vino la introducción de módulos, que permitió “aislar” subrutinas y tipos de datos para impedir su modificación, y proveer solamente interfaces para el uso de los mismos a (el resto de) los programadores.

Con la 4ª Generación se asocian lenguajes de propósito particular(special purpose Languages), diseñados para realizar con facilidad tareas en un área de aplicación específica (como lenguajes para Manejadores de Bases de Datos (SQL) y para desarrollar Compiladores (lex/YACC)). Suelen tener constructos no-procedurales.

Con la 5ª Generación se asocian lenguajes de muy alto nivel (very high-level Languages), que fueron utilizados principalmente en la Inteligencia Artificial “clásica” (no en la “nouvelle AI” actual) para hacer por ejemplo Procesamiento de Lenguaje Natural o Razonamiento Automático, y para desarrollar Sistemas Expertos. Se trata de LPs escencialmente no-procedurales. En esta generación renació un interés por continuar los trabajos procedentes del Paradigma Funcional.

Desarrollo histórico

Muy probablemente habrán visto en una de las columnas de Hanna Oktaba la ilustración de lo que el autor podría llamar “La Torre de Babel de los LPs”. Y es que a lo largo del tiempo se han desarrollado muchos LPs.

Aquí listamos descripciones breves sólo de aquellos LPs que han tenido gran relevancia en el desarrollo de la informática (ver figura de arriba), y que sentaron las bases para LPs posteriores hasta llegar a los utilizados en la actualidad (Java, .net, PHP, HTML, Delphi, C y C++, así como scripting languages).

FORTRAN (FORmula TRANslation) fue desarrollado en la IBM (1957) por un grupo encabezado por John Backus. Uno de los criterios más importantes para su implantación fue la eficiencia del código generado por el compilador. FORTRAN “introdujo”, entre otras cosas, los arreglos, la instrucción de alternación “if”, y los ciclos controlados por una variable indexada. Los programas debían escribirse con un formato léxico fijo (fixed-format), en el cual v.gr. ciertas cosas tenían que escribirse en columnas preestablecidas.
Plankalkül (“Cálculo de Planes”) fue en los hechos el primer LP de alto nivel. Fue desarrollado (1944) por el alemán Konrad Zuse para la Z3, primera computadora programable moderna, desarrollada también por él (1941). Plankalkül incluía, entre otros constructos: instrucciones de asignación, condicionales e iterativas; subrutinas; aritmética de punto flotante; manejo de excepciones; arreglos, registros y grafos. El diseño de Plankalkül estuvo influenciado por los trabajos en lógica matemática de Gottlob Frege (de finales del siglo XIX), y los de éste por los de Leibniz (de finales del siglo XVII).

LISP (LISt Processor) fue diseñado en el Massachussets Institute of Technology (MIT) por John McCarthy (1958). A LISP se le considera el LP funcional por excelencia. Su diseño se basó en la idea de la aplicación de funciones como noción fundamental de cómputo, y estuvo influenciado por los trabajos en el Cálculo Lambda de Alonzo Church. Introdujo conceptos como árboles (las estructuras de datos), dynamic Typing, Funciones de Orden Superior, Recursión, linked lists, el método “Garbage Collection” para recuperar de manera automática la memoria que los programas ya no utilizaban, así como las S-Expressions (Symbolic-Expressions), que son constructos con los cuales se expresan tanto los datos como los programas, lo cual permite a los programadores agregar nuevos elementos sintácticos al lenguaje y crear ligeras variantes del mismo.

COBOL (COmmon Business Oriented Language) fue desarrollado en el Department of Defense de los EEUU (1960). Es quizás aún el lenguaje de programación más utilizado. Introdujo la estructura registro, la idea de separar los datos del programa colocándolos en secciones diferentes, y el formateo de la impresión en pantalla usando pictures. Los programas podían escribirse sin un fixed-format. Un criterio para su diseño fue que su sintaxis fuera English-like, lo que lo hace, en no pocos casos, caer en descripciones con exceso de palabras.

ALGOL-60 (ALGOrithmic Language) fue desarrollado por un comité (1960). Tuvo una enorme influencia en el desarrollo posterior de los lenguajes de programación. Introdujo instrucciones estructuradas(“single-entry, single-exit”), declaraciones de tipos, paso de parámetros por valor, y fue el primer lenguaje en el que se utilizó BNF (Backus-Naur Form) para definir la sintaxis.
BASIC (Beginners All-purpose Symbolic Instruction Code) fue desarrollado por John G. Kemeny and Thomas E. Kurtz en el Dartmouth College, EEUU (1964), para hacer accesible la programación a estudiantes (no solo a científicos). Ha sido el primer lenguaje de muchos programadores.
Simula-I (principios de los 60’s). Introdujo el concepto de clase y se le considera el primer lenguaje de programación orientado a objetos.

Pascal fue diseñado por el suizo Niklaus Wirth (1969), destilando ideas de ALGOL-60 en un lenguaje pequeño, simple y estructurado. Fue muy utilizado.

C fue desarrollado por Dennis Ritchie en los Bell Labs (1972), con el objetivo de crear un lenguaje sencillo, reduciendo la complejidad del Sistema de Tipos y el ambiente de tiempo de ejecución (run-time environment). Es muy portable y ofrece grandes facilidades para accesar directamente los dispositivos de la computadora, lo que lo hace apto para el desarrollo de sistemas (que incluyen hardware).

PROLOG (PROgramming in LOGic) fue desarrollado por un grupo en Marsella dirigido por A. Colmerauer (comenzando en 1972). Se trata fundamentalmente de un demostrador de teoremas. Se ha utilizado para hacer procesamiento de lenguaje natural y razonamiento automático, y fue escogido por los japoneses para su Proyecto de 5ª Generación de Computadoras.

Scheme es un dialecto de LISP desarrollado en el MIT (1978).

Smalltalk fue desarrollado en Xerox Corporation’s Palo Alto Research Center (1972-1980) para aplicar el enfoque orientado a objetos en una forma completamente consistente. Se le considera el ejemplo más puro de un lenguaje orientado a objetos.

Criterios de Diseño

Ahora bien, cuando diseñamos un LC, debemos considerar los objetivos que se persiguen con él. Tomando en cuenta eso y que el lenguaje propietario que queremos desarrollar muy probablemente no generará código objeto sino código en el LP de alto nivel que ahora utilizamos para desarrollar software, describimos enseguida varias características que podrían ser deseables en el diseño de nuestro lenguaje propietario.

Simplicidad

Este criterio está vinculado con la Legibilidad: a mayor simplicidad, mayor legibilidad. La simplicidad facilta el uso del lenguaje; sin embargo, hay que considerar que "Everything should be made as simple as possible, but not simpler", pues la sobresimplificación hace engorroso el uso del lenguaje, le resta Expresividad, y lo deja sujeto a muchas restricciones. Las características de Generalidad, Ortogonalidad y Uniformidad conllevan frecuentemente a una disminución de la Simplicidad.

Ejemplos:

BASIC: La falta de constructos fundamentales, como declaraciones y bloques, hace más difícil la programación de aplicaciones grandes.
LISP, PROLOG: pocos constructos básicos facilitan las cosas, pero se depende de un sistema de ejecución complejo.

Legibilidad

Facilidad con la que alguien no-experto puede leer programas escritos en ese lenguaje y entenderlos. Tiene relación con lo que llamaríamos Mantenibilidad, que es la facilidad con la que puede modificarse un programa (v.gr. detectar y corregir errores, y agregar funcionalidad).

Expresividad

Facilidad con la cual, escribiendo poco código, se pueden expresar procesos y estructuras complejos.

Esto es muy claro cuando comparamos un lenguaje de alto nivel con uno de bajo nivel, pero aquí hay otros Ejemplos:

La posibilidad de utilizar recursión permite resolver ciertos problemas con pocas instrucciones.
En LISP, durante la ejecución de un programa, se pueden modificar no solo los datos sino también el programa mismo.

La Expresividad puede entrar en conflicto con la Simplicidad, como por Ejemplo:

PROLOG es muy expresivo, pero no simple.
C es expresivo, pero instrucciones como while ( *s++ = *t++ ) no son tan fáciles de entender para un novato.

Generalidad

Facilidad para combinar constructos estrechamente relacionados en uno solo más general, sin necesidad de casos especiales.

Ejemplos:

Pascal tiene declaración de procedimientos y paso de procedimientos como parámetros, pero no tiene variables que tomen procedimientos como valores.
En Pascal el operador de comparación " = " puede ser aplicado solamente a escalares, apuntadores y conjuntos, pero no a arreglos y registros.

Ortogonalidad

Permite que los constructos del lenguaje puedan ser combinados de cualquier manera que haga sentido, pero al mismo tiempo impide que la interacción entre diferentes constructos, o el contexto en que se están usando, causen restricciones o comportamientos inesperados o inadecuados.

Ejemplos:

En C una función puede retornar valores de cualquier tipo de datos excepto arreglos.
En C se pueden pasar todos los parámetros por valor, excepto los arreglos, que deben pasarse por referencia.

Uniformidad

Consistencia en la apariencia y comportamiento de los constructos del lenguaje:

Evitar que cosas no similares se vean o se comporten de manera similar.
Evitar que cosas similares se vean o comporten de manera distinta.

Ejemplos:

En Pascal el constructo repeat–until abre y cierra un bloque de instrucciones, mientras que las instrucciones 'while' e 'if' requieren de pares 'begin' - 'end’.
En Pascal se utiliza ";" para separar instrucciones, pero también para terminar una declaración.

Extensibilidad

Existencia de un mecanismo general que permita al programador añadir nuevas características al lenguaje. (No se consideran extensiones la definición de nuevos tipos de datos, ni la definición de funciones nuevas en una librería.)

Ejemplo:

Añadir nuevas palabras clave y constructos (como matrices, números complejos, etc.). LISP v.gr., permite extender su sintaxis.

Continuamos en la siguiente columna!

Bio

Aarón Moreno Monroy es Director de Operaciones y co-fundador de e-Quallity. Fue profesor de asignatura de la Universidad ITESO. Estudió su maestría en el CINVESTAV; su trabajo de tesis tuvo que ver con verificación formal, la cual aborda la prueba de software utilizando modelos matemáticos.

Adquisición y Análisis de Datos en el STC Metro

sg — Mon, 21 Aug 2017 21:04:17 +0000

Adquisición y Análisis de Datos en el STC Metro

sg Mon, 08/21/2017 - 16:04

Publicado en

SG #55

Caso de Estudio

Autor

Liliana Toledo

La adquisición y análisis de datos cobra especial interés en un mundo que se dirige a la digitalización. Para lograr esto, las señales análogas deben ser capturadas, purificadas de ruido y acondicionadas rápidamente para ser de utilidad. El Sistema de Transporte Colectivo Metro es una de tantas organizaciones que enfrenta este reto de digitalización. En este artículo compartimos el caso de un proyecto realizado recientemente por esta organización.

Contexto

El STC se construyó hace más de cuarenta años con tecnología de punta de esos momentos. Cuatro décadas después, darle mantenimiento a este sistema para que pueda atender a más de 5 millones de usuarios diarios, tiene diversas complicaciones. Una de ellas surge de que la mayoría de los componentes electrónicos en los vagones utilizan tecnología vieja que ya no es soportada.

Tal es el caso de los equipos de tracción que utilizan más de 17 mil tarjetas electrónicas para controlar el movimiento de los más de 150 trenes. Aunque los vagones siguen funcionando bien, los escáneres de lógica de tracción se diseñaron con microcontroladores antiguos que después de tantos años presentan fallas de cableado y dejan de funcionar. Al solicitar nuevos equipos al proveedor comentó que ya no soportaba esa tecnología y la única opción era comprar vagones nuevos.

Solución

A través de una colaboración con el Centro de Ingeniería y Desarrollo Industrial (CIDESI) con sede en Querétaro, se estableció el Laboratorio de Electrónica Digital Avanzada (LEDA), que homologa las comunicaciones de este medio de transporte en un formato de electrónica digital. CIDESI se encarga principalmente de implementar tecnología para adquisición y análisis de datos, mientras que el personal de STC aporta su profundo conocimiento de los trenes y operación.

Uno de los proyectos derivados de esta iniciativa fue la actualización del sistema de diagnóstico de las tarjetas de potencia. Anteriormente, este era un procedimiento lento y complicado en el que las señales analógicas de voltaje y/o corriente eran sometidas a diversos sistemas separados de prueba que incluían osciloscopio, fuente, generador, etcétera. Cada uno entregaba diferentes gráficas y en base a ellas los técnicos diagnosticaban las reparaciones requeridas.

El sistema de pruebas ahora se basa en una plataforma de software a la que se conectan tarjetas de adquisición de datos y las tarjetas de tracción. Lo más interesante es que, a través de la plataforma, se pueden simular las condiciones de uso real de los trenes y con ello extraer los datos correctos para hacer el diagnóstico. El sistema de pruebas consta de dos etapas. La primer etapa consiste en obtener una señal analógica, limpiarla y digitalizarla. En la segunda etapa, la plataforma trabaja con esta señal digital para inyectar señales que simulan el comportamiento de un tren en movimiento. Ya con los resultados de la simulación, el técnico determina que área de la tarjeta de tracción es la que presenta problemas.

Beneficios

Sergio Guevara, laboratorista del STC, nos comenta que el nuevo sistema ha cuadruplicado su capacidad para diagnosticar tarjetas. Adicionalmente, el nuevo sistema disminuye significativamente la curva de aprendizaje de los técnicos y operarios, ya que es mucho más amigable.

Otra ventaja consiste en que el conocimiento para diagnosticar las tarjetas ya no solo está en la mente de los técnicos que trabajan en STC por muchos años y que al jubilarse o cambiar de empleo se pierde, sino que ahora también reside en una plataforma que permite tener esa información siempre disponible.

Después de este proyecto, se han hecho otras evoluciones tecnológicas dentro de STC, la mayoría basada en software, como por ejemplo, las pruebas de los pilotos automáticos de los trenes.

El Sistema de Transporte Colectivo se incorpora de esta forma a la era moderna de la adquisición y análisis de datos, teniendo como misión, dentro de su recién inaugurado Laboratorio de Electrónica Digital Avanzada, seguir evolucionando conforme el metro lo requiera.

Bio

Liliana Toledo Rivera (@lilitoledo_), egresada de la Ingeniería de Comunicaciones y Electrónica por la Universidad de Guadalajara; dentro de su multifacética ruta profesional es periodista de ciencia y tecnología en diversos medios.

Los 6 Niveles de Autonomía

sg — Mon, 21 Aug 2017 21:02:28 +0000

Los 6 Niveles de Autonomía

sg Mon, 08/21/2017 - 16:02

Publicado en

SG #55

Autor

Pedro Galván

“Esta empresa ya tiene vehículos con nivel 3 autonomía, y se espera que antes del año 2020 lance vehículos nivel 4.”

¿Alguna vez has leído o escuchado una frase similar, donde se hable de niveles de autonomía en los vehículos? Si no te ha sucedido, pronto sucederá. Así que es buena idea de una vez entender a qué se refiere eso de los niveles de autonomía.

A continuación comparto una guía que explica qué significa cada nivel, desde el nivel 0 donde el humano hace todo hasta el nivel 5 que es completamente autónomo.

La escala de niveles de autonomía fue publicada originalmente por la Society of Automotive Engineers (SAE) en el año 2014 como parte de su reporte “Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Systems". El reporte describe un mapa de ruta en el que los fabricantes de vehículos se están basando para desarrollar las capacidades de sus vehículos autónomos. En Estados Unidos, la National Highway Traffic Safety Administration (NHTSA) había ya creado su propia escala en 2013 sin embargo en septiembre de 2016 decidió descartarla y adoptar la escala de SAE como estándar.

A continuación describo los distintos niveles de la escala SAE

Nivel 0: Sin asistencia

Este es el nivel inicial, en el que no hay asistencia y por lo tanto el conductor realiza todas las tareas (acelerar, frenar, girar) en todo momento. Es posible que el automóvil tenga sistemas de notificación al detectar eventos u objetos, pero aún así el conductor tiene el control completo. La mayoría de los automóviles en las calles actualmente se encuentran en este nivel.

Nivel 1: Conducción asistida

Estos automóviles pueden tener uno o más sistemas que controlen la velocidad o la dirección, pero no ambos al mismo tiempo. Por ejemplo, algunos automóviles modernos cuentan con piloto automático adaptativo (que acelera o frena de forma automática dependiendo del tráfico), que es un ejemplo de una capacidad de nivel 1. Otro ejemplo son los sistemas con control de carril, que automáticamente evita que un automóvil se salga de su carril. En resumen, el conductor sigue controlando el carro y debe mantener las manos en el volante, pero recibe asistencia para escenarios específicos.

Nivel 2: Autonomía parcial

Un vehículo nivel 2 tiene capacidad de tomar el control tanto de la dirección como de la aceleración y frenado, pero solo bajo ciertas condiciones y por periodos cortos de tiempo (típicamente menos de un minuto). Aunque el automóvil se está conduciendo solo, el conductor debe estar detrás del volante y atento para tomar el control en cualquier momento. Tesla Autopilot ha estado en este nivel desde hace un par de años, aunque ya otras marcas tienen en el mercado automóviles con capacidades similares.

Nivel 3: Autonomía condicional

En el nivel 3 el automóvil ya se puede conducir solo en la mayoría de las situaciones y por periodos extendidos de tiempo, pero al igual que en el nivel 2 se requiere que un conductor humano esté detrás del volante por si el automóvil no sabe qué hacer en alguna situación y necesita ceder control al conductor. El problema con este nivel es desde la perspectiva legal, ya que en caso de algún accidente no está claro qué tanta responsabilidad tendría el conductor; es por ello que algunas empresas planean saltarse este nivel.

Nivel 4: Alta autonomía

Un automóvil con autonomía nivel 4 se conduce por sí solo y sin necesidad de que una persona esté al pendiente. En caso de que el automóvil se encuentre ante una situación en la que no pueda conducirse —por ejemplo durante una tormenta donde se reduzca significativamente la visibilidad—, busca un lugar seguro donde detenerse y espera a que se resuelva la situación o el pasajero le provea información adicional. Un automóvil nivel 4 no necesariamente cuenta con controles para conducción manual.

Algunas empresas ya tienen prototipos con autonomía nivel 4 —tal es el caso de Waymo (Google)—, y en el caso del Modelo S de Tesla ya cuenta con todo el hardware necesario, pero las computadoras a bordo todavía están recopilando horas de manejo para entrenar los algoritmos de conducción autónoma; una vez que se cuente con suficiente entrenamiento se activará en los automóviles este nivel de autonomía. Otras marcas como Ford y Volvo han anunciado que planean tener disponibles autos nivel 4 a más tardar en el año 2021.

Nivel 5: Autonomía completa

En este nivel el automóvil se conduce por sí solo en todos los escenarios, incluso los más extremos. Aunque el paso entre nivel 4 y 5 parece pequeño, en realidad involucra superar una gran cantidad de retos técnicos para poder satisfacer todos los escenarios. Es por ello que ninguna empresa ha hecho compromisos para tener automóviles nivel 5 en menos de siete años.

Referencia

https://www.sae.org/misc/pdfs/automated_driving.pdf

Bio

Pedro Galván es cofundador y director editorial de Software Guru.

Deep Learning y Vehículos Autónomos

sg — Mon, 21 Aug 2017 20:49:58 +0000

Deep Learning y Vehículos Autónomos

sg Mon, 08/21/2017 - 15:49

Publicado en

SG #55

Autor

Gary Silberg

Piensa en todas las tareas que tu cerebro ha hecho mientras conduciste tu automóvil al trabajo esta mañana. Viste 235 letreros, 12 bicicletas, 20 peatones y 1,376 automóviles. Aceleraste, frenaste, diste vuelta y cambiaste de carriles.

Ahora imagina escribir un programa que pudiera conducir a un automóvil en ese mismo viaje que hiciste. Probablemente requeriría miles de millones de líneas de código.

Parece imposible, pero hacia allá vamos. El aprendizaje profundo (deep learning), una forma de inteligencia artificial, está llegando al punto de poder conducir automóviles de forma autónoma y en cualquier tipo de condición.

¿Qué es el aprendizaje profundo?

Aunque no lo sepas, seguramente ya has estado expuesto a aplicaciones de aprendizaje profundo. Es lo que hace que Siri pueda responder a tus preguntas, Google lo usa para encontrar los resultados que buscas, y Amazon para recomendarte un producto. En el ámbito automotriz, el aprendizaje profundo permite que los ingenieros no tengan que programar cada uno de los eventos y acciones posibles que se darían en un trayecto. En lugar de esto, la computadora recopila experiencias y a partir de estos datos genera deducciones para la toma de decisiones.

El sistema de aprendizaje de un automóvil autónomo trabaja aprendiendo a detectar objetos y patrones de forma automática. Conforme se le alimentan más datos va aumentando su precisión. El sistema es entrenado por medio de repetición, continuamente recibiendo datos de entrada y optimizando su habilidad para realizar predicciones sobre qué significan los datos y qué hacer con ellos. Al desplegar un sistema de este tipo a través de una flotilla de vehículos, la flotilla entera se beneficia del conocimiento colectivo generado por cada uno de los vehículos. Cuando un automóvil encuentra algo nuevo —por ejemplo un camino no mapeado o una acción no contemplada por parte de otro automóvil— envía la experiencia al sistema de aprendizaje, éste la analiza y envía el aprendizaje a toda la flotilla.

De esta manera, el aprendizaje profundo tiene la capacidad de resolver uno de los principales retos de la conducción autónoma: lidiar con lo impredecible. Sería prácticamente imposible que ingenieros humanos programaran manualmente algoritmos para expresar de forma adecuada todos los escenarios posibles al manejar.

El aprendizaje profundo ya es utilizado para habilitar capacidades de conducción autónoma en automóviles comerciales. Por ejemplo, el sistema de cámaras del Audi A7 utiliza aprendizaje profundo para reconocer señales de tráfico. El sistema Autopilot de Tesla también lo utiliza, y aunque el Modelo S ya tiene todo el equipo necesario para conducción autónoma, por el momento se encuentra recopilando experiencias de los automóviles en las calles y aprendiendo, para que cuando se determine que ha aprendido lo suficiente se pueda activar la conducción autónoma de niveles superiores.

Hacia el futuro, la mayoría de las empresas automotrices han anunciado que planear tener vehículos autónomos en el mercado alrededor del año 2020. En un principio estos vehículos estarán restringidos a ambientes sencillos y bien mapeados, pero eventualmente serán capaces de llevarnos a cualquier lugar sin importar las condiciones.

Técnica 1: abstracción semántica

Existen dos grandes técnicas para aplicar el aprendizaje profundo a la conducción autónoma: abstracción semántica, y aprendizaje de punta a punta.

La abstracción semántica se enfoca en dividir el problema en distintos componentes. Por ejemplo, un componente se dedica a detectar vehículos, otro componente detecta carriles, otro más detecta qué hay más allá del carril (otros automóviles, banqueta, barrera). Utilizando conocimiento previo, los ingenieros de software entrenan cada componente individual etiquetando o anotando imágenes para identificar su significado en el mundo real.

Una vez que cada uno de los componentes ha dominado su tarea, los distintos componentes comparten datos para que puedan colaborar y decidir cómo controlar el vehículo. Es decir, una vez que el componente de detección de vehículos sabe dónde están los vehículos, y el componente de detección de carriles sabe dónde están los carriles, y el componente de detección de fronteras sabe dónde está la banqueta, combinan este conocimiento con muchos otros datos aportados por otros componentes. La computadora maestra entonces decide qué trayectoria tomar y cuál es la velocidad adecuada para realizar la maniobra de manera segura.

Ventajas:

Menor tolerancia a fallas. Antes de que la red sea descargada a un vehículo autónomo activo, los algoritmos responsables de cada componente son entrenados de forma independiente hasta que cada uno tenga un alto nivel de precisión en su tarea.
Facilita detectar errores. En caso de que haya una falla —el automóvil toma una decisión incorrecta— los ingenieros pueden detectar qué componente provocó el error y corregirlo.
Mayor capacidad para lidiar con lo impredecible: El sistema ha sido alimentado previamente con datos etiquetados que lo ayudan a adaptarse a situaciones inusuales. Por ejemplo, si de pronto un niño cruza la calle persiguiendo una pelota, el sistema sabe que el niño es una persona, cómo se comportará y cómo evitar golpearlo.

Desventajas:

Se requiere mucho trabajo previo. Antes de que el sistema esté disponible el equipo de ingenieros debe diseñar una red de conocimiento y codificar algoritmos para cada componente. Posteriormente tiene que entrenar cada componente por medio de etiquetar meticulosamente grandes cantidades de datos, lo cual requiere mucho tiempo y esfuerzo.
Típicamente se etiqueta más información de la necesaria. Dado que se busca cubrir de forma anticipada todos los escenarios posibles es necesario etiquetar una gran cantidad de datos y al final muchos de ellos serán redundantes, por lo que hay un desperdicio en el esfuerzo.

Técnica 2: aprendizaje de punta a punta

El aprendizaje de punta a punta (end-to-end learning) es una técnica más disruptiva en la que el aprendizaje se realiza de forma automática por medio de captar y analizar experiencias reales de manejo. En vez de dividir la conducción en distintos aspectos y entrenar componentes por separado, el sistema opera de forma holística a través del conjunto de datos completo, sin enfocarse en detectar eventos en componentes individuales.

Ventajas

Al ser alimentado con big data, el sistema puede clasificarlos sin necesidad de que los datos estén previamente etiquetados. El sistema no necesita que previamente se le diga qué es un vehículo o cómo se ve un carril, sino que toma las entradas de datos y automáticamente clasifica los objetos y situaciones conforme los va experimentando. Esto significa que los ingenieros no necesitan predefinir o preprogramar todos los componentes que se conjuntan para conducir.
Conforme hay más datos sobre distintas situaciones, el sistema se hace más robusto. Las empresas automotrices pueden aprovechar el poder de su flotilla para rápidamente captar millones de horas de experiencia.
Se optimiza considerando el proceso completo. Los algoritmos internos son optimizados teniendo en consideración el desempeño del sistema completo, no de componentes individuales (como por ejemplo detectar carriles). Esto puede llevar a sistemas con mejor desempeño, que resuelvan las tareas usando el mínimo de pasos necesarios.

Desventajas

Se requiere capturar cantidades de datos enormes. Como ya comentamos, en el caso de los automóviles esto se puede mitigar acumulando la experiencia de una flotilla grande pero en otros casos de uso esto podría no ser posible.
Es difícil entrenar para escenarios fuera de lo normal. Es posible que aún después de acumular millones de horas no se cuente con experiencia de casos extremos. En estos casos, los sistemas deben ser aumentados con asistencia humana para ayudar al sistema a tomar una decisión acertada.
Técnicamente complicado. El diseño de estas redes de aprendizaje es complicado, requiere conocimientos avanzados y tiempo para optimizar los algoritmos.

Ver, pensar, conducir y aprender

Para lograr vehículos autónomos necesitamos que dichos vehículos tengan la capacidad de ver, pensar, conducir y aprender para mejorar. A continuación explicamos cómo funciona cada uno de estos pasos.

La capacidad de “ver” se refiere a cómo es que los vehículos detectan el ambiente a su alrededor. Para poder ver, los vehículos hacen uso de tres grandes fuentes de datos:

Sensores: Existen distintos tipos de sensores que obtienen datos en tiempo real sobre el entorno del automóvil. Los sensores más usados son: ópticos (cámaras que capturan color y contraste), LIDAR (pulsos de luz), radar (radio ondas), ultrasónico (alta frecuencia). Cada uno tiene un mejor desempeño en distintas condiciones, por lo que típicamente se usa una combinación de varios sensores para asegurar que el automóvil pueda detectar con precisión su entorno en todo tipo de condiciones.
Datos en la nube: Para reconocer su entorno los vehículos también hacen uso de datos en la nube tales como mapas y rutas, señales de tráfico, condiciones del camino.
Datos de otros dispositivos: Al corto plazo, el escenario más común es el de un smartphone que pueda proveer información al vehículo, pero eventualmente los automóviles tendrán comunicación entre sí (vehículo a vehículo), así como la infraestructura en ciertos lugares (ej. un estacionamiento inteligente que informa al automóvil donde hay espacios disponibles).

“Pensar” se refiere a cómo el automóvil integra la información obtenida y determina la acción correspondiente. La figura 1 ilustra este procedimiento a grandes rasgos. La ejecución de este procedimiento (integrar datos, analizarlos y decidir una acción) debe tomar milisegundos a lo mucho. Adicionalmente, a partir de lo que está sucediendo en el momento, el automóvil debe ir extrapolando para intuir lo que sucederá en el futuro inmediato. El aprendizaje profundo ayuda a realizar dicha extrapolación.

Figura 1. El proceso de pensamiento de un vehículo autónomo

Una vez que el sistema toma una decisión, requiere ejecutarla de manera confiable y segura, a esto nos referimos con “conducir”. Por ejemplo, se debe determinar el ángulo adecuado al que debe girar las llantas, así como la intensidad de aceleración o frenado. A su vez, los distintos componentes proveen retroalimentación sobre el resultado de la acción en ejecución (que sí se esté logrando disminuir la velocidad de acuerdo a lo planeado, que se esté manteniendo la tracción necesaria).

Cada que un automóvil se encuentra con una nueva experiencia o caso extremo, el sistema lo analiza y “aprende” de lo sucedido. El aprendizaje se despliega a toda la flotilla de vehículos para que estén preparados la próxima vez que se encuentren con dicho escenario.

Impacto en la industria

Conforme nos dirigimos a la conducción autónoma, las empresas del ecosistema automotriz deben reconocer las implicaciones de este cambio.

En principio, surgirá un nuevo mercado para servicios de movilidad basados en conducción autónoma y conectividad. Los vehículos podrían estar en uso continuo, por lo que habrá el modelo de propiedad de vehículos cambiará, y la cantidad de kilómetros que acumula cada carro aumentará significativamente. KPMG estima que el mercado de servicios basados en conducción autónoma tendrá un valor anual de más de un millón de millones de dólares para el año 2030.

La conducción autónoma también traerá una reducción significativa de accidentes viales, ya que se estima que el 94% de los accidentes son provocados por errores humanos. Uno de los sectores que más será afectado por este cambio es el de las aseguradoras. Otro sector que será afectado de forma indirecta es el de las autopartes y talleres de reparación.

Finalmente, las empresas automotrices están desarrollando nuevas capacidades para los automóviles que aprovechen este contexto. Desde tecnologías para mejorar “el sistema nervioso” del automóvil hasta servicios de entretenimiento y productividad para los pasajeros (“que estarán liberados de tener que conducir el automóvil y ahora podrán hacer otras cosas a bordo”). Empresas de software como Google, Apple y Microsoft ya están buscando penetrar el segmento de software y servicios a bordo para pasajeros, pero las empresas automotrices no cederán fácilmente esta rebanada del pastel y ya están desarrollando tecnología y canales para ofrecer estos servicios bajo sus propios términos.

Consideraciones para el nuevo paradigma

Las empresas automotrices que no reaccionen de forma sabia y rápida a los efectos que provocará este nuevo paradigma en su industria, desaparecerán en pocos años. Estas son algunas consideraciones que deben tener en cuenta:

Las empresas automotrices ya no se dedicarán solamente a hacer automóviles. La mayoría evolucionará a ser proveedores de servicios de movilidad. La estrategia que cada una elija afectará cómo generará ingresos y si logra mantenerse en el mercado.

Los kilómetros son oro. El aprendizaje profundo detonará una carrera para acumular kilómetros manejados. De especial valor serán las situaciones extraordinarias que extiendan el aprendizaje de los vehículos.

El talento es clave. Las personas con la capacidad de construir y operar sistemas de aprendizaje profundo serán muy valiosas. Actualmente la mayoría de las personas con esta habilidad trabaja en empresas de software (ver figura 1) pero las empresas automotrices ya se las están peleando.

El sistema nervioso será el enfoque de diseño del automóvil. Entramos a una nueva era de diseño automotriz centrada en el “sistema nervioso” del automóvil, que incluye el cerebro del automóvil, sensores, controladores y telecomunicación. Este es un cambio radical para los fabricantes de automóviles.

El poder de la flotilla eclipsará la importancia del automóvil individual. La interacción del automóvil con una flotilla y el ecosistema será esencial. La conectividad asegurará una interacción constante entre los integrantes de la red.

La forma de innovar cambiará. Conforme la industria automotriz adopta y desarrolla capacidades de aprendizaje profundo, aprenderá a innovar de una forma distinta que afectará a otras industrias.

Las plataformas de software automotriz serán clave. Las plataformas de software surgirán como un mecanismo para operar y actualizar el automóvil. Contar con una plataforma sofisticada, segura, capaz de desplegarse en distintos modelos de automóvil y que pueda ser actualizada fácilmente, será un elemento crucial de competitividad para las empresas automotrices.

Figura 2. Talento especializado en deep learning

Conclusión

El aprendizaje profundo está acelerando las capacidades de autonomía y antes de que nos demos cuenta estará en la mayoría de los vehículos. Esto traerá cambios masivos. Aunque nadie sabe con certeza lo que sucederá, es un hecho que se generarán nuevas oportunidades para empresas de distintas industrias: automotriz, software, servicios, entretenimiento. Específicamente, las empresas automotrices deben revisar en qué espacio competirán, con qué producto y servicios, cómo diseñarán los automóviles, cómo gestionarán su flotilla, y cuál es su enfoque hacia la innovación, el talento y la tecnología.

Este artículo es una versión traducida y editada por Software Guru del reporte original “I see, I think, I drive (I learn)” publicado por KPMG.

Referencia

G. Silberg, et al. “I see, I think, I drive (I learn)”. KPMG. http://swgu.ru/t4

Bio

Gary Silberg es socio director para sector automotriz en KPMG Estados Unidos.

Tecnologías detrás del Automóvil Conectado

sg — Mon, 21 Aug 2017 20:44:10 +0000

Tecnologías detrás del Automóvil Conectado

sg Mon, 08/21/2017 - 15:44

Publicado en

SG #55

Autor

Pedro Galván

Está muy bien que platiquemos sobre las posibilidades del automóvil conectado, los escenarios de uso que abre y el impacto que tendrá en distintas industrias. Pero como desarrolladores de software, una de las preguntas que inevitablemente nos hacemos es: ¿cómo podemos desarrollar aplicaciones para este segmento?, ¿qué tecnologías se utilizan y dónde puedo aprender al respecto?, ¿qué oportunidades están abiertas para desarrolladores externos?

Para contestar dichas preguntas, echemos un vistazo a las principales áreas en las que se puede construir soluciones para el automóvil conectado, así como las empresas que están detrás.

Capas aplicativas

Los automóviles modernos utilizan software para resolver distintos aspectos. Aunque no hay un estándar de los distintos grupos aplicativos, en general podemos reconocer los de telemática, infotainment, instrumentación, ADAS y conducción autónoma. A continuación explico cada uno.

Infotainment

Como su nombre lo indica, esta capa ofrece servicios de información y entretenimiento, apoyándose en las capacidades de conectividad, audio y despliegue de información en pantallas. Esto se puede utilizar tanto para escenarios de productividad (ej. hacer llamadas telefónicas, escuchar mensajes de correo) como de entretenimiento (servicios de música, juegos o video para pasajeros).

Telemática

La capa de telemática brinda información sobre la actividad, historial y ubicación de un automóvil. El uso más básico de estos servicios es para construir aplicaciones de navegación por GPS, asistencia en el camino o localización de autos robados. Sin embargo, al contar con la información del estado de un automóvil, tanto histórico como en tiempo real, y combinarlas con servicios de analítica predictiva las posibilidades aplicativas son infinitas. Por ejemplo:

Ofrecer pólizas de seguro personalizadas a los hábitos de manejo de un conductor.
Alertar al conductor cuando se esté acercando a un cruce donde hay una alta incidencia de accidentes.
Alertar al conductor cuando se esté estacionando en un lugar prohibido, o de alto riesgo.

Si adicionalmente combinamos esta información con la capacidad de identificar al conductor (por medio de biométricos o con mecanismos más rudimentarios como contraseñas), podemos habilitar escenarios tales como restringir a que nuestros hijos solo puedan manejar dentro de cierta área geográfica o llegar a cierto límite de velocidad.

Cluster de instrumentos

El cluster de instrumentos es el espacio que despliega información crítica para el conductor, tal como velocidad, temperatura y alertas. En los automóviles modernos se está comenzando a utilizar pantallas digitales en lugar de los tradicionales medidores análogos. En principio podríamos pensar que esto se podría delegar al sistema de infotainment, sin embargo acostumbra manejarse como una capa distinta ya que se requiere desempeño en tiempo real con alta confiabilidad. En otras palabras, no hay mucho problema si el sistema de entretenimiento no despliega correctamente los metadatos de una canción, pero sí hay problema si no sabemos que el auto está sobrecalentado. Es por ello que el cluster de instrumentos requiere operar a bajo nivel sobre un OS para tiempo real conectado al bus interno del automóvil, mientras que el sistema de infotainment opera más arriba sobre frameworks orientados a la información y conectividad externa.

Asistencia de manejo

Esta capa, conocida en inglés como ADAS (advanced driver assistance systems) contiene servicios y aplicaciones para ayudar al conductor a manejar el automóvil, por ejemplo alertar al conductor cuando se detectan objetos cercanos o se está saliendo del carril. Los servicios no solo son de alerta, sino que incluso también pueden controlar cierto aspecto del automóvil, como por ejemplo el frenado de emergencia o el control de velocidad adaptativo (adaptive cruise control). La figura 1 muestra los principales componentes involucrados en estos sistemas y las principales empresas proveedoras para cada uno.

Conducción autónoma

Se refiere a la plataforma que habilita que un automóvil pueda conducirse de manera autónoma. Involucra la operación de los sensores, motor de analítica/decisión, y control del automóvil.

Como es de esperarse, las capas que están más cercanas al control del automóvil (instrumentos, ADAS, conducción autónoma) típicamente son cerradas y como desarrolladores externos no hay mucha posibilidad de interactuar con ellas. En contraste, la capa de infotainment es donde hay mayor apertura y dinamismo. En la siguiente sección revisamos a los principales jugadores y plataformas.

Figura 1. Componentes y proveedores ADAS

Plataformas y proveedores

A continuación describo las que considero las plataformas de software más relevantes para automóvil conectado.

QNX

QNX Software Systems es parte de BlackBerry (fue comprada en 2010), y es líder de mercado en el segmento automotriz. El corazón de su tecnología es el Neutrino RTOS, un sistema operativo de tiempo real basado en Unix que destaca por su arquitectura de microkernel.

QNX tiene una alta penetración en las áreas de telemática e infotainment. Automóviles de marcas como Audi, BMW, Ford, Honda y General Motors, entre otros, utilizan esta plataforma. Típicamente, QNX opera como plataforma de bajo nivel, y las marcas construyen sus propias aplicaciones sobre esta.

El desarrollo de aplicaciones para QNX se hace en C++ utilizando el framework Qt. Específicamente en la capa de infotainment (QNX Car Platform for Infotainment) también se puede utilizar tecnologías web como HTML5 y Javascript. [1]

Linux

Linux ha sido una opción común para las marcas que construyen su propio OS para automóviles. De hecho, el software que opera los automóviles Tesla está basado en Linux, sin embargo es cerrado.

En 2009 se creó la GENIVI Alliance con el objetivo de impulsar la adopción de software open source en sistemas de infotainment. Entre los miembros de alto nivel están empresas como BMW, Honda, Nissan, Daimler y Volvo. El principal resultado de esta alianza es la Genivi Development Platform (GDP), una plataforma abierta basada en Linux para construir aplicaciones de infotainment. GDP puede funcionar sobre distintas arquitecturas de hardware tales como Intel, NVidia, Qualcomm e incluso tabletas de bajo costo como Raspberry Pi. [2]

Otra iniciativa que vale la pena notar es Automotive Grade Linux (AGL), que es operada por la Linux Foundation. Actualmente, la plataforma de AGL solo cubre infotainment, lo cual la hace parecer redundante con GENIVI, pero a diferencia de esta última AGL busca cubrir todo el espectro de software para un automóvil incluyendo telemática, clúster de instrumentos, ADAS y conducción autónoma. Aunque ambas organizaciones son abiertas, y hay muchas empresas que forman parte de ambas, hay empresas con mayor peso detrás de cada una. Por ejemplo, en el caso de GENIVI BMW es uno de los miembros con mayor protagonismo mientras que en el caso de AGL es Toyota. De hecho, el primer despliegue de AGL en un automóvil comercial será el sistema de infotainment del Camry 2018. [3]

Apple CarPlay

CarPlay es básicamente un mecanismo que permite ver y controlar las apps de un iPhone desde la consola de infotainment de un automóvil. Varios automóviles ya lo soportan y funciona con dispositivos iPhone 5 o superior.

Android Automotive

A lo largo de los años Android ha tenido distintos acercamientos en el área de infotainment en automóviles. Posiblemente lo más conocido es Android Auto, que es prácticamente lo mismo que CarPlay (mostrar y controlar las apps de tu smartphone desde el sistema de infotainment), pero para Android.

Otra posibilidad es instalar una capa de Android directamente como sistema de infotainment (sin necesidad de un smartphone). Algunas marcas ya han intentado esto, tomando el código fuente de Android y modificándolo ellos mismos. Al no ser un esfuerzo oficialmente soportado por Google, los resultados no han sido óptimos ya que modificar el sistema operativo no es trivial y requiere bastante esfuerzo por lo que los automóviles terminan usando versiones de Android anticuadas; por ejemplo, el Honda Accord 2017 usa Android 4.2, un sistema operativo del 2012. La buena noticia en este sentido es que Google anunció en mayo del 2017 la iniciativa Android Automotive, que básicamente será una versión de Android optimizada para el automóvil y oficialmente soportada por Google. Volvo y Audi están contemplando incluirlo en algunos modelos de 2019. [4]

SmartDeviceLink

SmartDeviceLink (SDL) es, al igual que CarPlay y Android Auto, un framework para que los smartphones puedan interactuar con los sistemas de infotainment de los automóviles. La diferencia es que SDL es abierto e independiente de Apple y Google. SDL fue originalmente creado por Ford, pero fue donado como open source y actualmente está siendo adoptado por varias automotoras, entre ellas Toyota (parece ser que el Camry 2018 que usará Automotive Grade Linux también soportará SDL para interactuar con smartphones).

De las distintas tecnologías para interactuar desde el smartphone con el automóvil, SDL es la que me parece más amigable para desarrolladores terceros. En su sitio web [5] puedes encontrar guías de arranque, y los SDK están disponibles en GitHub.

Otra capacidad atractiva para desarrolladores de SDL es Manticore. Esta es una instancia del core de SDL disponible en línea para que puedas probar cómo se comporta tu app en un automóvil con SDL. Lo único que haces es entrar desde un navegador web a Manticore [6], apuntar tu aplicación hacia el URL y puerto que te indique, y se cargará en el navegador tu app corriendo para que puedas probar las interacciones y depurarla (ver figura 2). Su uso es gratuito, simplemente regístrate como desarrollador SDL.

Figura 2. Manticore permite probar apps en SDL desde tu navegador

Microsoft Connected Vehicle

Microsoft fue uno de los pioneros en el área de sistemas operativos para infotainment, lanzando Microsoft Auto en 1998 que después de varios cambios de nombre terminó como Windows Embedded Automotive. Las primeras dos generaciones del sistema Sync de Ford estaban basadas en este sistema operativo, sin embargo en 2014 Ford movió Sync hacia QNX. En 2016 Microsoft hizo un cambio drástico de estrategia, abandonando la intención de ser el sistema operativo del automóvil y enfocándose en ofrecer servicios basados en la nube que habiliten aplicaciones en el automóvil. Esta iniciativa actualmente lleva el nombre de Microsoft Connected Vehicle y entre otras cosas abarca servicios de infotainment (llamadas por Skype, servicios de Cortana), analítica predictiva basada en telemática, e información en tiempo real sobre las condiciones del camino. [7]

Sistemas de cómputo

Una batalla no menos interesante es la que se está dando en el lado del hardware sobre el que se ejecuta el sistema operativo del automóvil. Hasta hace poco, los automóviles usaban sistemas en chip (SoC) de gama relativamente baja. Sin embargo, conforme los automóviles se hacen más inteligentes demandan soluciones expresamente diseñadas para este segmento y con mayor poder. Estos son los jugadores y lo que están haciendo …

Renesas Electronics, una empresa de origen japonés especializada en semiconductores y microcontroladores para el sector automotriz es uno de los jugadores originales de este segmento. Aunque tradicionalmente ha estado enfocada en el área de instrumentación y ADAS, recientemente mostró un prototipo de vehículo autónomo.

NVIDIA se ha posicionado rápidamente como líder en cómputo para inteligencia artificial para conducción autónoma, siendo la elección de marcas como Tesla y Toyota. Su oferta para automóviles considera: Drive PX, una tarjeta de cómputo basada en GPUs optimizada para procesar la información captada por las cámaras y sensores del automóvil; Driveworks, un SDK con herramientas y bibliotecas para construir capacidades de conducción autónoma y NVIDIA DGX que son sistemas para el centro de datos optimizados para aprendizaje profundo (deep learning), estos sistemas analizan los datos obtenidos por los automóviles, los analizan y en base a ello entrenan a la computadora del automóvil. Es por ello que Tesla indicó que el Modelo S ya incluye todo el hardware necesario para conducción autónoma pero esta capacidad será activada hasta que se hayan analizado suficientes horas de conducción, lo que está sucediendo es que estos automóviles vienen equipados con una computadora Drive PX que estará enviando información al centro de datos para ser analizada y en base a ello entrenar a la computadora a bordo para tomar decisiones instantáneas. [8]

Intel recientemente lanzó la línea de SoC Atom A3900 orientada específicamente al sector automotriz. Este sistema está diseñado para habilitar clusters de instrumentos y sistemas de infotainment. Sin embargo, la meta importante para Intel está en alcanzar a NVIDIA en el ámbito de cómputo para conducción autónoma. Su estrategia es similar, contemplando una computadora SoC a bordo del automóvil que se comunique con sistemas en un centro de datos donde se haga el aprendizaje profundo; sin embargo, la oferta de Intel también considera la plataforma para comunicación inalámbrica utilizando tecnología 5G. [9]

Qualcomm ha sido un poco lento en entrar al espacio automotriz, pero ya está corrigiendo el rumbo. Por el momento está empujando el Snapdragon 820a como SoC para habilitar capacidades de infotainment y telemática. Su propuesta hace fuerte énfasis en la conectividad, de hecho uno de los puntos a destacar del Qualcomm Connected Car Reference Platform que estará disponible en la segunda mitad del 2017 es que se basa en el modem X16 LTE que puede alcanzar velocidades de Gigabit. Más allá de esto, la reciente compra de NXP Semiconductors habilitará a Qualcomm para ofrecer sistemas automotrices más avanzados y de conducción autónoma. [10]

Bosch y su omnipresencia

Conforme me acerco al final de este artículo considero que me hace falta mencionar a Bosch, pero confieso que no encuentro donde acomodarlos, ya que están involucrados en distintos niveles. Bosch tiene una amplia tradición como proveedor de partes para el automóvil tradicional, pero se ha modernizado junto con el automóvil. Bosch también provee sensores y componentes para manejo asistido (ADAS), así como componentes clave para vehículos eléctricos.

Entre las tecnologías que ha creado Bosch para el automóvil moderno está CAN (Controller Area Network) [11] que es el bus de comunicación que conecta todos los sensores y componentes electrónicos. Es un protocolo de comunicación serial que soporta control en tiempo real con alta seguridad, y que prácticamente todos los automóviles modernos utilizan.

Pero más allá de los componentes individuales para automóviles, lo que destaca a Bosch es su visión y capacidad para soluciones integrales en el contexto de ciudades inteligentes. Un ejemplo de esto sería un sistema de estacionamiento inteligente donde un automóvil que está buscando lugar de estacionamiento pueda ser informado por la red de automóviles en la cercanía sobre dónde hay lugar disponible. Este tipo de soluciones involucra una gran cantidad de subsistemas tales como la inteligencia artificial para detectar lugares, comunicación entre vehículos y coordinación con infraestructura de la ciudad. Bosch es una de las pocas empresas que está pensando a ese nivel, y que tiene amplias capacidades tanto a nivel de ingeniería de bajo nivel como de integrar “sistemas de sistemas”. Por cierto, vale la pena mencionar que Bosch recientemente abrió un centro de desarrollo de software y servicios de ingeniería en Guadalajara, así que seremos testigos de cerca de lo que hagan en este espacio. [12]

Conclusión

El automóvil conectado involucra una gran variedad de tecnologías y empresas que lo habilitan. En este artículo echamos un vistazo a algunos de los jugadores clave y sus estrategias. Algunas de estas tecnologías son cerradas o fuera del alcance de los desarrolladores independientes, pero hay otras que son abiertas y con las que cualquiera puede comenzar a experimentar. Así que si te interesa, te invito que consultes los enlaces que comparto en la sección de referencias para conocer más.

Referencias

Bio

Pedro Galván es director editorial de Software Guru.

El Camino de la Experiencia hacia la Innovación Automotriz

sg — Mon, 21 Aug 2017 20:39:45 +0000

El Camino de la Experiencia hacia la Innovación Automotriz

sg Mon, 08/21/2017 - 15:39

Publicado en

SG #55

Autor

Gunther Barajas

A medida que entramos en la industria 4.0, una nueva era de sistemas ciber-físicos, Internet de las cosas y procesos conectados ¿cuál es el futuro que vamos a crear para la industria automovilística durante los próximos 10 o 15 años?

Conforme visualizamos la movilidad del futuro ¿Podremos crear y producir nuestro propio coche personalizado? ¿Podemos ir más allá de un vehículo de cero emisiones a un modo de transporte que apoye activamente la salud y el equilibrio medioambientales? ¿Qué pasa con los vehículos que son tan inteligentes que literalmente no pueden chocar e incluso pueden contribuir a la seguridad personal y urbana?

Una cosa es cierta, con el inmenso impacto social y emocional de la movilidad y con la creciente tasa de cambio tecnológico, la industria automotriz evoluciona a un ritmo nunca antes visto.

Uso de aplicaciones de datos en el vehículo para centrarse en la experiencia del cliente

Con los vehículos autónomos previstos para estar disponibles al público antes del año 2020, el foco de los fabricantes de autos se centrará en la creación de experiencias de movilidad en torno a cómo los consumidores utilizan e interactúan con sus automóviles. Los pasajeros pueden ahora mirar una película, cenar o trabajar con otras personas, entre otras muchas opciones, esto requiere un entendimiento integral de las capacidades y necesidades de los consumidores más allá de la conducción, inspirando a los proveedores a forjar nuevas alianzas tecnológicas y de negocios mientras desarrollan nuevos estándares de industria y tecnología.

Un típico “nuevo modelo” de auto viene con 100 millones de líneas de código y de 50 a 80 unidades de control electrónico que responden a más de 30 mil requerimientos funcionales. La electrónica comprende entre el 20 y el 40 por ciento del costo actual del desarrollo de vehículos, con un número que se prevé que crezca hasta el 50% para 2030, modificando rápidamente la complejidad del vehículo e influyendo en el proceso de desarrollo. Se espera que el 80% de las innovaciones de vehículos en el futuro sean en sistemas integrados, gran parte de ellos enfocados en seguridad activa o pasiva, entretenimiento y rendimiento.

Será cada vez más crucial validar los subsistemas y el desempeño de un vehículo en una etapa temprana del ciclo de desarrollo del producto. Las nuevas metodologías de la ingeniería de sistemas, que enlazan dominios de procesos dispares , serán necesarias para hacer pruebas dinámicas del vehículo previo a su producción, para garantizar que se cumplan estándares de desempeño y seguridad.

Para reducir el riesgo de innovación en este nuevo mundo de la experiencia de movilidad, los clientes estarán fuertemente involucrados en el proceso de creación a través de experiencias virtuales realistas en 3D. La capacidad de ejecutar pruebas dinámicas e inmersivas en un entorno virtual durante la etapa de diseño, ofrecerá nuevas formas de entender y validar los deseos del consumidor en torno a la movilidad. Además, el aprovechamiento de cantidades masivas de información no estructurada (big data) catalizará la creación de experiencias personalizadas de movilidad. Los sensores dentro de los vehículos proporcionarán nuevos niveles de retroalimentación en tiempo real para que técnicos y empresarios puedan interpretar el comportamiento del cliente. Los subsistemas de los automóviles son cada vez más inteligentes y cada vez más dependientes de la conexión con los datos de otros sistemas. De los faros a los sistemas de escape, cuando antes un “ajuste y acabado” eran la única integración necesaria, entender ahora cómo el software, hardware y la electrónica trabajan juntos es crucial. Toda esta información, mezclada con datos externos de las redes sociales en línea, se utilizará para mejorar continuamente el rendimiento de la conducción y proporcionar así la experiencia deseada.

Para comprender el impacto completo de la innovación, los fabricantes irán más allá de las características físicas y tecnológicas del vehículo hasta simular aspectos funcionales y de comportamiento. Por si fuera poco, el automóvil, el cual es ahora visto como un sistema inteligente, será simulado dentro de sistemas tan amplios como el tráfico, la energía o incluso las redes comunitarias y domésticas.

El concepto del auto Link & Go de AKKA Technologies es un ejemplo de cómo los innovadores en la cadena de suministro automotriz pueden combinar conocimientos avanzados de sistemas de ingeniería con la innovación social para ofrecer nuevas e impresionantes perspectivas para la movilidad auto-dirigida en las carreteras urbanas [1].

Ser ágil administrando la creciente complejidad

Esto puede sonar contradictorio, pero en la era de Automotive 4.0 los fabricantes de automóviles serán capaces de dominar la inmensa complejidad de los sistemas detrás de los procesos de desarrollo y fabricación, simplificando al mismo tiempo la experiencia del usuario en toda la empresa. El primer método para lograr esto es la integración dentro de los actuales entornos de las tecnologías de la información, en los que muchas aplicaciones aisladas han crecido a lo largo de décadas, y donde las oportunidades son numerosas, entre ellas:

integración de diseño e ingeniería para preservar la idea original de una creación,
integración de ingeniería y simulación para compensaciones costo-rendimiento y cumplimiento de productos,
integración mecánica, de software y desarrollo punto a punto para obtener una arquitectura de desarrollo optimizada,
integración de pruebas y validación con mercadotecnia y ventas para conocer los requerimientos.

Cada parte de la organización se beneficiará de una intensa integración, conectando personas, información y procesos a través de un entorno único, intuitivo y colaborativo.

La siguiente clave para la gestión de la complejidad es la modularización -idealmente a través de la aplicación de una estrategia, otra vez, que requiera la integración de diversas disciplinas- desde los requerimientos sobre el diseño de sistemas, la ingeniería detallada y las pruebas hasta la fabricación. La integración comprenderá el mundo virtual y físico: pruebas integradas de hardware y software, planificación y operación integrada en la fabricación, etcétera, mediante la cual objetos inteligentes y modulares establecerán el comportamiento de sistemas complejos.

La tecnología base y los conceptos están disponibles hoy en día. El siguiente paso -la implementación de sistemas inteligentes y auto-adaptables en la fabricación y la logística - sólo estará limitado por el alcance de las estrategias de integración y modularización. Si las impresoras 3D son capaces de manejar una parte de la producción de piezas de repuesto ¿cuál será el impacto en el diseño del producto, su empaquetado y los aspectos comerciales?

Últimamente, la gestión de la complejidad tiene otra dimensión. Al igual que los usuarios de transporte tendrán la posibilidad de personalizar su experiencia, los creadores de soluciones de movilidad también tendrán que beneficiarse de un banco de trabajo más flexible, atractivo, intuitivo y personalizable para las necesidades individuales. Fiat Chrysler Automobile, el séptimo mayor fabricante de automóviles del mundo, ha comenzado a implementar la solución de experiencia por industria "Drive Emotion" en sus estudios de diseño global. Esto permite a sus expertos colaborar en tiempo real en las experiencias y elementos holísticos del usuario como el estilo artístico o calidad de la superficie del vehículo.

Asumir una mayor responsabilidad

Las empresas están acostumbradas a actuar como ciudadanos corporativos responsables, pero estas obligaciones crecerán con la capacidad de las tecnologías del mañana. Los aspectos ambientales han sido durante mucho tiempo parte de las preocupaciones de la industria automotriz, los conductores de hoy en día esperan la entrega de vehículos eco-amigables y eficientes en cuanto al combustible sin sacrificar el rendimiento. Con tanto software en los vehículos, los principales competidores de la industria del automóvil han trabajado juntos para desarrollar el estándar Automotive Open System Architecture (AUTOSAR). Estos fabricantes tienen ahora la tarea de cumplir con el nuevo estándar de seguridad funcional eléctrica/electrónica ISO26262, que requiere la documentación del proceso completo, análisis y verificación de todos los sistemas integrados de los productos que fabrican.

Con diferentes lineamientos que cumplir en todo el mundo, los proveedores de esta industria utilizarán una plataforma que gestione la complejidad de las normas y permita la simulación de modelos y comportamientos, que muestren el balance energético y el potencial impacto del diseño de sus vehículos en el medio ambiente.

El aumento de la seguridad de los pasajeros y los peatones seguirá siendo un elemento que empuje la innovación futura y pronto veremos como este enfoque crece rápidamente. Esta es la razón por la cual los enfoques Target-Zero-Defect son (y seguirán siendo) tan importantes en la agenda de esta industria. Estos dirigen la operación sin fallos y sin incidentes alrededor de los diversos procesos y datos corporativos.

Y ¿qué pasa con la retención de clientes y el uso de sus datos? Con la gama de sensores en el vehículo e información externa disponible, se puede esperar que la industria contribuya realmente al bienestar social y la salud personal. Estos aspectos podrían comenzar por el registro del estado de un pasajero y - según la situación – proveer una sensación calmante dentro del vehículo, iniciar un masaje que evite el dolor de espalda o coágulos de sangre, o conectarse inmediatamente a un médico especialista en caso de emergencia.

Generar y procesar este tipo de datos personales, al menos en los países donde la información es sensible, requerirá que los pasajeros sientan una gran familiaridad con las compañías. Las promesas de las marcas y de los fabricantes, así como la dimensión de confianza, tendrán que reflejarse en modelos de negocios que llevarán a variables como "el placer de conducir" o "ventaja tecnológica" a un nuevo nivel.

Viendo hacia adelante

No somos clarividentes para predecir el futuro de la industria automotriz, sin embargo, estamos seguros de que la integración y el impacto de la innovación social serán elementos fundamentales para controlar la creciente complejidad de la innovación en la industria de la movilidad, lo que contribuirá a aumentar el tiempo de comercialización y su productividad.

Una mayor conectividad dentro de los vehículos con sus entornos, así como la demanda continua de movilidad individualizada, abrirán nuevas oportunidades para que los innovadores automovilísticos creen experiencias diferenciadas para sus clientes. Los ambientes virtuales de trabajo que son realistas, colaborativos, "inteligentes" e intuitivos serán los laboratorios de innovación para crear estas experiencias. Las tecnologías de hoy día, aunque en constante evolución, ya construyen un puente para proporcionar el nivel de colaboración necesario para operar mañana el Automotive 4.0.

Referencias

http://blogs.3ds.com/perspectives/autonomous-cars-in-the-age-of-experience/

Bio

Gunther Barajas (@GBV_001) es Vice Presidente de Dassault Systèmes para México. https://www.3ds.com/es

Exportando Sistemas Relacionales a Sistemas Columnares Distribuidos

sg — Mon, 21 Aug 2017 20:31:18 +0000

Exportando Sistemas Relacionales a Sistemas Columnares Distribuidos

sg Mon, 08/21/2017 - 15:31

Publicado en

SG #55

Gestión de datos

Autor

Hugo de la Mora

El manejo de información masiva se ha hecho cotidiano, y una estrategia común para analizar grandes cantidades de datos es moverla de las bases de datos relacionales tradicionales (RDBMS) hacia bases de datos columnares distribuidas.

En el presente artículo muestro los pasos necesarios para migrar información relacional a una infraestructura de Hive en Hadoop. La idea básica es importar grandes datos de un origen relacional como Microsoft SQL Server a un almacenamiento en Hadoop como Hive o HDFS, teniendo la posibilidad de analizar esa información a través de Hue.

Panorama

Para esta labor utilizaremos Apache Sqoop [1], una herramienta precisamente creada para mover datos entre bases de datos estructuradas y Hadoop. Sqoop trabaja con tablas individuales, cada fila de una tabla se trata como un registro en HDFS. Todos los registros se almacenan como datos de texto en archivos de texto, en Hive o HBase (ver figura 1).

Figura 1. Flujo de Sqoop

Prerrequisitos

Para el propósito de este tutorial voy a suponer que ya se tiene instalado y funcionando tanto un ambiente de SQL Server como otro de Hadoop. Si no tienes el de Hadoop, para propósito de aprendizaje puedes utilizar una máquina virtual de Cloudera Quickstart [2]. En tu ambiente de Hadoop necesitas tener instalado Sqoop. Checa si ya tienes, invocando el comando “sqoop” desde la línea de comandos. Si no lo tienes, lo más conveniente es instalarlo por medio del manejador de paquetes de tu sistema operativo (en el caso de OSX está disponible para Homebrew).

Preparando la conexión

Nos conectaremos a SQL Server por medio de JDBC. Para que esto funcione primero necesitamos habilitar TCP/IP en nuestra instancia. Esto se hace desde el SQL Server Configuration Manager.

Posteriormente vamos a descargar el driver de JDBC de SQL Server en nuestro ambiente Hadoop. Este se obtiene del sitio web de Microsoft y al momento de escribir este artículo la versión más reciente se obtiene en http://swgu.ru/t3 . Dentro del paquete encontraremos una carpeta jre7 y otra jre8 y dentro de cada una hay un archivo .jar que corresponde al driver. Así que seleccionaremos el archivo que corresponda a la versión de java que estemos usando y lo copiaremos en /var/lib/sqoop . Si esta carpeta no existe, la creamos y le asignamos los permisos necesarios como se ve a continuación.

$ mkdir -p /var/lib/sqoop
$ chown sqoop:sqoop /var/lib/sqoop
$ chmod 755 /var/lib/sqoop
$ sudo cp sqljdbc_6.0/enu/jre8/sqljdbc42.jar /var/lib/sqoop/

Importando datos

Para verificar que podemos conectarnos de nuestro ambiente Hadoop a SQL Server vamos a comenzar listando las bases de datos. Para ello utilizamos sqoop list-databases con los argumentos de conexión requeridos (en este ejemplo nuestro SQL Server está disponible en la ip 192.168.56.1 y exponiendo el puerto 1444, y tiene un usuario hadoopUser con contraseña hadoop… ).

$ sqoop list-databases --connect jdbc:sqlserver://192.168.56.1:1444 --username hadoopUser --password hadoop...

Con lo anterior obtendremos una lista de las bases de datos.

A continuación importamos la base de datos y tablas que queremos (en este caso la tabla employee de la base de datos sqoopDB).

$ sqoop import --connect "jdbc:sqlserver://192.168.56.1:1444;username=hadoopUser; password=hadoop...; database=sqoopDB" --table employee --hive-import

Por cierto, si quisieramos importar todas las tablas de la BD sin necesidad de especificarlas una por una utilizaríamos sqoop import-all-tables –connect “jdbc://sqlserver….” --hive-import

Si quieres revisar lo que se importó a Hadoop, puedes hacerlo por medio Hue, una interfaz gráfica web para navegar Hadoop.

Hagámoslo repetible

Si quisieramos estar realizando esta tarea frecuentemente, lo más conveniente es crear un “job” en sqoop que simplemente podemos invocar. Para ello usamos sqoop job con el argumento --create y el resto de la información para conectarse a SQL Server.

$ sqoop job --create jobImpEmpl -- import --connect "jdbc:sqlserver://192.168.56.1:1444;username=hadoopUser;password=hadoop...;database=sqoopDB" --table employee --hive-import

Lo más probable es que no querramos importar todos los datos cada vez que ejecutamos la tarea, sino que solo querramos importar los datos nuevos o modificados. Para lograr esto usamos la opción --incremental e indicamos la columna con el timestamp a verificar.

$ sqoop job --create jobImpEmplInc -- import --connect "jdbc:sqlserver://192.168.56.1:1444;username=hadoopUser;password=hadoop...;database=sqoopDB" --table employee --incremental lastmodified -check-column creationdate --hive-import

Ya creamos los jobs, pero todavía no los ejecutamos. Para ejecutar un job utilizamos sqoop job --execute <nombre-del-job>. Para ver los jobs que tenemos definidos podemos usar sqoop job --list. Y si queremos consultar los detalles de algún job usamos sqoop job --show <nombre-del-job>.

Ejecución periódica automatizada

Si deseamos estar importando datos de manera periódica y automatizada, lo más conveniente es programar la tarea por medio de Oozie, que es una herramienta del ecosistema Hadoop que permite gestionar workflows desde una interfaz web.

Oozie tiene un editor en el cual defines el workflow. Si ya tienes el comando de sqoop que deseas ejecutar simplemente puedes “pegarlo” en un campo de texto al crear tu workflow. Después de eso podemos crear “coordinadores” para calendarizar el envío de información al sistema HDFS (ver figura 2).

Figura 2. Coordinar workflows en Oozie

Conclusión

Se ha mostrado de una forma sencilla la extracción de datos desde un popular ambiente de bases de datos relacionales hasta un sistema columnar como Hive.

Referencias

Bio

El MSC Hugo Enrique De La Mora Carrillo (@hugodelamora) es Chief Information Security Officer en CONTPAQi. Anteriormente ha trabajado con sistemas distribuidos, big data, desarrollo para cloud y móvil.

Visión Computacional

sg — Mon, 21 Aug 2017 20:26:49 +0000

Visión Computacional

sg Mon, 08/21/2017 - 15:26

Publicado en

SG #55

Herramientas y Tecnologías

Autor

Ana Loyo

La visión computacional trata de emular en las computadoras la capacidad que tienen nuestros ojos. Es decir, trata de interpretar las imágenes recibidas por dispositivos como cámaras y reconocer los objetos, ambiente y posición en el espacio.

Lograr tal interpretación al mismo nivel que el ser humano es un problema complejo. Sin embargo, ha habido avances considerables a lo largo de los años.

Del procesamiento de imágenes a la visión computacional

Durante la década de los 1970s se dieron los primeros avances significativos en el campo de análisis de imágenes por computadora. Resaltan los siguientes trabajos::

Azriel Rosenfeld es uno de los pioneros en este campo, su trabajo se enfocó principalmente en el desarrollo de técnicas empíricas basadas en criterios matemáticos para representar objetos físicos por medio de un conjunto de discreto de datos.
Otro enfoque fue el propuesto por Waltz y Mackworth en 1975, reduciendo el alcance del problema a un mundo de bloques blancos mate iluminados sobre fondo negro. Los bloques podían tener cualquier forma, siempre que todas sus superficies fueran planas y todos sus bordes rectos. Aunque este enfoque fue útil para experimentar, dadas sus restricciones no se pudo llevar a mundos complejos.
Por su parte, el trabajo de Berthold Horn se enfocó en establecer modelos de cálculo que expresan la formación de imágenes a través de ecuaciones diferenciales que relacionan los valores de intensidad de la imagen con la geometría, la reflectancia de la superficie y el punto de vista del observador. La idea era que debía existir un nivel adicional de comprensión en el que el carácter de las tareas de procesamiento de la información llevadas a cabo durante la percepción se analicen y comprendan de modo independiente a los mecanismos y escrituras particulares que los implementa en nuestros cerebros.

Ahora bien, debemos considerar que la visión computacional y el procesamiento de imágenes son cuestiones diferentes. El procesamiento de imagen trata sobre cómo mejorar una imagen para su interpretación por una persona mientras que la visión computacional trata de interpretar las imágenes por la computadora.

La visión computacional se puede dividir en 3 grandes etapas:

Procesamiento de nivel bajo. Se extraen propiedades como orillas, gradiente, profundidad, textura, color, etcétera.
Procesamiento de nivel intermedio. Agrupa elementos de nivel bajo para obtener contornos y regiones con el propósito de segmentar.
Procesamiento de alto nivel. Consiste en la interpretación utilizando modelos y/o conocimiento del dominio del problema.

Experimentando con OpenCV

Actualmente, una de las tecnologías más usadas para visión computacional es OpenCV. Esta es una librería publicada bajo licencia BSD que está disponible para una gran variedad de sistemas operativos y tiene más de 500 funciones que abarcan una amplia gama de áreas en el proceso de visión y reconocimiento de objetos, calibración de cámaras, visión estérea y visión robótica. Se puede utilizar con los lenguajes de programación Python, C++ y Java, entre otros.

A continuación explicaré como instalar un ambiente de desarrollo para visión computacional con OpenCV y Python.

En este caso, Python es una excelente opción de lenguaje de programación por ser un lenguaje de código abierto, multiplataforma, con una sintaxis intuitiva, una curva de aprendizaje corta y un amplio ecosistema de bibliotecas. En caso de que no tengas Python instalado, puedes obtenerlo en https://www.python.org/downloads . Procura usar una versión 2.7.x de Python (al momento de este artículo la versión más reciente de esta rama es la 2.7.13) ya que si usas una versión 3.6.x tendrás problemas de compatibilidad cuando trates de usarlo con las otras herramientas que recomiendo en este artículo.

Si quieres utilizar un editor de código, personalmente me gusta LiClipse, pero en gustos se rompen géneros así que utiliza tu preferido.

El siguiente paso a seguir es la instalación de NumPy (en su última versión), un paquete fundamental de Python que contiene sofisticadas funciones y extiende el soporte para vectores, matrices y funciones matemáticas de alto nivel. La forma más sencilla de instalar numpy es por medio de la utilería pip. Si trabajas en Windows, como yo, recuerda agregar las variables del sistema correspondientes a la ruta donde tienes tu archivo Python.exe y a la carpeta Scripts dentro de Python. Hecho lo anterior solamente tendrás que ejecutar desde la línea de comandos:

pip install numpy

Si todo sale bien obtendrás un mensaje confirmando que numpy se instaló exitosamente.

Ahora vamos a instalar OpenCV. Si usas Windows, para instalar OpenCV debes descargarlo de http://opencv.org/releases.html donde encontrarás un ejecutable de Windows. Este archivo es un paquete que descomprime OpenCV en la carpeta que elijas. Una vez hecho esto, entra a la carpeta que se creó y localiza el archivo cv2.pyd bajo la ruta build/python/2.7/x64 (el x64 ruta es suponiendo que tu sistema operativo sea de 64 bits, que es lo más probable). Ahora copia el archivo cv2.pyd a la carpeta lib/site-packages de tu instalación de Python.

Si usas Linux, puedes instalar OpenCV del repositorio de paquetes de tu sistema operativo. En el caso de OSX, lo más sencillo es instalar OpenCV por medio de Homebrew (tienes que habilitar el repositorio homebrew/science).

Para verificar que nuestra instalación de OpenCV funciona correctamente hagamos un pequeño programa. Crea en tu computadora una carpeta donde pongas un archivo de imagen, y crea un programa python con el código mostrado en el listado 1.

Listado 1. Prueba de opencv

Reemplaza “carro.jpg” por el nombre de archivo de tu imagen (recuerda incluir la ruta en caso que tu imagen esté en una imagen distinta a tu programa).

Si todo está bien, al ejecutar tu programa se desplegará una ventana con tu imagen, tal como se muestra en la figura 1.

Figura 1. Ejecución de programa con OpenCV

Teniendo todo esto instalado puedes comenzar a experimentar con el reconocimiento de imágenes. Obviamente necesitarás más que esto pero el objetivo del artículo es que puedas realizar una configuración mínima necesaria para comenzar, suerte con tus proyectos.

Te comparto algunas recomendaciones para continuar en tu exploración:

Puedes tener problemas al querer usar PIP, verifica que estén bien las variables de entorno en tu sistema operativo.
Cuando descomprimas OpenCV asegúrate de estar copiando el archivo correcto en la ruta correcta porque si no lo haces bien, no reconocerá el import de cv2.
En http://opencv.org/links.html puedes encontrar varios tutoriales e información de referencia sobre OpenCV.
Cuando trabajas con dispositivos como la RaspBerry tu código será un poco distinto. No pretendas probar sin tener el hardware, inicia tu código y pruebas hasta que lo tengas y te evitarás re-trabajo.

Bio

Ana Luz Loyo Páez es Ingeniero en Sistemas Computacionales (UNIVO) con Maestría en Comercio Electrónico (ITESM). Actualmente es Coordinadora de contenidos en Software Guru, y catedrático en la Universidad Veracruzana. Además es desarrolladora, instructora y asesora de TI y Negocios Electrónicos freelance. TW @ana_loyo

CDO: Se buscan líderes digitales

sg — Mon, 21 Aug 2017 20:19:37 +0000

CDO: Se buscan líderes digitales

sg Mon, 08/21/2017 - 15:19

Publicado en

SG #55

Columna invitada

Autor

Olivia Salas

Una de las preguntas clave que la alta dirección se hace al emprender una iniciativa de transformación digital es: ¿quién debe liderar el viaje hacia la innovación? En muchas organizaciones, la respuesta se ha materializado en un nuevo rol corporativo: el director de Digitalización, o Chief Digital Officer (CDO), a quien se le encomienda concretar la evolución innovadora del negocio.

Por la sustancia digital del cargo, que exige una sólida competencia tecnológica en temas como IoT, Big Data, movilidad, entre otras, se asume que el CIO es un candidato ideal para dirigir una iniciativa de transformación digital. Sin embargo, de acuerdo con encuestas entre corporaciones globales, sólo el 35% de los CIO dirigirá la transformación digital de sus organizaciones. Estos especialistas también deben afrontar una pregunta, al parecer, sin respuesta sencilla: “¿Y por qué yo no?”.

CDO: una evolución posible para el experto TI

En la elección de un líder para dirigir la transformación digital, según los expertos, la mayoría de los CIO pierde la oportunidad por la misma razón: no logran demostrar de forma contundente que su habilidad tecnológica está firmemente alineada a los valores de negocio. Por ejemplo, los CIO pueden proyectar un gran conocimiento sobre IoT, pero pierden confianza ante cuestionamientos que un CDO debería responder: ¿qué significará IoT para la experiencia del cliente?, ¿esta innovación generará nuevas oportunidades o líneas de negocio?, ¿tendrá un efecto negativo en una oferta?, ¿cómo influirá IoT en la estrategia de ventas y mercadotecnia?

En ese sentido, en el marco de una transformación digital, el CDO entiende qué necesita cambiar, por qué debe hacerlo y cuál será la repercusión de negocio, mientras que el CIO se concentra en cómo realizar la modificación.

No obstante, un líder del área de Tecnología o Sistemas puede tomar las riendas de una iniciativa digital si cambia su enfoque y desarrolla nuevas capacidades. Entre otros aspectos, debería poner atención a:

Mejorar la comunicación con los líderes de negocio. En sus diálogos con otros gerentes y directivos es necesario reducir el uso de palabras como “algoritmo”, “protocolo” o “zettabytes”, y privilegiar conceptos como “trayecto del cliente”, “ventas multicanal” y “experiencia del usuario”, entre otros. Esto implica una nueva actitud y enfoque: no sólo pensar en el costo, la implementación y la gestión de la innovación, sino en cómo utilizarla para alcanzar metas de negocio que generan valor a la empresa.
Definir nuevos parámetros de colaboración. Dado su foco y experiencia en la operación, los CIO tienden a hablar y pensar en escala de “proyectos”. Hoy, la prioridad es interactuar con los distintos departamentos empresariales, entender sus objetivos y plantear “resultados de negocios”. El CDO es un habilitador de capacidades, no un gestor de tareas. Los mejores CDO detectan las necesidades de las áreas corporativas, incluso antes de que éstas las reconozcan.
Nueva escala de valores. En la dinámica de su equipo de trabajo original, el departamento de Sistemas o Tecnología, el CIO debe inculcar una cultura de la velocidad, la agilidad y el foco en el cliente. Esto creará una mentalidad “de CDO” entre los especialistas técnicos, lo que enriquecerá su visión de la empresa, la toma de decisión y el liderazgo.
Colaboración multidisciplinaria. En su camino a la posición de CDO, un líder tecnológico hará bien en acostumbrarse a trabajar con especialistas en ventas, mercadotecnia, logística, administración, producción, redes sociales, atención al cliente, etc. Sumar la perspectiva de estos colaboradores, en las metas de TI, fortalece la capacidad de análisis y ejecución de un CDO.

Más allá de estos aspectos, para asumir el timón de una transformación digital, los CIO deben superar un gran desafío. En muchas ocasiones, abrumados por las tareas operativas de TI que deben atender todos los días, los CIO no tienen tiempo para desarrollar la visión, la creatividad y las capacidades que exige el rol de CDO.

En este aspecto,soluciones de software para infraestructura, automatización, desarrollo y gestión de nube entre mucha más, facilitan la administración y operación de la infraestructura de TI existente, y habilitan el camino a tecnologías emergentes. Ambas capacidades, permiten que el líder de TI se concentre en la transformación innovadora del negocio, y tome mucho menos tiempo en tareas operativas.

Un CIO que se compromete con una nueva visión y el desarrollo de nuevas habilidades, sin lugar a dudas, puede ponerse al frente de una transformación digital, la transformación de la organización hacia el futuro de un negocio que evoluciona.

Bio

Olivia Salas es Directora de Marketing de Red Hat México.