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


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


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


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


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


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

http://www.youtube.com/watch?v=kYUrqdUyEpI


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.


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ȱ


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


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


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


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


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


SPARK

• Subconjunto seguro de Ada … - para eliminar elementos ambigüedades y

comportamiento imprevisible • … con anotaciones

- para análisis estático de programas

17


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


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


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!


Ó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.


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


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


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


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


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)


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


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


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



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



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

SVF

Arquitectura de pruebas

38

OBC computadorinterfaz de operador

disco

RS-232otras interfaces

El entorno del sistema se simula en la SVF


UPMSat2 02 Softwarestr/proyectos/upmsat2/slides/02_Software.pdf · • Lenguaje de programación...

Documents

Transcript of UPMSat2 02 Softwarestr/proyectos/upmsat2/slides/02_Software.pdf · • Lenguaje de programación...