UPMSat2 02 Softwarestr/proyectos/upmsat2/slides/02_Software.pdf · • Lenguaje de programación...
Transcript of UPMSat2 02 Softwarestr/proyectos/upmsat2/slides/02_Software.pdf · • Lenguaje de programación...
UPMSat2 Software embarcado
Alejandro Alonso Juan Antonio de la Puente
Juan Zamorano
ditUPM
UPMSat2 © 2014 STRAST UPM
Índice• Características del software embarcado
- sistema empotrado, tiempo real, integridad • Proceso de desarrollo
- estándares de la ESA • Especificación del sistema de software
- modos de funcionamiento • Validación y verificación
- ciclo de desarrollo en V • Requisitos tecnológicos
- herramientas de desarrollo y pruebas
2
UPMSat2 © 2014 STRAST UPM
Software embarcado• Hay funciones críticas que dependen del software
- categorías de criticidad del software - requisitos de alta integridad
• Hay requisitos de tiempo real- funciones que hay que ejecutar en un intervalo de
tiempo determinado ‣ no basta hacer lo correcto, hay que hacerlo a tiempo
• El software está empotrado (embedded) en otros sistemas
• La tecnología de software que se emplea está condicionada por los requisitos de alta integridad
3
UPMSat2 © 2014 STRAST UPM
Requisitos de tiempo real• Hay acciones que hay que ejecutar en intervalos de
tiempo determinados. Por ejemplo: - calibrar el sensor solar a las 1200 UT
(tiempo absoluto) - leer los magnetómetros cada 100 ms
(ejecución periódica) - entre la recepción de un mensaje y la del siguiente
deben transcurrir al menos 2 s (separación mínima)
- los mensajes deben procesarse antes de que pasen 500 ms desde su recepción (plazo)
4
UPMSat2 © 2014 STRAST UPM
Tiempo real estricto y flexible
• Requisitos de tiempo real estrictos (hard real-time) - es inaceptable que no se cumplan
‣ ejemplo: control de actitud
• Requisitos de tiempo real flexibles (soft real-time) - si no se cumplen el sistema funciona peor,
pero aún es aceptable ‣ ejemplo: envío de paquetes de telemetría que no son críticos
5
UPMSat2 © 2014 STRAST UPM
Requisitos de alta integridad
• Los fallos de un sistema informático pueden tener efectos indeseables
• Estos efectos sirven para clasificar el software según su grado de criticidad - mission critical
‣ un fallo puede poner en riesgo el éxito de la misión
- safety critical ‣ un fallo puede causar pérdidas de vidas humanas, heridas graves o
daños medioambientales inaceptable
6
UPMSat2 © 2014 STRAST UPM
Accidentes causados por el software
• Lanzador Ariane 5 (1996) - fallo de control de vuelo y
explosión a los 40 s - especificación incorrecta de la
plataforma inercial • Mars Pathfinder (1997)
- problemas de tiempo real, corregidos desde tierra
• Mars Climate Orbiter (1999) - destruido al entrar en la
atmósfera de Marte - problemas de navegación por
confusión de unidades
7
http://www.youtube.com/watch?v=kYUrqdUyEpI
UPMSat2 © 2014 STRAST UPM
Estándares http://www.dit.upm.es/~str/proyectos/upmsat2/documentacion/
• La Agencia Europea del Espacio (ESA) promueve estándares para el desarrollo de misiones espaciales
‣ ECSS – European Cooperation for Space Standardization
• Estándares para ingeniería de software ‣ ECSS-E-ST-40 Software Engineering ‣ ECSS-Q-ST-80 Space Product Assurance — Software
‣ ECSS-E-HB-40 Software Engineering Handbook
8
Categorías de criticidad según ECSS-Q-ST-80C
9
Category Definition
ASoftware that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Catastrophic consequences.
BSoftware that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Critical consequences.
CSoftware that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences.
DSoftware that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Minor or Negligible consequences.
UPMSat2 © 2014 STRAST UPM
Estándares en otros sectores
• Aviones: DO 178B/C • Automóviles: ISO 26262 • Ferrocarriles: IEC 61508/ EN 50129 • Centrales nucleares: IEC 61513
10
Procesos de software según ECSS-E-ST-40C
11
ECSSȬEȬSTȬ40C
ȱ6ȱM
archȱ2009ȱ
25ȱ
Figureȱ4Ȭ2:ȱOverview
ȱofȱtheȱsoftwareȱlifeȱcycleȱprocessȱ
UPMSat2 © 2014 STRAST UPM
Análisis de requisitos• Documento SSS — Software System Specification
- Funcionalidad - Restricciones - Entorno de funcionamiento - Carga útil - Requisitos - Verificación, validación e integración del sistema
• Los requisitos deben ser - completos - consistentes
12
UPMSat2 © 2014 STRAST UPM
Funciones del software embarcado
• Adquisición y procesado de telemetría (TM). • Descodificación y ejecución de órdenes remotas (TC) • Supervisión y control de la plataforma • Control y determinación de actitud (ADCS) • Adquisición de datos de mantenimiento (housekeeping) • Detección y tratamiento de fallos • Adquisición, gestión y almacenamiento de datos de la
carga útil • Registro de datos temporales
13
UPMSat2 © 2014 STRAST UPM
Funciones del software de tierra
• Cálculos de parámetros orbitales y tiempos de paso
• Determinación de la posición del satélite • Recepción, procesamiento y registro de datos de
telemetría (TM) • Entrada de órdenes de operador y envío al satélite
mediante mensajes de órdenes remotas (TC) • Gestión de la interfaz de operador
14
UPMSat2 © 2014 STRAST UPM
Restricciones
• Uso de estándares - ECSS-E-ST-40C y ECSS-Q-ST-80C - Unidades SI
• Software libre - GPL / LGPL
• Lenguaje de alto nivel fiable - Ada /SPARK
15
UPMSat2 © 2014 STRAST UPM
Ada• Lenguaje de programación para sistemas fiables
- promovido por el US DoD hacia 1980 - estándar actual: Ada 2012
• Estructura de bloques, tipado fuerte, excepciones • Punteros seguros y gestión de memoria fiable • Clases, herencia, despacho dinámico
- todo esto es opcional y separado de módulos • Plantillas genéricas, interfaces • Concurrencia y tiempo real
16
UPMSat2 © 2014 STRAST UPM
SPARK
• Subconjunto seguro de Ada … - para eliminar elementos ambigüedades y
comportamiento imprevisible • … con anotaciones
- para análisis estático de programas
17
UPMSat2 © 2014 STRAST UPM
Ejemplopackage Hello is task Say_Hello; — say “hello” every 1 send Hello;——————————————————————————————————————————-with Ada.Real_Time; use Ada.Real_Time;with Ada.Text_IO; use Ada.Text_IO;package body Hello is Period : constant Time_Span := Seconds(1);
task body Say_Hello is Next_Time : Time := Clock; begin loop Put_Line("hello"); Next_Time := Next_Time + Period; delay until Next_Time; end loop; end Say_Hello;end Hello;——————————————————————————————————————————-procedure Hello_Periodic isbegin null;end Hello_Periodic;
18
UPMSat2 © 2014 STRAST UPM
Entorno y carga útil
• Entorno de funcionamiento - Características del satélite - Características del OBC - Diagrama de contexto - Interfaces de hardware
• Carga útil - experimentos
20
UPMSat2 © 2014 STRAST UPM
Requisitos específicos• Funcionamiento del sistema
- modos de funcionamiento - órdenes remotas (TC) - telemetría (TM)
• Control de actitud (ADCS) • Supervisión de la plataforma (housekeeping) • Almacenamiento y registro de datos • Interfaces • Computador • Seguridad, fiabilidad, disponibilidad • Diseño y herramientas de software • Mantenimiento del software
21
Modos de funcionamiento en tierra
22
Land!
Off! Test!
Await_Launch!
Modos de funcionamiento en vuelo
23
Normal_operation!
Nominal! Experiment!TC!
timer | TC!
Inactive!
Launch! Latency!
low battery |error |!
TC!lost COMM!
separation timer!
TC!Checking!
Initialization! Commissioning!
latencytimer!
Degraded_operation!
lost COMM!
TC received!Safe! Beacon!
auto | timer!
watchdog timer!
critical battery!
TC!
UPMSat2 © 2014 STRAST UPM
Órdenes remotas (TC)
24
Requisitos DescripciónConfigure Modificación de los parámetros de configuración del software.Commission Pasa a modo de puesta en servicio.OpenLink Inicio de comunicación.Envía a tierra los datos:
- Estado de la plataforma (housekeeping) - Registro (logbook). - Estado de magnetopares (health table) - Reloj de misión (mission clock)
Nominal Pasa a modo nominal.Safe Pasa a modo seguro.Latency Pasa a modo de latencia.Logbook Envía a tierra del contenido del registro.Test Verificación para ensayos en tierra.
UPMSat2 © 2014 STRAST UPM
Medidas periódicas (housekeeping)
25
Requisitos DescripciónTemperaturas - Caras del satélite
- Baterías - Magnetómetros - Computador - Experimentos
Actitud - Medida magnetómetro - Salida magnetopares - Intensidad magnetopares
Energía - Tensión en bus - Tensión en batería - Tensión en paneles solares - Intensidad en batería - Intensidad en paneles solares
Períodos - Parámetros de configuración
UPMSat2 © 2014 STRAST UPM
Telemetría (TM)
26
Requisitos DescripciónTM periódica Datos de sistema (housekeeping)
Períodos: parámetros de configuración
TM de sucesos Cambios de modo Cambios de estado de baterías Otros
TM de petición Datos de sistema (housekeeping) Registro del sistema Tiempo de misión
TM de experimentos Datos de experimentos
UPMSat2 © 2014 STRAST UPM
Telemetría en distintas situaciones
27
Requisitos DescripciónTM sin cobertura Almacenar mensajes en registro
TM periódica (housekeeping)TM con cobertura Los nuevos mensajes se envían cuando se generan
El registro de mensajes se envía a tierra a petición Se distinguirán ambos tipos de mensajes
TM en funcionamiento degradadado
Modo seguro: sólo mensajes básicos
TM en comprobación Modo inicio o puesta en servicio: sólo mensajes inicialesTM en radiofaro Modo radiofaro: sólo mensaje de aviso periódico
UPMSat2 © 2014 STRAST UPM
Control de actitud
28
Requisitos DescripciónFunciones - Lectura de magnetómetros
- Cálculo de acción en magnetopares (algoritmo de control) - Emisión de señales de magnetopares
TC de ADCS - Sincronización del tiempo- Recepción de la posición del satélite - Órdenes para los sensores y actuadores - Configuración de magnetómetro - Configuración de sensores solares - Configuración de magnetopares - Actualización de efemérides - Actualización de parámetros de configuración del ADCS - Lectura de parámetros de configuración del ADCS
TM de ADCS - Envío de medidas de los sensores- Datos orbitales: actitud y posición orbital del satélite - Datos de estado del ADCS: campo magnético, posición solar, etc. - Parámetros de configuración del ADCS
Períodos - Lectura de magnetómetros - Control y accionamiento de magnetopares
UPMSat2 © 2014 STRAST UPM
Computador embarcado
29
Requisitos DescripciónCondiciones de arranque
- Apagado: al recibir alimentación - Encendido: señal reset en hardware
Acciones de arranque - Copia de código desde EEPROM a RAM - Comprobación de estado de los dispositivos - Ejecución en modo inicio
Temporizador de separación
- Realizado en hardware - Se activa en el momento de la separación - Al vencer el tiempo activa la alimentación del computador
Temporizador de latencia
- Realizado en hardware - Se activa al pasar al estado de latencia (batería baja) - Al vencer el tiempo activa la alimentación del computador
Temporizador de guardia (watchdog timer)
- Realizado en hardware - Se activa periódicamente desde el software - Si llega a cero hace un reset del computador
Reloj de misión - Mide el tiempo transcurrido desde la separación (hardware)
UPMSat2 © 2014 STRAST UPM
Validación y verificación• Validación
- comprobar que el sistema se comporta de la forma esperadabuild the right system
• Verificación- comprobar que el sistema implementa
correctamente la especificación - comprobar que los procesos de software se
llevan a cabo correctamente build the system right
30
UPMSat2 © 2014 STRAST UPM
Pruebas (tests)
• Tienen por objeto encontrar los fallos que pueda haber
• Hay que conseguir la mayor cobertura posible
• Problema: no se puede probar el software en el entorno real
• Software validation facility - entorno de pruebas
simulado
31
Espacio de ejecución
Espacio de prueba
UPMSat2 © 2014 STRAST UPM
Tipos de pruebas• Pruebas unitarias
- black box / white box • Pruebas de integración
- integración progresiva con stubs • Pruebas de regresión
- comprobar que al arreglar un fallo no hemos introducido otros
• Pruebas de sistema • Pruebas de aceptación
32
Ciclo de desarrollo en V
33
Subsistemas
Componentes
Código
Sistema
Mundo realcaptura de requisitos
análisis de requisitos
diseño arquitectónico
diseño detallado
implementación pruebas unitarias
integración de subsistemas
integración de sistema
pruebas de aceptación
operación y mantenimiento
UPMSat2 © 2013 STRAST UPM
UPMSat2 © 2014 STRAST UPM
Tecnología de software para UPMSat2
• Requisitos: texto y tablas • Diseño: TASTE
- basado en AADL ‣ Architecture Analysis Design Language
• Implementación: Ravenscar Ada - subconjunto seguro de Ada
‣ entorno de desarrollo/compilación GNAT/ORK+
• Pruebas unitarias: AUnit • Pruebas de integración y sistema: SVF
34
Arquitectura de ejecución
35
Hardware
ORK+Drivers
GNARL
Application software
UPMSat2 © 2013 STRAST UPM
UPMSat2 © 2014 STRAST UPM
Desarrollo alternativo• Sistema particionado sobre procesador
multinúcleo • Diseño: MultiPARTES
- basado en UML MARTE ‣ Unified Modelling Language - Modelling and Analysis of Real-Time
and Embedded Systems
• Implementación: Ravenscar Ada ‣ entorno de desarrollo/compilación GNAT/ORK+ / XtratuM
• Pruebas unitarias: AUnit • Pruebas de integración y sistema: SVF
36
Arquitectura particionada
37UPMSat2 © 2013 STRAST UPM
SVF
Arquitectura de pruebas
38
OBC computadorinterfaz de operador
disco
RS-232otras interfaces
El entorno del sistema se simula en la SVF
UPMSat2 © 2013 STRAST UPM
© ESA 2012 - PROBA V mission