Curso: Diseño de alto nivel de controladores industriales

1. Curso: Diseño de alto nivel de controladores industriales Módulo 3 –Ingeniería de Sistemas EmbebidosTarea 3.2 –Ingeniería del Software embebido (SW) А. Petrov – PU, ECIT Department

2. Temasprincipales • Sistemasembebidos (ES) – características • Ingeniería del Software – comparación con programación del software y la ingeniería de sistema • Componentes del Software components de los SistemasEmbebidos (ES) • Principalesetapas del desarrollo del software para Sistemasembebidos (ES) • Calidad del Software • Sistemas de tiempo Real embebidos • Lenguajes de programación en Sistemasembebidos (ES)

3. ¿Quées un Sistema embebido? Unadefinición de uso general de los sistemasembebidosesque son dispositivosque se utilizan para controlar, supervisar o ayudar en la operación de equipos, maquinaria o planta. “Embebido” refleja el hecho de que son una parte integral del Sistema. En muchoscasos, su “arraigo” puedesertalquesupresenciaestálejos de serevidente para el observador casual. Instituto de IngenieríaEléctrica (IEE)

4. Características de los sistemasembebidos(1) • Características básicas: • Número limitado de funciones predefinidas para ejecutar; • Fuente de alimentación limitada y la administración de energía efectiva; • Disponibilidad de recursos de reserve para situaciones inesperadas. • Funcionamiento en tiempo real (con mayor frecuencia); • Periféricos anchos e interfaces • Interfaces: • Interfaces de operador (Interfaces Máquina-Hombre - HMI) – teclados, monitores, interruptores, botones, indicadores emisores individuales o grupales de los diferentes tipos de señales, motores eléctricos, solenoides y otros. • Interfaces eléctricas (interfaces con otros components y dispositivos) Interno - I2C, SPI, ISA y otros. • Externos - RS232, TTY, Ethernet, Centronics, FlexRay, CAN, LIN, RF y otros

5. Características de los sistemasembebidos(2) • Plataforma de sistemas embebidos: • Microprocesador (MP o P) y los microcontroladores (MCU), que tienen menos poder de cómputo, pero varios periféricos; • Arquitecturas - Von Neumann y Harvard; • Utilizan P y MCU - CISC (Complex Instruction Set Computer) y más a menudo RISC (Reduced Instruction Set Computer); • Las populares familias de procesadores RISC: ARC (ARC International), ARM (ARM Holdings), AVR (Atmel), PIC (Microchip), MSP430 (TI) y otros; • CISC CPUs: Intel y Motorola; • Por lo general en el interior hay una memoria cache y procesamiento de la canalización de instrucciones; • Memoria para datos e instrucciones: RAM, PROM - OTP (Programable de una sola vez), EEPROM o memoria Flash; • Periféricos: Propósito general Entrada /Salida - GPIO, temporizadores, ADC, DAC y más.

6. Características de los sistemasembebidos(3) • Comunicación: • RS-232, RS-422, RS-485, UART / USART (Receptor / Transmisor universal síncrono y asíncrono); • I2C (Inter-Integrated Circuit – Circuito integrado), SPI (Serial Peripheral Interface Bus – Bus de la interfaz de periféricos serie), SSC and ESSI (Enhanced Synchronous Serial Interface – Interfaz mejorada serie síncrona), USB (Bus Universal en serie); • Protocolos de comunicación de red: Ethernet, CAN (Controller Area Network – Controlador del área de red), LonWorks etc. • Software: Popular OS – QNX4 RIOS, Linux embebido y Linux-based (Android, etc.), iOS, Windows CE, etc. • Herramientas para probar y corregir (depuración) • JTAG (Joint Test Action Group) – una interfaz especializada para la prueba saturada PCB; • ISP (In-System Programming) – Programación de circuito; • ICSP (circuito de programación en serie) – un método para la programación directa del microcontrolador, por ejemplo, de la serie PIC y AVR; • BDM (Modo de depuración de fondo) – utilizado principalmente en productos de Freescale; • IDE (Integrated Development Environment- Entorno de desarrollo integrado) – para el desarrollo de programas.

7. Sistemasembebidos: Ejemplos

8. Ingeniería del Software • Ingeniería del Software (SE): la aplicación de un enfoque disciplinado cuantificable sistemático, con el diseño, desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques; • Es decir, la aplicación de la ingeniería del software. • El plazo es de 45 años: conferencias de la OTAN • Garmisch, Alemania, 7-11 octubre, 1968 • Roma, Italia, 27-31 octubre, 1969 • La realidad está finalmente empezando a llegar • La informática como base científica • ¿Otras bases científicas? • Muchos aspectos se han hecho sistemáticos: • Métodos / metodologías / técnicas • Lenguajes • Herramientas • Procesos - Instrumentos

9. ¿Porquéestasdificultades? • SE esunamarcaúnica de la ingeniería • El Software esmaleable • La construcción del Software eshumano-intensivo • El Software es intangible • Problemas del Software son complejos sin precedentes • El Software dependedirectamente del hardware. • Está en la parte superior del Sistema de ingeniería “cadenaalimentaria” Las soluciones del software requieren rigor inusual • El software tienecarácteroperativodiscontinuo

10. Ingeniería del software ≠ Programación del Software • Programación del Software • Desarrollador individual • Aplicaciones de “juguete” • Esperanza de vida corta • Pocos actores o actores individuales • Arquitecto = Desarrollador = Gerente = Tester = Cliente = Usuario • Uno de un Sistema tipo • Construido desde cero • Mantenimiento mínimo

11. Ingeniería del software ≠ Programación del Software • Ingeniería del software • Equipos de desarrolladores con multiples funciones. • Sistemas complejos • Vida útil indefinida • Numerosos grupos interesados • Arquitecto ≠ Desarrollador ≠ Gerente ≠ Tester ≠ Cliente ≠ Usuario • Las familias del sistema • Reutilizar para amortizar costes • Mantenimiento representa más del 60% de los costos generales de desarrollo

12. Ingeniería del software ≠ Programación del Software • Ingeniería de sistemas • Campo interdisciplinario de la ingeniería que se centra en cómo los proyectos complejos de ingeniería deben ser diseñados y gestionados; • Se ocupa de todos los aspectos del desarrollo del Sistema informático; • Identifica las funciones de hardware, software, personas, bases de datos y otros elementos del Sistema que participan en ese Sistema que se va a desarrollar. • Ingeniería del software • Es una parte de la ingeniería de sistemas a nivel de usuario • Decir los aspectos prácticos del desarrollo y distribución de software útil.

13. Aspectos de gestióneconómica y de SE • La produccion de software = mantenimiento + desarrollo (evolución) • Costes de mantenimiento > 60% de todos los costs de desarrollo • 20% correctivo • 30% adaptativo • 50% perfectivo • Desarrollo más rápido no siempre es preferible • Mayores costos por adelantado pueden sufragar los costos aguas abajo. • Software mal diseñado / implementado es un factor de coste crítico.

14. Componentestípicos de software embebido Casi idéntico a los sistemas generales informáticos Software de aplicación Controlador de dispositivo 14

15. Componentestípicos de software embebido(cont.) • Middleware – ¿Qué es? • Middleware es un software que ha sido extraído de la capa de aplicación por una variedad de razones. Una de las razones es que ya puede ser incluido como parte del paquete del Sistema operativo fuera de la plataforma OS. • Otras razones para eliminarlo de la capa de aplicación son: permitir la reutilización en otras aplicaciones, para reducir costes o el tiempo de desarrollo mediante la compra off-the-shelf a través de un proveedor de terceros, o para simplificar el código de la aplicación. • En los términos más generales, el software middleware es el software del Sistema que no es el núcleo OS del Sistema operativo, controladores de dispositivos, o software de aplicación. • A continuación se muestra el middleware en el Modelo de Sistemas Embebidos (ver más en http://www.eetimes.com/document.asp?doc_id=1276764 15

16. Interfaz de Usuario Analog o/p Analog i/p AnalógicoFront End D/A, Aislamiento MódulosInterfazUsuario Digital i/p Digitali/p Ports Digital o/p Digitalo/p Puertos interrupciones Soporte: Temporizador de guarda ENTRADAS SALIDAS CPU Comms: ASC, SSC,USB, IIC, IrDA, etc. Bus de datos Bus de direcciones Memoria De datos Memoriade programa Links A otrossistemas 16

17. Desarrollo del ciclo de vida de software. ModeloCascada Requisitos Diseño Implementación Integración Validación Despliegue

18. Desarrollo de ciclo de vida de software. Modeloespiral Evaluaralternativas, identificar, solucionarriesgos, desarrollarprototipos Determinarobjetivos, alternativas, limitaciones Desarrollar, verificar los productos del siguientenivel Planificarlassiguientesfases

19. Hardware-Software Co-Diseño de SistemasEmbebidos El Software que basa su funcionalidad en los productos embebidos de hoy causan retrasos en la completitud de los proyectos si se tiene que esperar al prototipo de hardware para empezar el desarrollo de software y su depuración. Diseño concurrente y verificación de hardware y software es una tendencia que reduce el tiempo de lanzamiento al mercado. (ver más en [4, 5] )

20. Requisitos • Problema de definición→Especificación de requisitos • Determinarexactamentequéquiere el cliente y el usuario. • Desarrollar un contrato con el cliente • Especificarquéva a hacer el software de producto • Dificultades • El clientesolicita el productoque no esadecuado • El clienteno conoce el software • Las especificaciones son ambiguas, inconsistentes e incompletas.

21. Arquitectura/Diseño • Especificación de requisitos→ Arquitectura/Diseño • Arquitectura: descomponer el software en módulos con interfaces • diseño: desarrollo de las especificaciones del módulo (algoritmos, tipos de datos) • Mantener un registro de las decisiones de diseño y trazabilidad • Especifica cómo el product de software hace sus tareas. • Dificultades • La falta de comunicación entre los diseñadores de módulos • El diseño puede ser incoherente, incompleto y ambiguo.

22. Arquitectura vs. Diseño[Perry & Wolf 1992] • La Arquitectura tiene que ver con la selección de los elementos arquitectónicos, sus interacciones y las limitaciones de los elementos y sus interacciones necesarias para proporcionar un marco en el que se cumplan los requisites y que sirva como base para el diseño. • El diseño se ocupa de la modularización y las interfaces detalladas de los elementos de diseño, sus algoritmos y procedimientos, y los tipos de datos necesarios para apoyar la arquitectura y para satisfacer los requisitos.

23. ImplementacióneIntegración • Diseño → Implementación • Implementar módulos; verificar que cumplen con sus especificaciones • Combinar módulos de acuerdo con el diseño • Especifica cómo el product de software realiza sus tareas • Dificultades • Errores de interacción del módulo • Orden de integración puede influir en la calidad y la productividad

24. Desarrollobasado en componentes • Desarrollar components generalmente aplicables de un tamaño razonable y reutilizarlos a través de sistemas. • Asegurarse de que son adaptables a los diferentes contextos • Extender la idea más allá del código en el desarrollo de otros artefactos • Pregunta: ¿Qué viene primero? • Integración, a continuación despliegue • Despliegue, a continuación integración

25. Diferentes componentes • Software de terceros “piezas” • Los Plug-ins de efectos/ complementos • Applets • Frameworks • Sistemas abiertos • Infraestructuras de objetos distribuidos. • Documentos compuestos • Los sistemas heredados

26. Verificación y validación • ¿Quéesverificación y validación? • VerificaciónLa verificaciónconfirmaque el trabajo de los productosreflejanadecuadamente los requisitosprescritos para los mismos. En otraspalabras, la verificaciónaseguraque “el product se ha construidocorrectamente” • ValidaciónLa validaciónconfirmaque el product, según lo previsto, cumplirá con suusoprevisto. En otraspalabras, la validaciónaseguraque “has construido lo correcto”.

27. Verificación y validación ¿Cómo actúa? • Modelo de desarrollo de sistema

28. Calidades de Software • Exactitud • Óptima calidad • establecido w.r.t., la especificación de los requisitos • absoluta • Confiabilidad • Propiedad estadística • Probabilidad de que el software funcionará como se esperaba durante un período de tiempo dado • Relativo • Robustez • Comportamiento “razonable” en circunstancias imprevistas • subjectiva • Un requisito especificado es un problema de la corrección;un requisito no especificado es un problema de robustez.

29. Calidades de software (cont.) • Usabilidad • Capacidad de que los usuarios finales puedan utilizer fácilmente el software • Extremadamente subjetivo. • Comprensibilidad • Capacidad de los desarrolladores a entender fácilmente los artefactos producidos • La calidad interna del producto • subjetivo • Verificabilidad • La facilidad de establecer las propiedades deseadas • Realizado por análisis formal o pruebas • Calidad interna • Rendimiento • Equiparado con la eficiencia • Evaluables mediante la medición, el análisis y simulación.

30. Calidades de Software (cont.) • Desarrollo • Posibilidad de añadir o modificar la funcionalidad • Aborda el mantenimiento adaptativo y perfectivo. • problema: La evolución de la implementación es muy fácil • La evolución debe comenzar en los requisitos o en el diseño • Reutilización • Capacidad de construir un Nuevo software a partir de piezas existentes • Debe ser planificado • Ocurre a todos los niveles: desde la gente a los procesos, desde los requisitos hasta el código. • Interoperabilidad • Capacidad de los (sub)sistemas de software a cooperar con los demás • Fácilmente integrable en sistemas más grandes. • Técnicas communes que incluyen APIs, protocolos plug-in, etc.

31. Calidad de software (cont.) • Escalabilidad • Capacidad de un Sistema de software para crecer en tamaño, mientrasquemantienesuspropiedades y cualidades. • Asume el mantenimiento y la capacidad de evolucionar • Objetivo de desarrollobasado en componentes • Heterogeneidad • Capacidad de componer un Sistema de piezasdesarrolladas en varioslenguajes de programación, en multiples plataformas, por multiples desarrolladores, etc. • Necesario para la reutilización. • Objetivo de desarrollobasado en componentes Portabilidad • Capacidad de ejecución en entornosnuevos con un mínimoesfuerzo. • Puedeserplaneadomediante el aislamiento de componentesdependientes del entorno. • Necesarios para la aparición de los sistemasaltamentedistribuidos (porejemplo, Internet)

32. Evaluarcalidades del software • Las calidades deben ser medibles • La medición require que las calidades sean definidas de forma precisa • La mejora requiere una medición precisa • Actualmente la mayoría de las calidades se definen de manera informal y son difíciles de evaluar

33. Ingeniería del Software “Axiomas” • La adición de desarrolladores a un proyecto probablemente resultará en más retrasos y acumulación de costes. • Tensión básica de la ingeniería de software • Mejor, más barato, más rápido – elegir cualquiera de los dos¡ • Funcionalidad, escalabilidad, rendimiento – elegir cualquiera de los dos¡ • Cuanto más dura un fallo en el software • Mayores son los costes de la detección y corrección del fallo • Menos probable es que sea debidamente corregido • Hasta el 70% de todos los fallos detectados en los proyectos de software a gran escala se introducen en los requerimientos y el diseño • La detección temprana de las causas de los fallos puede reducir sus costos resultantes por un factor de 100 o más.

34. Despliegue y evolución • Operación → Cambio • Mantener el software durante / después de la operación del usuario • Determinar si el product todavía funciona correctamente • Dificultades • Diseño rígido • Falta de documentación • Rotación de personal

35. Principios de la Ingeniería del Software • Rigor y formalidad • La separación de los asuntos de interés • Modularidad y descomposición • Abstracción • Anticipación del cambio • Generalidad • Incrementalidad • Escalabilidad • Composicionalidad • Heterogeneidad

36. Arquitectura del Software • Arquitectura del Software es la organización fundamental de un Sistema, dentro de suscomponentes, lasrelaciones entre sí y con el entorno, y los principiosquerigensudiseño y evolución. • La arquitectura del Software abarca el conjunto de decisionesimportantessobre la organización de un Sistema de software • Selección de los elementosestructurales y sus interfaces por los que se compone un Sistema. • Comportamientocomo se especifica en lascolaboraciones entre esoselementos. • Composición de estoselementosestructurales y de comportamiento en subsistemasmásgrandes. • El estiloarquitectónicoqueguíaestaorganización

37. Arquitectura del software Embebido • Estructura de Software y la complejidad de un Sistema embebido pueden variar significativamente según la aplicación • Las arquitecturas de software de uso general incluyen: • Lazos de control simples • Interrupción del Sistema controlado • Sistema multitarea no preferente • La multitarea preventive o multi-threading (incluye los sistemas operativos en tiempo real – RTOS) • Microkernels - micronúcleos (un paso adelante respecto a un RTOS para incluir la asignación de memoria, sistemas de archivos, etc) • Kernel Monolitico (un relativo gran kernel con capacidades sofisticadas, se adaptan a un entorno embebido). Linux embebido y Windows CE Móviles y embebidos son algunos ejemplos.

38. Sistemasoperativosembebidos • Tradicional OS • Grandesrequerimientos de memoria • Arquitecturamultiamenazas • Modelo I/O (entrada/salida) • Núcleo y separación de usuario • No hay restricciones de energía • Ampliosrecursosdisponibles • Característicasdeseadas para EOS • Huella de memoriapequeña • Computoeficiente • Protocolos de comunicación • Interfazfácil de exponerdatos • Apoyar el diseño de aplicacionesdiversas • Forma fácil de programar, actualizar y depuraraplicaciones de red.

39. Algunossistemasoperativosintegrados • RTOSs • pSOS • VxWorks • VRTX (Versátil en tiempo real) • uC/OS-II • Java RTS etc. • Palm OS (fuente: Wikipedia) • Sistema operative embebido desarrollado inicialmente por U.S. Robotics-owned Palm Computing, Inc. para asistentes digitales personales (PDAs) en 1996 • SymbianOS (fuente: Wikipedia) • Sistema operativo diseñado para dispositivos móviles por SymbianLtd. (se ejecuta generalmente en OMAP (Plataforma de aplicaciones multimedia abierta) procesadores, los cuales generalmente incluyen un propósito general de arquitectura en el núcleo del procesador ARM más uno o más coprocesadores especializados. • Android • Projecto abierto Handset Alliance • Basado en núcleo Linux 2.6 (http://code.google.com/android/)

40. Algunossistemasoperativosembebidos (cont.) • Windows CE (WinCE) (fuente: Wikipedia) • Sistema operativo de Microsoft para ordenadores minimalistas y sistemas embebidos • WinCE es un Sistema operative muy diferente, en lugar de una version abreviada del escritorio de Windows • Linux embebido (uClinux, ELKS, ThinLinux) (fuente: Wikipedia) • El uso de un Sistema operativo Linux en sistemas informáticos integrados • Según la encuesta realizada por Venture Development Corporation, Linux fue utilizada por el 18% de los ingenieros • Versiones embebidas de Linux están diseñados para dispositivos con recursos relativamente limitados, tales como teléfonos móviles y decodificadores • Dado que los dispositivos integrados se utilizan para fines específicos en lugar de fines generales, los desarrolladores optimizan sus distribuciones de Linux embebido para conseguir las configuraciones de hardware específicas y las situaciones de uso.

41. Sistemasembebidos de tiempo Real • Los sucesos de procesos de sistemas de tiempo real. • Los eventos ocurridos en las entradas externas provocan el que otros eventos tengan lugar como salidas (outputs) • Minimizar el tiempo de respuesta suele ser un objetivo principal, o de lo contrario todo el Sistema puede dejar de funcionar correctamente. • Los tipos de sistemas embebidos en tiempo real • Tiempo real Estricto (Hard) — por ejemplo, sistemas de control de vuelos • Tiempo real Flexibles (Soft) — por ejemplo, Sistema de adquisición de datos. • Tiempo real (Real) — por ejemplo Sistema de guía de misiles • Tiempo real firmes (Firm)

42. Tipos de sistemas en tiempo real • Tiempo Real Estricto (Hard)– sistemas en los que es absolutamente imperativo que las respuestas ocurran dentro del plazo requerido. Por ejemplo: Sistemas de control de vuelo. • Tiempo Real Flexible – sistemas en los que los plazos son importantes pero que todavía funcionarán correctamente si se determinan plazos que ocasionalmente no se cumplan. • Por ejemplo: El Sistema de adquisición de datos. • Tiempo real (Real) – sistemas que son estrictos en tiempo real y su tiempo de respuesta es muy corto. Por ejemplo: Sistema de guía de misiles • Tiempo real Firme (Firm)– sistemas que son en tiempo real flexible pero en el que no haya beneficio de una entrega tardía del servicio. Un solo Sistema puede tener todos los subsistemas de tiempo real estricto, flexibles y reales. En realidad muchos sistemas tendrán una función de coste asociada con el incumplimiento de los plazos.

43. Arquitectura Prism en sistemasembebidos • Durante las últimas décadas los investigadores de software y profesionales han propuesto diversos enfoques, técnicas y herramientas para el desarrollo de sistemas de software a gran escala. Los resultados de estos esfuerzos han sido caracterizados como de programación a gran escala programming-in-the-large (PitL). • Un nuevo conjunto de desafíos que ha surgido con la aparición del barato, pequeño y heterogéneo, posiblemente integrado, altamente distribuido, así como las plataformas de computación móviles. Nos referimos al desarrollo del software en programación a pequeña escala programming-in-the-small-and-many (Prism).

44. Arquitectura Prism en sistemasembebidos (cont.) • Propiedades de Prism: Recursosmuylimitados • Potencialimitada • Ancho de bandabajo • Velocidad de la CPU lenta, memorialimitada • Tampañopequeño del display • Middleware • Desarrollado para apoyar la implementación de Arquitectura de Software en el entornog • Proporcionaconceptos de nivel de arquitectura • Componentes • Conector • Configuración • Eventos

45. Arquitectura Prism en sistemasembebidos (cont.) • Proporciona: • Flexibilidad • Eficiencia (Tamaño, velocidad, sobrecarga) • Escalabilidad (Número de componentes, conectores, eventos, hilos, dispositivos de hardware) • Extensibilidad (Soporterelativo a los nuevosdesarrollos) • Investigar los siguientestemas: • Límites de dispositivosmóviles (potencia, tamaño, memoria, ..) • Modelado • Análisis • Simulación • Prism estácaracterizadopor la compañía OS’s (Palm, Symbian) • Prism estárelacionado con la arquitectura del Software (arquitecturabasada en el desarrollo)

46. Prism – ejemplo de aplicación • TDS (Despliegue de Tropas y simulación) • Distribución del despliegue de personal • Cuartel general • Recopilainformación de campo y muestra el estado actual de campo de batalla • Red a través de enlaces seguros a PDA’s • Comandantes • Conectado a soldados • Dar órdenes a los soldados • Soldados • Versegmentos del campo de batalla y recibirórdenes • Mássobrelascaracterísticas PRISM, ver en: • http://sunset.usc.edu/~softarch/Prism/ y • Prism-MW – CS 795 / SWE 699, Sam Malek, Spring 2010

47. Programación de Sistemasembebidos • Normalmente se tiene que ser mucho más consciente de los recursos que se consumen en la programación de sistemas embebidos que los que son necesarios en los programas ordinaries • Tiempo • Espacio • Canales de comunicación • Archivos • ROM (Read-Only Memory) • Memoria Flash • … • Se debe tomar el tiempo para aprender acerca de la forma en que las características del lenguaje de programación se implementan para una plataforma en particular. • Hardware • Sistema operativo • Librería

48. Programación de Sistemasembebidos • Una gran cantidad de éste tipo de programación es: • Mirar con atención las características especializadas de un RTOS (Sistema Operativo en Tiempo Real) • El uso de un “entorno non-hosted” (que es una forma de decir “ un lenguaje de programación justo en lo alto (right on top) del hardware sin un Sistema operativo”) • Incluye (a veces complejas) arquitecturas de controladores de dispositivos • El trato directo con interfaces de dispositivos hardware • … • No entraremos en detalles aquí • Para eso están los cursos y manuales específicos.

49. Lenguajes de programación de sistemasembebidos • Lenguajes Hardware • Verilog y VHDL son los lenguajes más populares para la descripción del hardware y su modelización (ver las características de abajo)

50. Lenguajes de programación de sistemasembebidos (cont.) • Lenguajes de Software Lenguajes de Software describensecuencias de instrucciones para un proceso a ejecutar. Por lo tanto, la lista de la mayoría de lasinstruccionesimperativas se ejecutanpara comunicar a través de la memoria: un array de almacenamiento de localizacionesquemantienensusvalores hasta que son modificados. Los lenguajesmáspopulares son: Lenguajeensamblador, C, C++ y Java. Las características de estoslenguajes se muestran en la tabla de abajo.