Los sistemas electrónicos se utilizan en forma creciente en las aplicaciones de salvaguardia críticas, no solo en los dóminos “tradicionales” (tales como las aplicaciones aeroespaciales), que han empleado la tolerancia a fallos desde hace varias décadas, sino también en nuevos dominios en los cuales los sistemas embebidos son usuales, como es el caso de los dominios, automotrices, biomédicos, y de telecomunicaciones. En la mayoría de los casos, es importante la detección de las fallas posibles que aparezcan cuando el sistema se despliegue en el campo, lo cual prevendrá problemas serios. De esta forma, las soluciones para el desarrollo de pruebas en el campo de los sistemas embebidos se están transformando en algo mas usual. En la mayoría de los casos existen regulaciones y estándares, (por ejemplo, la IC 61508 para sistemas vinculados a la salvaguardia genérica; la ISO 26262 para aplicaciones automotrices y la DO-254 para aviónica). Esto hace que la selección de la solución más adecuada sea aún más importante, no solo desde el punto de vista técnico, sino también desde los puntos de vistas económico y legal.
En el tema de Febrero de Computing Now veremos los desafíos que este escenario presenta, así como las soluciones propuestas para superarlos efectivamente.
La Necesidad de Enfoques de Pruebas de Campo a Nivel de Sistema.
En la mayoría de los nuevos dominios que incluyen sistemas electrónicos con restricciones estrictas de salvaguardia críticas, varias compañías están involucradas en el diseño y la fabricación, cada una teniendo su propio interés y restricciones. Por ejemplo, las unidades de control electrónico para los sistemas electrónicos complejos distribuidos de los automóviles actuales son integradas por los fabricantes de automóviles, pero producidas por diferentes fabricantes de equipamiento original. A su vez, los últimos recursos tanto o de dispositivos comerciales como a medida son distribuidos por diferentes compañías de semiconductores para sus productos. En este escenario, los productos de salvaguardia críticos utilizan usualmente dispositivos originalmente desarrollados para productos menos críticos. Por lo cual, no queda asegurado que existan mecanismos adecuados, (por ejemplo, basados en el Diseño para Comprobabilidad), para desarrollar pruebas en el campo de los dispositivos del fabricante. En forma adicional, los fabricantes de equipo original a menudo desconocen la estructura interna de cada dispositivo, lo cual puede hacer que el desarrollo de pruebas sea un desafío. Además, un componente puede contener núcleos con propiedad intelectual, haciendo que los detalles de su estructura interna sean desconocidos aun para los fabricantes del dispositivo.
Generalmente las soluciones deben combinar las restricciones técnicas y comerciales en tanto que preservan la propiedad intelectual de cada producto. También, dado que las pruebas se realizan a menudo durante la fase operacional, (por ejemplo, durante los tiempos inactivos de las secuencias temporales), las soluciones adoptadas deben igualar a las restricciones de la aplicación en términos de duración y recursos. Finalmente, los requerimientos incluyen crecientemente a la seguridad, lo cual típicamente demanda el bloqueo del acceso entre dispositivos a sus trabajos internos tanto como sea posible. Desafortunadamente, estos requerimientos colisionan con las pruebas, lo cual beneficia la alta controlabilidad y observabilidad del circuito interno.
La Perspectiva de la Industria
Industry Perspective Video
Davide Appello on in-field test approaches.
Una práctica usual de la industria es el encarar estos problemas con una variedad de soluciones, algunas veces recayendo fuertemente en el diseño de la comprobabilidad (por ejemplo, generando una auto comprobación) y otras veces posibilitando una aproximación funcional. Las soluciones hibridas también son populares. En este video, David Appello de ST Microelectronics comenta sobre la importancia de considerar estos problemas. Menciona la importancia de las técnicas que comparten recursos entre el final de a línea de producción y las pruebas en el campo, así como en el desarrollo adecuado de modelos de fallos para las tecnologías actuales de semiconductores.
En esta Edición
La Biblioteca digital de la IEEE Computer Society ofrece artículos interesantes que tratan diferentes aspectos de estos desafíos. Una solución que es incrementalmente utilizada en la industria es el empleo de pruebas funcionales; que fuerzan al sistema procesador objetivo a ejecutar software basado en auto comprobaciones (SBST, Software Based Self Test) que detecta los fallos en el procesador y en otros sistemas componentes. Esta solución es flexible, reduce los costos de hardware y posee una alta cobertura de defectos. Sin embargo, se presenta como invasiva en términos de la memoria requerida. En el artículo “MIHST Una Técnica de Hardware para la Auto Comprobación en Línea de Microprocesadores Embebidos”, de Pablo Bernardi y sus colegas, ofrece una solución que minimiza tales limitaciones en tanto que reduce el tiempo de comprobación e incrementa la cobertura de defectos.
Frecuentemente los sistemas embebidos incluyen componentes reconfigurables basados en arreglos de compuertas programables en el campo. Por lo cual es crucial comprobar la capacidad de estos componentes para trabajar correctamente en el campo. En el artículo “Estrategias de Comprobación para Arquitecturas Confiables Reconfigurables en Tiempo de Corrida”, Lars Bauer y sus colegas detallan tales comprobaciones. También discuten la diferencia entre la comprobación reconfigurable de componentes antes y después de que se haya programado.
La seguridad se ha ganado importancia creciente en los sistemas embebidos. En el artículo “Comprobación vs Seguridad: Pasado y Presente”, Ingrid Verbauwhede presenta un caso de comprobación que muestra como la salvaguardia y la seguridad podrían transformarse en objetivos contrapuestos. Sin embargo, ofrece posibles caminos de combinar las restricciones correspondientes.
Lecturas Adicionales
Varias ponencias recientes tratan las comprobaciones en el campo de las salvaguardias críticas en los sistemas embebidos. Una cuestión importante es la generación de programas de comprobación funcional adecuados para detectar fallos permanentes que ocurrirán durante la fase operacional. Estos programas apuntan no solo a los núcleos de CPU y sus componentes, sino también a otros componentes del sistema, tales como la memoria y los periféricos. En el artículo “Metodología de Software de Auto comprobación para Comprobaciones En Línea de Caches L1 en Arquitecturas Multihilos y Multinúcleos”, George Theodorou y sus colegas describen como escribir un programa de comprobación para detectar posibles fallos que afecten las caches L1 en las arquitecturas multi núcleo
De forma similar en el artículo “Sobre las Comprobaciones Funcionales de las Unidades de Predicción de Saltos”, Ernesto Sánchez y yo describimos una técnica para escribir programas que comprueben la unidad de predicción de saltos, (BPU), existente en la mayoría de los procesadores. Este enfoque requiere de información no detallada sobre la estructura de la BPU y solo se basa en los datos del manual del procesador.
El artículo de Felix Reimann y sus colegas; “Diagnósticos Avanzados: Integración SBST y BIST en las Arquitecturas Automotrices E/E”, es particularmente interesante. Muestra cómo integrar tanto la SBST como construir una técnica de Auto Comprobación (BIST), para alcanzar no solo la prueba sino también las capacidades de diagnóstico en los dispositivos automotrices.
Editor Invitado
Matteo Sonza Reorda lidera el Grupo CAD y s profesor en el Departamento de Ingeniería de Control y Computación en el Politécnico de Turín. Sus intereses de Investigación son comprobación y diagnóstico de circuitos digitales y sistemas y diseño de sistemas y circuitos digitales tolerantes a fallos. Sonza Reorda ha recibido su Doctorado en ingeniería de computación en el Politécnico de Turín. Es miembro Fellow del IEEE. Se lo puede contactar en matteo.sonzareorda@polito.it.