Jornadas de Computación Empotrada (JCE)

Las JCE son un foro de debate y cooperación entre investigadores y expertos en sistemas empotrados, que comenzaron en el año 2010 en el marco del CEDI. Este año se celebrarán en Elche, del 19 al 21 de septiembre, conjuntamente con las Jornadas de Paralelismo y las Jornadas de Computación Reconfigurable y Aplicaciones, en el contexto de las Jornadas SARTECO 2012 (http://www.jornadassarteco.org).

Como en las ediciones anteriores, los mejores trabajos serán seleccionados para su publicación, en versión extendida y en inglés, en la revista Embedded Software Design (Journal of Systems Architecture) de Elsevier, indexada en el JCR (con factor de impacto).

La fecha límite de envío de trabajos es el 27 de Abril y los temas de interés:

• Arquitecturas y Diseños de Referencia en Computación Empotrada:

    Plataformas, procesadores y dispositivos de propósito específico.
    Firmware y sistemas operativos en tiempo real.
    Sistemas multi-core, multi-hebra.
    Seguridad y confiabilidad en sistemas empotrados.
    Sistemas críticos y de tiempo real.
    Linux, Android y plataformas de código abierto.

• Conectividad de Sistemas Empotrados

    Middleware.
    Calidad del servicio y análisis de prestaciones.
    Virtualización.
    Sistemas distribuidos, redes de sensores y comunicaciones.
    Gestión compleja de datos.
    Captura dinámica de sensores.
    Tecnologías de Servicios: Servicios pervasivos de localización.
    Interfaces al usuario y realidad aumentada.
    Sistemas vestibles y computación ubícua.
    Internet de las cosas.

• Diseño de Sistemas Empotrados

    Métodos y Herramientas.
    Depuración, verificación, integración y test de sistemas.
    Líneas de productos.
    Certificación.
    Optimización del consumo energético.

•  Computación Empotrada: Aplicaciones y Retos de la Sociedad

    Automatización y control avanzado.
    Robótica y mecatrónica.
    Consumer electronics (multimedia, entretenimiento, comunicaciones, etc).
    Aplicaciones críticas (aeroespaciales, militares, industriales, médicas, automoción, etc).
    Salud y bienestar accesible.
    Transporte verde seguro y funcional.
    Aplicaciones Medioambientales, en Agricultura o Ganadería.
    Edificios inteligentes y comunidades del futuro (Smart Bulding, Smart City y Smart Grid).
    Educación universitaria.

Innovación tecnológica e I+D

Existen distintas definiciones de innovación tecnológica:

1. Acto o proceso consistente en aceptar o en casar por primera vez, en un país o ámbito espacial preciso, una nueva oportunidad tecnológica con una necesidad o, en su caso, con una demanda a ser cubierta.
2. Proceso que posibilita la producción de nuevos bienes y servicios aplicando las últimas técnicas conocidas. Este proceso comprende el desarrollo y comercialización con éxito de nuevos o mejorados productos; la utilización comercial de nuevos procesos y equipos y la introducción de nuevos métodos de servicio social.
3. Introducción de alguna modificación de tipo técnico que incremente la eficacia del proceso productivo.
4. Proceso por el cual se introducen en el sistema productivo nuevas combinaciones de los factores de producción que permiten disponer de un nuevo producto o producir uno ya existente con un menor coste.
5. Producto o proceso enteramente nuevos, o sustancialmente mejorados técnicamente, que se ofrecen a usuarios potenciales.

A partir de estas, se puede concluir que la innovación tecnológica es aquella que resulta de la primera aplicación de los conocimientos científicos y técnicos en la solución de los problemas que se plantean a los diversos sectores productivos, y que origina cambio en los productos, en los servicios o en la propia empresa en general, introduciendo nuevos productos procesos o servicios basados en nueva tecnología

En ocasiones se confunden los conceptos de innovación tecnológica e I+D. La Invetigación + Desarrollo se define como el mecanismo generador de aquellas tecnologías y conocimientos propios con las que la empresa pretende potenciar o desarrollar sus productos, procesos y servicios.

Esta definición remarca el carácter interno de la I+D y su menor alcance con respecto a la innovación tecnológica que incluye:

• La Investigación y Desarrollo (I+D)
• La adquisición de tecnología externa (patentes, know-how, marcas, diseños…)
• La compra e implantación de paquetes de software
• La adquisición de maquinaria y equipos con rendimiento tecnológicamente mejorado
• La puesta a punto de herramientas y equipos industriales
• La ingeniería de procesos y diseño industrial
• La formación del personal
• Mejora de la experiencia del consumidor

De hecho se habla de I+D+i (Investigación + Desarrollo + innovación)

Procesadores Itanium

Ya hemos comentado en entradas anteriores que los procesadores que podemos encontrar hoy en día en los PCs, portátiles y servidores, están diseñados para ejecutar instrucciones del repertorio x86 (que es CISC, aunque luego el front-end de los procesadores traduzca las instrucciones a microoperaciones de tipo RISC). Este es el estándar de facto en el que los dos grandes fabricantes de este segmento de mercado, Intel y AMD, basan todos sus diseños. O casi todos, porque Intel lanzó hace ya unos años un procesador que se basa en otro tipo de repertorio: el procesador Itanium diseñado para ejecutar instrucciones del repertorio IA-64.

Algunos habéis preguntado en ocasiones por este tipo de procesador ya que es relativamente habitual en  servidores críticos tanto en industria como en infraestructuras (en concreto del fabricante HP), así que intentaré explicar en qué se diferencia del resto de procesadores en pocas palabras. El Itanium es un procesador de tipo EPIC (Explicitly Parallel Instruction Computing) y en este tipo de diseños la relación entre el compilador y el hardware es mucho más estrecha de los habitual. Simplificando un poco, la idea es descargar al procesador de ciertas "responsabilidades" de manera que se encargue de ellas el compilador. De esta manera se puede simplificar el hardware que normalmente se dedica a funciones como la planificación dinámica de instrucciones y ejecución fuera de orden, la emisión superescalar, etc; y dedicar el área que se ahorra a añadir más unidades funcionales a la ruta de datos del procesador (capacidad de realizar operaciones). ¿Para qué? Para agrupar varias instrucciones en una más larga (con técnicas del tipo VLIW que ya hemos explicado) y que se puedan ejecutar en paralelo.

El compilador, además de encargarse de buscar las instrucciones que pueden empaquetarse juntas, y por lo tanto, ejecutarse en paralelo, también se encarga de proporcionar "pistas" (hints) al procesador para que pueda mejorar sus resultados en las predicciones de los saltos, para que las técnicas de prefetching sean más eficientes, etc.

A pesar de los continuos rumores acerca de este procesador y de su desaparición, parece que Intel y HP siguen apostando por él para servidores de HPC, por lo que los sistemas operativos orientados a servidores, tanto Windows como Linux, le siguen dando soporte. Próximamente se espera el lanzamiento de una nueva versión del procesador Itanium2, el Poulson, que ha generado bastantes expectativas en cuanto a su rendimiento.

Disponibilidad de servidores 2010-2011

En esta entrada se relacionan los principales resultados que se extraen de la ITIC 2010-2011 Global Server Hardware and OS Reliability Survey. Esta encuesta presenta la fiabilidad y la disponibilidad de los principales sistemas operativos para servidor utilizados en las organizaciones.

Por tercer año consecutivo, el sistema operativo para servidor considerado como el más fiable es el IBM's AIX UNIX sobre un total de 19 plataformas entre las que se incluyen SO UNIX, Microsoft, Linux y MAC OS X. Según el 78% de los encuestados, el sistema de IBM experimentó menos de un error por año asociado a la capa 1 (Tier 1*) de disponibilidad.

Destaca la posición obtenida por los sistemas operativos Windows 2008 Server y 2008 Server R2, que ocupan el tercer puesto del ranking de fiabilidad, desbancando a sistemas operativos tipo UNIX, Linux y Open Source que ocupaban estos puestos durante los años 2008 y 2009. Según el 92% de los encuestados, los sistemas operativos desarrollados por Microsoft, experimentaron menos de un error por año asociado a la capa 3 (Tier 3*) de disponibilidad.

En cualquier caso, además del criterio de la disponibilidad, es necesario tener en cuenta otros criterios a la hora de seleccionar un sistema operativo para servidores. Entre estos criterios destacan:

• El coste de propiedad (TCO) del sistema operativo, en el que se incluiría el coste de adquisición y el mantenimiento del mismo (Service Packs y Parches).
• La facilidad de desarrollo de parches en caso de que se produzcan fallos en los sistemas operativos.
• La existencia de personal cualificado que sea capaz de administrar correctamente el sistema operativo seleccionado.
• La idiosincrasia del sector o entorno en el que se va a implementar el sistema operativo.
• La latencias requeridas por los usuarios para satisfacer sus peticiones de servicio.

En esta entrada se describía el método AHP como una técnica de decisión multicriterio (TDM) en la que el decisor debe alcanzar un objetivo y para ello dispone de varias alternativas. A su vez cada alternativa es valorada teniendo en cuenta una serie de criterios. Podría ser una buena práctica aplicar esta TDM para seleccionar el sistema operativo idóneo para cubrir las necesidades de una aplicación específica.

(*) La denominación de Tier 1, 2, 3 y 4 corresponde a una nomenclatura estándar que identifica el nivel de disponibilidad de un Data Center. Un Data Center Tier 4 es considerado el más robusto y con menor probabilidad de interrupción de servicio no programado. El Tier 1 es un sistema no redundado, mientras que el Tier 4 se desarrolla redundando todos sus componentes (servidores, almacenamiento, SAI…)

Los porcentajes de disponibilidad garantizados por cada Tier son los siguientes: Tier 1 (99.671%), Tier 2 (99.741%), Tier 3 (99.982%) y Tier 4 (99.995%). Como se comentaba en esta entrada, los Tier 3 y 4 se corresponden con sistemas de alta disponibilidad (HA), ya que el porcentaje está en un valor a partir de los tres nueves, es decir, por encima de un 99.9%.

Tolerancia a fallos y disponibilidad

En un sistema compuesto por  nodos de cómputo distribuidos la probabilidad de que se produzca un fallo aumenta, pero se debe garantizar que el sistema siga funcionando a pesar de ellos. Y minimizando las pérdidas de información y/o rendimiento, es decir, garantizando una calidad de servicio mínima a los usuarios.

Desde el punto de vista de la arquitectura, la principal herramienta que se puede utilizar para resolver este problema es la redundancia, es decir, incluir recursos adicionales a los estrictamente necesarios para la operación normal del sistema. La redundancia siempre incrementa el coste de la arquitectura, por lo que es importante elegir adecuadamente el tipo de recurso adicional que se va a utilizar.

Existen distintos tipos de redundancia, principalmente hardware, software y  de información. Y se puede aplicar a diferentes niveles (físico, sistema operativo, aplicación). Por ejemplo, en lo que se refiere al hardware, dos de los elementos críticos para conseguir la tolerancia a fallos que se suelen incluir en todos los diseños actuales son las SAI (Sistemas de Alimentación Ininterrumpida) para la alimentación y los RAID para el almacenamiento.

A veces el concepto de la tolerancia a fallos se confunde con el de disponibilidad, pero, aunque estén relacionados, no se refieren exactamente a lo mismo. La disponibilidad es la capacidad de un sistema de garantizar la continuidad en su operación ante cualquier situación. Los usuarios deben tener, la mayor parte del tiempo, la capacidad de acceder a la arquitectura para lanzar trabajos, realizar tareas de configuración y mantenimiento, recoger resultados, etc. Esta capacidad del sistema se suele cuantificar con el porcentaje de tiempo que ha estado disponible para los usuarios (se habla de alta disponibilidad cuando este porcentaje está en un valor a partir de los tres nueves, es decir, por encima de un 99.9%).

Obviamante debemos tener resuelta la tolerancia a fallos para conseguir sistemas de alta disponibilidad. Pero la continuidad en el servicio no sólo se ve amenazada por fallos o desastres, también existen discontinuidades en el servicio por paradas programadas, por ataques de denegación de servicio o por picos de demanda del servicio, sólo por poner algunos ejemplos.