PFC Victor Sanchez Munoz PDF

Escuela Técnica Superior de Ingenieros
Informáticos
Universidad Politécnica de Madrid
Desarrollo de un Sistema de
Registro Jurı́dico Ferroviario
Utilizando un Sistema Operativo
de Tiempo Real de Libre
Distribución
Proyecto Fin de Carrera
AUTOR: Vı́ctor Sánchez Muñoz

TUTOR/ES: Juan Zamorano Flores
Madrid, 06 de julio de 2018

i
Dedicatoria
A mis padres por darme el mejor regalo que a un hijo se puede dar, estar
orgulloso de vosotros, y por apoyarme siempre incondicionalmente.
Papa, estés donde estés, esto ya está chupado.

ii
iii
AGRADECIMIENTOS
Quiero agradecer muy especialmente
a mis padres, José y Maribel, porque sin ellos simplemente esto no hubiese sido
posible.
a mi mujer y pareja, Mónica, porque me acompaña y apoya siempre en este

largo camino que es la vida.
a mis hijas, Alicia y Julia, porque son la luz que guı́an mis pasos y mi orgullo
y nunca pierden la oportunidad de sorprenderme o sacarme la sonrisa.
a mi tutor, Juan, gracias por ayudarme a llevar esto a buen puerto.
Y en general, quiero dar las gracias a todos los que siempre han creı́do en mi
y en que este momento llegarı́a.
Muchas gracias.
iv
v
RESUMEN
El objetivo principal de este proyecto es el desarrollo de un sistema embebido de

tiempo real crı́tico del sector ferroviario, más concretamente un registrador jurı́dico.
Los registradores jurı́dicos ferroviarios son sistemas que almacenan información del
tren y eventos que ocurren en el mismo en tiempo real con propósitos legales, son
las llamadas cajas negras.
Los sistemas de tiempo real crı́ticos tienen una serie de caracterı́sticas especia-
les que los diferencian de los sistemas convencionales por lo que su desarrollo también
tiene ciertas particularidades y se desarrollan con una serie de metodologı́as ideadas
especialmente para este propósito. En este proyecto se describirán algunas de estas
metodologı́as y se mostrará como se realiza el desarrollo de un sistema de tiempo
real con la aplicación de estas metodologı́as.
Además, existe un objetivo secundario que es la implementación del sistema

basándose en un sistema operativo de distribución libre que cumpla con las ca-
racterı́sticas propias de un sistema operativo de tiempo real. Para este objetivo se
realizará un estudio y análisis previo de la oferta existente en el mercado de este
tipo de sistemas operativos y se elegirá el más adecuado para la implementación del
sistema.
vi
Índice vii
Índice
1. INTRODUCCIÓN Y OBJETIVOS . . . . . . . . . . . . . . . . . . . 1
1.1. Propósito y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Registrador jurı́dico Ferroviario . . . . . . . . . . . . . . . . . . . . . 2
1.3.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2. Registrador jurı́dico ferroviario . . . . . . . . . . . . . . . . . 3
1.3.3. Event Recorder de SEPSA . . . . . . . . . . . . . . . . . . . . 4
1.4. Definiciones, acrónimos y abreviaturas . . . . . . . . . . . . . . . . . 5
1.5. Contenido del documento . . . . . . . . . . . . . . . . . . . . . . . . 7
2. SISTEMAS EMBEBIDOS DE TIEMPO REAL . . . . . . . . . . . . 9
2.1. Caracterı́sticas de los sistemas de tiempo real . . . . . . . . . . . . . 9
2.2. Computación en tiempo real . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Sistemas operativos de tiempo real . . . . . . . . . . . . . . . . . . . 10
2.3.1. Caracterı́sticas de los sistemas operativos de tiempo real . . . 11
2.3.2. Distribuciones de sistemas operativos de tiempo real . . . . . 13
2.3.3. Linux de tiempo real . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4. RTLinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5. RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.6. Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4. Conclusiones en la elección del sistema operativo de tiempo real . . . 23
3. METODOLOGÍAS DE DESARROLLO SOFTWARE UTILIZADAS 25

viii Índice
3.1. Análisis Estructurado Moderno . . . . . . . . . . . . . . . . . . . . . 25
3.1.1. Modelo esencial . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2. Modelo de implantación del usuario . . . . . . . . . . . . . . . 26
3.2. HRT-HOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Paradigma estructurado . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4. Lenguaje C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5. Método en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4. ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA . . . . . . . . 33
4.1. Listado de los principales casos de uso del sistema . . . . . . . . . . . 34
4.2. Descripción detallada de los casos de uso del sistema . . . . . . . . . 35
4.2.1. Calcular los datos de odometrı́a . . . . . . . . . . . . . . . . . 35
4.2.2. Registrar los cambios de estado de las señales digitales del tren 36
4.2.3. Actualizar los indicadores leds del equipo . . . . . . . . . . . . 37
4.2.4. Visualizar el estado del sistema por el operador . . . . . . . . 38
4.2.5. Descargar el fichero de registro completo por el operador. . . . 38
4.3. Descripción detallada de los requisitos no funcionales del sistema . . . 39
4.3.1. Periodo de registro de las señales digitales . . . . . . . . . . . 40
4.3.2. Periodo de actualización del fichero de registro . . . . . . . . . 40
4.3.3. Capacidad del fichero de registro . . . . . . . . . . . . . . . . 41
5. ANÁLISIS DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . 43
5.1. Modelo ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1. Declaración de propósitos . . . . . . . . . . . . . . . . . . . . 43

Índice ix
5.1.2. Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3. Lista de acontecimientos . . . . . . . . . . . . . . . . . . . . . 44
5.2. Modelo de comportamiento . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.1. Nivel 01. Event Recorder . . . . . . . . . . . . . . . . . . . . . 46
5.2.2. Nivel 02. Odometry Management . . . . . . . . . . . . . . . . 47
5.2.3. Nivel 02. Time Management . . . . . . . . . . . . . . . . . . . 48
5.2.4. Nivel 02. External Interfaces Management . . . . . . . . . . . 49
5.2.5. Nivel 02. EVR Status Management . . . . . . . . . . . . . . . 50
5.2.6. Nivel 02. Record File Management . . . . . . . . . . . . . . . 51
5.2.7. Nivel 02. Configuration Management . . . . . . . . . . . . . . 53
6. DISEÑO DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1. Event Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1.1. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2. Date/Time Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3. Odometry Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4. Events Recording Manager . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
x Índice
6.5. IO Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.5.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6. Operator Communications Manager . . . . . . . . . . . . . . . . . . . 66
6.6.1. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.7. System Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.8. Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.8.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.8.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7. IMPLEMENTACIÓN DEL SISTEMA . . . . . . . . . . . . . . . . . 71
7.1. HRT HOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2. Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3. HRT HOOD, Xenomai y C . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.1. Objeto Activo . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.2. Objeto Cı́clico . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.3. Objeto Esporádico . . . . . . . . . . . . . . . . . . . . . . . . 74
7.3.4. Objeto Protegido . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.3.5. Objeto Pasivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8. VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA . . . . . . . . . . 77
8.1. Proceso de verificación . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Índice xi
8.2. Proceso de validación . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9. RESULTADOS Y CONCLUSIONES . . . . . . . . . . . . . . . . . . 79
9.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
xii Índice
Índice de cuadros xiii
Índice de cuadros
1. Términos, acrónimos y abreviaturas del proyecto. . . . . . . . . . . . 7

xiv Índice de cuadros
Índice de figuras xv
Índice de figuras
1. Arquitectura Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2. Interfaces RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Reglas de descomposición . . . . . . . . . . . . . . . . . . . . . . . . 27
4. Reglas de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Método en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7. DFD Nivel 01. Event Recorder . . . . . . . . . . . . . . . . . . . . . . 46
8. DFD Nivel 02. Odometry Management . . . . . . . . . . . . . . . . . 47
9. DFD Nivel 02. Time Management . . . . . . . . . . . . . . . . . . . . 48
10. DFD Nivel 02. External Interfaces Management . . . . . . . . . . . . 49
11. DFD Nivel 02. EVR Status Management . . . . . . . . . . . . . . . . 51
12. DFD Nivel 02. Record File Management . . . . . . . . . . . . . . . . 52
13. DFD Nivel 02. Configuration Management . . . . . . . . . . . . . . . 53
14. Event Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
15. Date/Time Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
16. Odometry Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
17. Events Recording Manager . . . . . . . . . . . . . . . . . . . . . . . . 59
18. Recording Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
19. Events Recording Supervision Manager . . . . . . . . . . . . . . . . . 60
20. IO Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
21. Digital Signals Manager . . . . . . . . . . . . . . . . . . . . . . . . . 62

xvi Índice de figuras
22. Analog Signals Manager . . . . . . . . . . . . . . . . . . . . . . . . . 63
23. MVB Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
24. Leds Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
25. Operator Communications Manager . . . . . . . . . . . . . . . . . . . 66
26. System Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . 67
27. Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 68

1
1. INTRODUCCIÓN Y OBJETIVOS
En este capı́tulo se proporcionará una descripción del propósito y el alcance del

proyecto y una declaración de los objetivos que persigue alcanzar la realización del
mismo. Además, este capı́tulo contendrá una introducción al sistema a desarrollar,
los registradores jurı́dicos ferroviarios, y una breve descripción de los contenidos del
documento.
1.1. Propósito y alcance
El propósito del proyecto que se desea realizar es desarrollar un sistema em-

bebido de tiempo real crı́tico, un registrador jurı́dico ferroviario, basándose en un
sistema operativo de tiempo real y distribución libre.
El primer problema que se tiene que resolver antes de comenzar con el desa-
rrollo es establecer cual será el sistema operativo de libre distribución que reúne
todas las condiciones necesarias para desarrollar un sistema embebido de tiempo
real crı́tico como es el caso del registrador jurı́dico ferroviario. Para ello se realizará
un análisis de la oferta actual respecto a sistemas operativos de tiempo real y se
llegará a la conclusión de cual será la mejor opción para el desarrollo del sistema.
Una vez tomada la decisión del sistema operativo a utilizar para desarrollar
el registrador jurı́dico, se realizará el desarrollo del sistema utilizando técnicas de
desarrollo software orientadas a sistemas embebidos y de tiempo real.
El desarrollo del registrador jurı́dico ferroviario se hará en el ámbito de una

empresa privada con una dilatada dedicación en el desarrollo de sistemas embebidos
ferroviarios, SEPSA, SL. Por este motivo, el presente documento contendrá infor-
mación de los procedimientos que se han utilizado para el desarrollo del sistema y
documentará en todo lo posible los productos generados en el desarrollo. Pero nun-
ca contendrá información que pueda perjudicar a la empresa, por ejemplo el código
fuente del sistema.
1.2. Objetivos
El objetivo de este proyecto fin de carrera es el desarrollo de un sistema de

tiempo real crı́tico utilizando un sistema operativo de libre distribución que cumpla
con los requisitos de un sistema operativo de tiempo real. El sistema que se desea
desarrollar en este caso es un registrador jurı́dico ferroviario y las opciones que se
2 1 INTRODUCCIÓN Y OBJETIVOS
van a estudiar para la elección del sistema operativo serán distribuciones de Linux
adaptadas a necesidades de sistemas de tiempo real.
Además del objetivo principal, también se deberá validar que las caracterı́sti-
cas que proporciona el sistema operativo elegido cumplen con las expectativas del
sistema operativo que se busca para el desarrollo del sistema mencionado.
Las caracterı́sticas que se buscan para el sistema operativo que se quiere utilizar
para el desarrollo del registrador jurı́dico ferroviario son las siguientes:
Sistema operativo de libre distribución. Además de ser gratuito, disponer del

código fuente para su manipulación y permitir ser comercializado el sistema
desarrollado, también se busca que proporcione un soporte garantizado por
una amplia comunidad de desarrolladores.
Sistema operativo de tiempo real. El sistema operativo debe cumplir con todas
las caracterı́sticas propias de un sistema operativo de tiempo real: determinis-
mo, sensibilidad, fiabilidad, control de usuario, tolerancia de fallos, tiempo
compartido.
Plataforma de desarrollo sencilla. El desarrollo de sistema de tiempo real en

el sistema operativo seleccionado debe tener una complejidad baja respecto a
la complejidad de desarrollarlo en un sistema Linux convencional.
Una vez terminado el estudio de los sistemas operativos de tiempo real del
mercado basados en Linux, se deberá concluir cual será el elegido para desarrollar
el sistema del registrador jurı́dico y los motivos por los que se ha seleccionado.
Por último, se deberá desarrollar el sistema del registrador jurı́dico ferroviario,

el cual es un sistema embebido de tiempo real crı́tico.
1.3. Registrador jurı́dico Ferroviario
El registrador jurı́dico o caja negra es un dispositivo que se incorpora

normalmente en las aeronaves, trenes, barcos y naves espaciales; y cuya funcionalidad
principal es la de registrar tanto el estado del vehı́culo como las conversaciones de
los tripulantes en tiempo real. Los datos que almacena este sistema son analizados
en caso de accidente para conocer lo que ocurre en los momentos del accidente y
establecer las causas del mismo.
1.3 Registrador jurı́dico Ferroviario 3
1.3.1. Historia
A finales de los años 1950, se empezaron a utilizar los primeros registradores en

aeronaves y se les llamaron cajas negras, denominación que todavı́a perdura aunque
actualmente son de color naranja para facilitar su localización en caso de accidente.
Actualmente, estos dispositivos son obligatorios en la aviación comercial y

permiten explicar 9 de cada 10 accidentes de avión que ocurren.
El primer prototipo de este dispositivo se le adjudica al ingeniero francés Fran-

cois Hussenot en 1939. Esta consistı́a en una rudimentaria caja con film fotográfico y
calibrada con espejos que iba lanzando flashes y registrando de esta forma el historial
de vuelo.
Aunque la caja negra propiamente dicha es obra del australiano David Warren,
que en 1953 se le encomendó la tarea de descubrir la causa de una serie de accidentes
aéreos y para ello diseño un dispositivo de grabación de audio en la cabina del piloto.
En 1958, Warren diseño el primer prototipo de la Unidad de Memoria de Vuelo capaz
de grabar más de 4 horas de conversación de cabina y lecturas de mandos en una
bobina de acero magnetizado.
Actualmente, los registradores utilizan microcircuitos de memoria flash que

son capaces de almacenar datos durante años sin alimentación de energı́a. Estos
graban las últimas dos horas o treinta minutos, dependiendo del modelo, de todas
las conversaciones de cabina. Estas memorias se protegen con un blindaje de acero
grueso para resistir los impactos y aislante térmico para protegerlas de los incendios.
Las aeronaves comerciales llevan dos cajas: la grabadora de voces de cabina o

CVR (Cabin Voice Recorder - CDR) que recoge las conversaciones de la tripulación
de vuelo y los sonidos procedentes de la cabina; y el registrador de datos de vuelo
(Flight Data Recorder - FDR), que anota la altitud del aparato, su velocidad con
respecto al aire, su rumbo y otras lecturas instrumentales.
1.3.2. Registrador jurı́dico ferroviario
Las cajas negras de los trenes son similares a las de los aviones. Estas guardan
datos referentes al estado del tren como la velocidad, la aceleración, el estado de los
sistemas del tren, las balizas instaladas a lo largo del trazado, etc.
En general, el registrador jurı́dico del tren es una especie de tacógrafo que mide
y almacena todo lo que ocurre en el tren al menos una media hora antes.
1.3.3. Event Recorder de SEPSA
El Event Recorder (ER) es un sistema embarcado y grabador de datos del

tren que registra datos sobre las operaciones de control del tren y el rendimiento del
mismo en respuesta a esos controles y otros sistemas de control de trenes. El ER es
desarrollado y comercializado por la empresa SEPSA, SL.
El almacenamiento de datos es provisto por una memoria EEPROM no volátil

o una memoria flash sobrescrita en un bucle continuo FIFO. Los datos están des-
tinados para su uso en la investigación de accidentes e incidentes, pero también
se utilizan para controlar el estado general del tren durante un perı́odo de tiempo
determinado.
ER también es responsable de calcular la distancia recorrida, la velocidad real

del tren y cada información para el conductor.
El ER debe cumplir las siguientes caracterı́sticas:
Medida de la velocidad, la aceleración y la distancia recorrida por el tren.
Captura directa de variables discretas y analógicas a través de entradas fı́sicas.
Captura de variables discretas y analógicas a través de comunicaciones.
Control de niveles de velocidad y activación de las salidas de relés correspon-

dientes.
Registro cronológico de eventos, velocidad del tren, distancia, fecha y hora

para fines legales.
Análisis y visualización de los eventos grabados.
Creación de una copia completa del registro de la memoria protegida en una

memoria flash no volátil y sin bloqueo para una extracción más rápida y un
mayor control temporal.
Soporte para la interfaz de extracción mediante la inserción de un dispositi-

vo tipo Pendrive compatible con USB, con autenticación de dispositivo por
algoritmo de validación.
Configuración de parámetros funcionales.
Operaciones de autochequeo.
Reloj de tiempo real.
Mejora de la resistencia a choques mediante un módulo de memoria reforzado.

1.4 Definiciones, acrónimos y abreviaturas 5
1.4. Definiciones, acrónimos y abreviaturas
En esta sección se definirán los términos, acrónimos y abreviaturas del proyec-

to.
Término Definición
ADC Analog-to-Digital Converter (Convertidor
Analógico Digital)
ADEOS Adaptive Domain Environment Operating Sys-
tems
ALGOL Algorithmic Language (lenguaje algorı́tmico)
ANSI American National Standards Institute (Instituto
Nacional Estadounidense de Estándares)
API Application Programming Interface (Interfaz de
Programación de Aplicaciones)
ASIL Automotive Safety Integrity Level (Nivel de Inte-
gración de Seguridad de Automoción)
ATC Asynchronous Transfer Control (Control de Trans-
ferencia Ası́ncrona)
BCPL Basic Combined Programming Language (Lengua-
je de Programación Básico Combinado)
CAN Controller Area Network (Controlador del Área de
Red)
CVR Cabin Voice Recorder (Registrador de Voces de
Cabina)
CPU Central Processing Unit (Unidad Central de Pro-
cesamiento)
CRC Cyclic Redundancy Check (Verificación de Redun-
dancia Cı́clica)
DSP Digital Signal Processor (Procesador Digital de
Señales)
EEPROM Electrically Erasable Programmable Read-Only
Memory (Memoria de Sólo Lectura Programable
y Borrable Eléctricamente)
ER Event Recorder (Registrador de Eventos)
FDR Flight Data Recorder (Registrador de Datos de
Vuelo)
FIFO First In, First Out (Primero en Entrar, Primero en
Salir)
GPL General Public License (Licencia Pública General)
GPS Global Positioning System (Sistema de Posiciona-
miento Global)
HAL Hardware Abstraction Layer (Capa de Abstracción
de Hardware)
HOOD Hierarchical Object Oriented Design (Diseño
Jerárquico Orientado a Objetos)
HRT Hard Real-Time (Tiempo Real Crı́tico)
HW Hardware
I2C Inter-Integrated Circuit (Circuito InterIntegrado)
IEC International Electrotechnical Commission (Comi-
sión Electrotécnica Internacional)
I/O Input/Output (Entrada/Salida)
IP Internet Protocol (Protocolo de Internet)
IPC Inter-Process Communication (Comunicación En-
tre Procesos)
ISO International Organization for Standardization
(Organización Internacional de Normalización)
MVB Multi-Vehicle Bus (Bus Multi-Vehı́culo)
MRE Memoria Regurizada EEPROM
MUP Multi-UniProcessor (Multi-UniProcesador)
N/A No Aplica
OS Operating System (Sistema Operativo)
PC Personal Computer (Computadora Personal)
PDA Personal Digital Assistant (Asistente Digital Per-
sonal)
PFC Proyecto Fin de Carrera
PLC Programmable Logic Controller (Controlador
Lógico Programable)
PL/I Programming Language 1 (Lenguaje de Programa-
ción 1)
POSIX Portable Operating System Interface (Interfaz
Estándar del Sistema Operativo)
RT Real-Time (Tiempo Real)
RTAI Real Time Application Interface (Interfaz para
Aplicaciones de Tiempo Real)
RTOS Real-Time Operating System (Sistema Operativo
de Tiempo Real)
SEPSA Sistemas Electŕonicos de Potencia, S.A.
SI Sistemas Informáticos
SMP Symmetric Multi-Processing (MultiProceso
Simétrico)
SIL Safety Integrity Level (Nivel de Integración de Se-
guridad)
1.5 Contenido del documento 7
SPI Serial Peripheral Interface (Interfaz de Periféricos
Serie)
SRT Soft Real-Time (Tiempo Real No Crı́tico)
TCP Transmission Control Protocol (Protocolo de Con-
trol de Transmisión)
UP UniProcessor (UniProcesador)
USB Universal Serial Bus (Bus Serie Universal)
V&V Verificación y Validación
Tab. 1: Términos, acrónimos y abreviaturas del proyecto.
1.5. Contenido del documento
A continuación, se proporciona una visión general de los contenidos del docu-

mento. Para ello se describen brevemente los contenidos de cada capı́tulo del presente
documento.
Introducción y objetivos: En este capı́tulo se proporciona una descripción

del propósito y alcance del proyecto, de los objetivos a alcanzar y una breve
introducción del sistema a desarrollar, los registradores jurı́dicos ferroviarios.
Sistemas embebidos de tiempo real: En este capı́tulo se introducen los

conceptos básicos de los sistemas embebidos de tiempo real, se describen las
caracterı́sticas básicas de los sistemas operativos de tiempo real y se estudia
la oferta existente. Además, se exponen los criterios utilizados para la elección
del sistema operativo que se va a utilizar en el desarrollo del proyecto y la
decisión tomada.
Metodologı́as de desarrollo software utilizadas: En este capı́tulo se enu-

meran y se describen las principales metodologı́as de desarrollo software utili-
zadas para la ejecución del proyecto.
Especificación de requisitos del sistema: En este capı́tulo se enumeran y

describen brevemente los principales requisitos del sistema.
Análisis del sistema: En este capı́tulo se resumen los resultados obtenidos

en el desarrollo de la fase de análisis del proyecto.
Diseño del sistema: En este capı́tulo se resumen los resultados obtenidos en

el desarrollo de la fase de diseño del proyecto.
Implementación del sistema: En este capı́tulo se describe como se ha im-

plementado el sistema utilizando la metodologı́a HRT-HOOD y las librerı́as
de Xenomai.
Verificación y validación del sistema: En este capı́tulo se describe el pro-

ceso de verificación y validación utilizado en el proyecto.
Resultados y conclusiones: En este capı́tulo se redactan los resultados y

las conclusiones obtenidos después de ejecutar el proyecto.
9
2. SISTEMAS EMBEBIDOS DE TIEMPO REAL
Un sistema de tiempo real es un sistema informático que interacciona con

su entorno fı́sico y que además de cumplir correctamente con la funcionalidad para
la que está diseñado cumple con una serie de restricciones temporales. Es decir, no
solo sirve que el sistema realice las acciones a estı́mulos externos correctamente sino
que deben ejecutarse en un intervalo de tiempo determinado.
Los sistemas de tiempo real se pueden clasificar en sistemas de tiempo real

crı́tico, los tiempos de respuesta se deben respetar estrictamente y si no se cumplen
pueden traer consecuencias fatales; y sistemas de tiempo real acrı́tico, se pueden
tolerar retrasos en las respuestas del sistema.
Un sistema embebido o empotrado es un sistema diseñado para una fun-

cionalidad especı́fica y normalmente la mayorı́a de los componentes se encuentran
en la placa base. Ejemplos de sistemas embebidos serı́an un taxı́metro, el sistema
de control de acceso, la electrónica de una máquina expendedora o el sistema de
control de una fotocopiadora.
Una aplicación de tiempo real es una aplicación informática cuya funcio-

nalidad está sujeta a restricciones temporales impuestas por el entorno en el que se
ejecutan.
Los sistemas de tiempo real se aplican a sectores de nuestra vida diaria como
por ejemplo: los aviones, los trenes, los automóviles, los televisores, las lavadoras,
los hornos microondas, los teléfonos móviles o las centrales telefónicas digitales.
También, aseguran la generación, transmisión y distribución de la energı́a eléctrica
y la calidad y seguridad de incontables procesos industriales.
Los sistemas de tiempo real cumplen tres condiciones básicas: interactúan con
el mundo real (proceso fı́sico), emite respuestas correctas y cumple restricciones
temporales.
2.1. Caracterı́sticas de los sistemas de tiempo real
Determinismo: Esta es una cualidad esencial de los sistemas de tiempo real.

El determinismo es la capacidad de determinar con una alta probabilidad,
cuanto es el tiempo que se toma una tarea en iniciarse. Esto también se refiere
al tiempo que tarda el sistema en tratar una interrupción externa.
Responsividad: Esta caracterı́stica se refiere al tiempo que tarda el sistema

en ejecutar una tarea una vez iniciada por una interrupción.
10 2 SISTEMAS EMBEBIDOS DE TIEMPO REAL
Usuarios controladores: En los sistemas de tiempo real los usuarios, los

procesos, tienen un control mayor del sistema. Los procesos son capaces de
especificar su prioridad, la memoria que necesitan y los derechos que tienen
sobre el sistema.
Confiabilidad: Esta es otra caracterı́stica fundamental. El sistema además
de funcionar correctamente debe proporcionar una calidad de servicio deter-
minado y no degradarse más allá de un lı́mite determinado.
Operación a prueba de fallos graves: Si ocurre un fallo en el sistema, este
debe mantener la mayor parte de los datos y capacidades del sistema. Es decir,
que el sistema sea estable y sea capaz de cumplir con las tareas crı́ticas y mas
prioritarias por lo menos.
Estas caracterı́sticas especiales de los sistemas de tiempo real introducen en

la especificación del sistema una serie de requisitos no funcionales que especifican
estas caracterı́sticas. Estos requisitos no funcionales son los requisitos de fiabilidad,
eficiencia o implementación.
2.2. Computación en tiempo real
La computación en tiempo real está relacionada con sistemas informáticos

limitados por restricciones temporales.
Se podrı́an clasificar los sistemas de tiempo real como activos o crı́ticos, un fallo
en estos sistemas pueden ser fatales; y pasivos o no crı́ticos. Ejemplos de sistemas de
tiempo real crı́ticos podrı́an ser: el sistema que gestiona un motor de un coche, un
fallo en este puede causar un daño del motor; sistemas médicos como marcadores de
pasos artificiales; y los controladores industriales. Los sistemas no crı́ticos se utilizan
normalmente cuando hay acceso compartido a recursos que necesitan mantenerse
actualizados en un número de sistemas conectados. Ejemplos de sistemas pasivos
serı́a el sistema que gestiona los planes de vuelo de las compañı́as aéreas comerciales;
los sistemas de audio y vı́deo en directo.
Los sistemas operativos de tiempo real ofrecen el marco necesario para cons-
truir los sistemas de tiempo real.
2.3. Sistemas operativos de tiempo real
Un sistema operativo de tiempo real es un sistema operativo diseñado para

ejecutar aplicaciones de tiempo real, garantizando la correcta ejecución de estas
2.3 Sistemas operativos de tiempo real 11
cumpliendo con las restricciones temporales del sistema. Además, un sistema ope-
rativo de tiempo real debe proporcionar determinismo y hacer predecibles a las
aplicaciones de tiempo real que ejecuta.
2.3.1. Caracterı́sticas de los sistemas operativos de tiempo real
Las caracterı́sticas principales de los sistemas operativos de tiempo real son

las siguientes:
Utilización de poca memoria.
Los eventos de soportes fı́sicos se suelen tratar en tareas.
Multi-arquitectura.
Tiempos de respuestas predecibles.
Utilizados para sistemas embebidos generalmente.
Además, presentan una serie de requisitos especiales:
Determinismo.
Sensibilidad.
Control de usuario.
Fiabilidad.
Tolerancia de fallos.
Tiempo compartido.
Procesador
Los sistemas operativos de tiempo real no suelen tener una capacidad de pro-
cesamiento muy alta, esto se debe al algoritmo de planificación especializado y a la
tasa de interrupción de reloj elevada.
Además, para los sistemas de tiempo real se suelen utilizar procesadores lo

más predecibles posibles, premiando la fiabilidad de los viejos procesadores ante las
mejores prestaciones de los procesadores modernos.
Los sistemas operativos de tiempo real se utilizan también en microcontrola-

dores y procesadores digitales de señal ”DSP’s”.
Diseño
Existen dos diseños básicos:
Sistema operativo guiado por eventos. Solo cambia de tarea cuando un evento
necesita un servicio.
Sistema operativo con compartición de tiempo. Cambia de tarea por interrup-

ción de reloj y por eventos. Este diseño gasta más tiempo de procesador por
cambios innecesarios de tarea pero da una mejor ilusión de multitarea.
Planificación
Las tareas, normalmente, tienen tres estados posibles: ejecución, preparada y

bloqueada. La mayorı́a de las tareas están bloqueadas y solo se están ejecutando
una tarea por procesador en cada instante de tiempo. La gestión de estas listas de
tareas se realiza mediante interrupciones de muy corto tiempo. Para optimizar esto
se suelen ordenar por prioridades consiguiendo determinismo.
Comunicación entre tareas
La sincronización entre tareas se puede solucionar utilizando diferentes méto-

dos:
Semáforos. Los problemas con los diseños con semáforos son los siguientes:
inversión de prioridades (tareas más prioritarias están bloqueadas por tareas
menos prioritarias que poseen el semáforo) y puntos muertos (deadlocks) o
interbloqueos.
Mensajes. Tiene los mismos problemas que los semáforos: inversión de priori-
dades y puntos muertos.
Interrupciones
Principalmente, las interrupciones en los sistemas de tiempo real informan de

la ocurrencia de eventos en los mecanismos de comunicación con el mundo exte-
rior (puertos de comunicaciones, dispositivos de entrada y salida, etc) y son, por
naturaleza, impredecibles. Para que el sistema cumpla los requisitos de tiempo real
es necesario que las interrupciones sean atendidas antes de que suceda una nueva.
Para esto es necesario que los controladores de interrupciones se ejecuten en el me-

nor tiempo posible. Esto se consigue procesando la señal fuera de la interrupción,
activando una tarea en espera que se encarga de adquirir la información y procesarla
completamente.
Memoria
En los sistemas operativos de tiempo real existen dos problemas principalmente

con la gestión de memoria:
La velocidad de asignación de memoria. En un sistema convencional para la

gestión de asignación de memoria se utiliza una lista de longitud indetermi-
nada que debe ser recorrida hasta encontrar el primer bloque libre, esto no es
aceptable si debe ocurrir en un determinado tiempo fijo como en el caso de los
sistemas operativos de tiempo real.
La fragmentación de la memoria. Para solucionar esto se suele utilizar una

lista FIFO de bloques de memoria de tamaño fijo.
Además, la paginación en sistemas de tiempo real se suele desactivar, ya que

es recuso bastante aleatorio e impredecible que varia el tiempo de respuesta y no
asegura los plazos de respuesta.
Comunicaciones
Las comunicaciones que suelen usar los sistemas de tiempo real deben ser
deterministas y capaces de garantizar el tiempo de respuesta, para ello se utilizan
las conexiones CAN bus o puertos serie normalmente.
2.3.2. Distribuciones de sistemas operativos de tiempo real
A continuación, se van a enumerar y comentar las principales caracterı́sticas

de algunas distribuciones de sistemas operativos de tiempo real que están en el
mercado, tanto comerciales como de libre distribución.
Haiku
Haiku es un sistema operativo de código abierto centrado en la informática

personal y multimedia. El proyecto está dirigido por Haiku, Inc., una organización
no lucrativa situada en Nueva York.
El proyecto se inició en el 2001 con el nombre de OpenBeOS cuando la empresa

Palm compró a Be propietaria de BeOS y dejando a sus usuarios sin soporte. En el
2004, el proyecto cambio a su actual nombre para evitar los derechos de marca que
tenı́a Palm. Y en septiembre del 2009 se liberó la primera versión Alpha.
A continuación, se enumeran las caracterı́sticas básicas:
Micronúcleo modular propio, llamado NewOS, el cual está muy optimizado

para trabajar con contenidos multimedia.
Dispone de navegador propio basado en webkit, llamado Web+.
La arquitectura de su núcleo permite una gran capacidad para múltiples proce-

sadores, un alto rendimiento y un ancho de banda de entrada/salida modular.
Diseño multihilo de gran eficiencia.
APIs orientadas a objetos para un desarrollo rápido de aplicaciones y sistemas.
Compatibilidad con BeOS.
QNX
QNX es un sistema operativo de tiempo real de tipo Unix que cumple con la
norma POSIX y es desarrollado por la empresa canadiense QNX Software Systems,
que fue adquirida por BlackBerry en abril del 2010.
QNX es desarrollado principalmente para sistemas embebidos. QNX tiene una

arquitectura de micronúcleo que proporciona caracterı́sticas de estabilidad avanza-
das de memoria protegida frente a fallos de dispositivos, aplicaciones, etc.
El microkernel de QNX, llamado Neutrino, esta implementado en diferentes

versiones según su aplicación:
QNX Neutrino RTOS: La versión más completa para sistemas embebidos.

Es un microkernel real de arquitectura modular.
QNX OS for Safety: La versión está diseñada para cumplir las normas ISO
26262 en ASIL D y las normas IEC 61508 en SIL3. Se utiliza en sistemas
crı́ticos de automóviles, trenes y automatización industrial.
QNX OS for Medical: La versión está diseñada para cumplir las normas
IEC 62304. Se utiliza en sistemas crı́ticos médicos que requieren aprobaciones
regulativas.
QNX OS for Security: La versión está diseñada para cumplir las normas
ISO/IEC 15408 EAL 4.
RT-11
RT-11 es un pequeño sistema operativo de tiempo real, monousuario, para

la familia de computadoras de 16 bits PDP-11, de la empresa Digital Equipment
Corporation.
La primera versión de RT-11 fue implementada en 1970 y se empleó para

sistemas de tiempo real de control de procesos y adquisición de datos.
MaRTE OS
MaRTE OS es un sistema operativo de tiempo real para aplicaciones embebidas

basadas en POSIX. El proyecto se desarrolla por el Grupo de Computación y Tiempo
Real de la Universidad de Cantabria.
A continuación, se enumeran las caracterı́sticas principales del kernel:
Soporte de aplicaciones en el lenguaje mixto Ada, C y C++.
Servicios POSIX: hilos, exclusiones mutuas, variables condicionales.
Todos los servicios tienen un tiempo de respuesta limitado.
El espacio de direcciones de memoria individual compartida por la aplicación

multihilo y por MaRTE OS.
Licencia Pública General GNU 2.
LynxOS RTOS
LynxOS RTOS es un sistema operativo de tiempo real tipo Unix desarrollado

por LynuxWorks. Las primeras versiones se desarrollaron en 1986 en Dallas, Texas,
para el procesador Motorola 68010. La compatibilidad con Linux ha sido añadida
igual que la compatibilidad con muchas otras arquitecturas como Intel, ARM, MIPS
y PowerPC.
eCos
eCos es un sistema operativo de tiempo real embebido que funciona sobre varias
arquitecturas, entre ellas x86, PowerPC, MIPS o ARM. Es un sistema operativo
altamente configurable a nivel de código fuente y por lo tanto personalizable para

las necesidades particulares de cada aplicación.
Se comenzó a desarrollar por la empresa Red Hat, que en el 2004 delegó sus
derechos a la Free Software Foundation.
Las funcionalidades incluidas en el núcleo son las siguientes:
Capa de abstracción del hardware (HAL).
Kernel de tiempo real.
Manejo de interrupciones y excepciones.
Soporte de hilos, timers, contadores y alarmas.
Soporte de instrumentación y debug.
API compatible con uITRON 3.0 y POSIX.
Librerı́as de matemática e ISO C.
Drivers para puerto serie, ethernet, SPI, I2C, framebuffer, CAN, ADC, entre
otros.
Soporte de USB esclavo.
Pila para redes TCP/IP.
VxWorks
VxWorks es un sistema operativo de tiempo real de sistemas integrados y

embebidos, basado en Unix, vendido y fabricado por Wind River Systems.
Las principales caracterı́sticas de VxWorks incluyen un kernel multitarea con

planificador preemptive (los procesos pueden tomar la CPU arbitrariamente), res-
puesta rápida a las interrupciones, comunicación entre procesos, sincronización y
sistema de archivos.
El desarrollo de aplicaciones de VxWorks se realiza en un ”host”que ejecuta

Unix o Windows para ejecutarse en un ”target”.
Windows CE
Windows CE es un sistema operativo desarrollado por Microsoft para sistemas

empotrados.
Se puede encontrar en teléfonos inteligentes, computadoras portátiles, Pocket

PCs y GPS y, sobre todo, en la consola de videojuegos Dreamcast.
Symbian
Symbian es un sistema operativo propiedad de Nokia, y que en el pasado

fue producto de la alianza de varias empresas de telefonı́a móvil, entre las que se
encontraban Nokia, Sony Mobile Communications, Psion, Samsung, Siemens, Arima,
Benq, Fujitsu, Lenovo, LG, Motorola, Mitsubishi Electric, Panasonic, Sharp, etc. Sus
orı́genes provenı́an de su antepasado EPOC32, utilizado en PDA’s y Handhelds de
PSION. Estuvo vigente entre 1997 y el 2013.
El objetivo del Symbian era crear un sistema operativo para terminales móviles
que pudiera competir con el de Palm o el Windows Mobile de Microsoft y posterior-
mente Android de Google, iOS de Apple, Windows Phone de Microsoft y BlackBerry
OS de Blackberry.
BlackBerry OS 10
BlackBerry OS 10 es un sistema operativo propietario, desarrollado por Black-

Berry para su lı́nea de teléfonos inteligentes BlackBerry. Está basado en QNX el
cual fue adquirido por RIM en abril del 2010.
El BlackBerry OS 10 es un sistema operativo multitarea construido en el QNX

Neutrino RTOS. El sistema operativo implementa la cantidad mı́nima de software
en el espacio del núcleo y ejecuta otros procesos en el espacio de usuario. Mediante
la ejecución de la mayorı́a de los procesos en el espacio de usuario, el BlackBerry
OS 10 puede gestionar los procesos que no responden de forma aislada.
FreeRTOS
FreeRTOS es un sistema operativo de tiempo real para dispositivos embebidos

que soporta multitud de arquitecturas de microcontroladores. Está distribuido bajo
licencia GPL.
El diseño de FreeRTOS es pequeño y simple. Está implementado en C y es

fácilmente configurable para las distintas arquitecturas. FreeRTOS soporta múltiples
tareas, mutex, semáforos y software timers.
2.3.3. Linux de tiempo real
El sistema operativo Linux es muy utilizado en el diseño de sistemas embebidos,

ya que es un sistema operativo de código abierto y por lo tanto está soportado por
la comunidad de desarrolladores, es gratuito y accesible. Además, Linux es muy

personalizable y ofrece soporte a una amplia gama de arquitecturas de procesador
(ARM, x86, ...).
A pesar de los beneficios de Linux en el desarrollo de sistemas embebidos, no

es adecuado históricamente para sistemas que pretenden cumplir con los requisi-
tos de las aplicaciones de tiempo real y alto rendimiento. Desde el principio, los
desarrolladores de software embebido han propuesto numerosas soluciones a este
problema, sin embargo no existı́a un enfoque coherente y ampliamente aceptado
para el rendimiento de tiempo real de Linux.
Una de las soluciones adoptadas fueron las basadas en hypervisor, las cuales
ejecutan Linux junto con un RTOS más dedicado. El problema de estas soluciones
es que incrementan la complejidad del sistema en detrimento de la usabilidad y
demandan una mayor especialización de los equipos de diseño embebido perdiendo
la esencia de utilizar Linux.
Recientemente, ha surgido la alternativa para los diseñadores de sistemas em-

bebidos de ir anexando caracterı́sticas que mejoran el determinismo del propio kernel
de Linux mediante la aplicación de un conjunto de parches de PREEMPT RT, uni-
ficando de esta forma los criterios para mejorar el método de lograr el rendimiento
de tiempo real con Linux por parte de la comunidad Linux.
Un RTOS de Linux generado con el conjunto de parches de PREEMPT RT

permite un rendimiento de tiempo real al mismo nivel que otros RTOS dedicados.
Además, permite a los desarrolladores disponer de la accesibilidad, usabilidad y
soporte de una comunidad de un sistema operativo de propósito general. En gran
parte, esta mejora del rendimiento a nivel de aplicación es el resultado de la disponi-
bilidad de la programación de un sistema RTOS basado en Linux. A diferencia de la
mayorı́a de los RTOS dedicados, un RTOS basado en Linux puede ofrecer tanto un
programador de tiempo real para las tareas crı́ticas, como un programador mucho
más eficiente y completo para todas las tareas que no son de tiempo real.
2.3.4. RTLinux
RTLinux es una distribución de Linux de tiempo real que ejecuta Linux como
un hilo de menor prioridad que los hilos de tiempo real. Este diseño permite que
las tareas de tiempo real y los manejadores de interrupciones nunca se ejecuten a
destiempo por motivo de operaciones que no son de tiempo real.
RTLinux tiene la capacidad de ejecutar tanto las tareas de tiempo real y mane-
jadores de interrupciones como el Linux estándar en la misma máquina. Las tareas
de tiempo real como los manejadores de interrupciones ejecutan cuando se necesita
en detrimento de lo que estuviera ejecutando Linux.
La empresa Wind River actualmente es la propietaria de RTLinux.
RTLinux no es una distribución nueva de Linux, es un parche sobre el código

de Linux.
Historia
RTLinux nació del trabajo de Michael Barabanov y Victor Yodaiken en New

Mexico Tech, que posteriormente fundaron FSM Labs ofreciendo soporte técnico.
En febrero de 2007, Wind River adquirió FSM labs.
La primera versión se ejecutaba en la plataforma x86 y tenı́a una pequeña API

y un pequeño entorno de programación. La segunda versión fue totalmente reescrita
para dar soporte de multiprocesamiento simétrico (SMP) y para dar soporte a una
amplia variedad de arquitecturas.
RTLinux se distribuye bajo la ”GNU Public License”.
A partir del código de Yodaiken, se está desarrollando otro proyecto liderado

por P. Mantegazza llamado: Real Time Application Interface (RTAI).
En octubre del 2015 el proyecto pasa a estar tutelado por la Linux Foundation,
con la colaboración de compañı́as como Google, Intel, ARM, IBM, Qualcomm o
SanDisk entre otras para rescatar el proyecto.
Caracterı́sticas
Las caracterı́sticas principales de RTLinux son las siguientes:
Sistema operativo de tiempo real estricto.
Extensiones
2.3.5. RTAI
RTAI (Real Time Application Interface) es un parche de Linux para desarrollar

aplicaciones de tiempo real, basado en un principio en RTLinux y actualmente en
ADEOS. RTAI dispone de un pequeño núcleo de tiempo real bajo el núcleo estándar
de Linux y gestiona al núcleo de Linux como una tarea de menor prioridad.
Caracterı́sticas
Arquitectura: RTAI tiene una arquitectura similar a RTLinux, gestiona el

núcleo estándar de Linux como una tarea con la menor prioridad de ejecución.
Las interrupciones generadas por los periféricos son gestionadas por RTAI In-
terrupt Dispatcher, que encola las interrupciones para ser atendidas después
de las acciones de tiempo real. También dispone de un mecanismo de comu-
nicación entre procesos (IPC) y de un planificador diferentes para RTAI que
para Linux.
HAL – Hardware Abstraction Layer: Se utiliza el concepto de Real Ti-

me Hardware Abstraction Layer (RTHAL) para capturar las interrupciones
hardware y procesarlas después de las tareas de tiempo real.
Planificación: Siempre existe al menos una tarea ejecutando, el núcleo de

Linux, que se ejecuta como tarea de menor prioridad. Cuando se incluyen
tareas de tiempo real, estas son atendidas con mayor prioridad que la tarea de
Linux. Existen tres tipos de planificadores dependiendo del tipo de máquina:
uniprocesador (UP), multiprocesador simétrico (SMP) y multi-uniprocesador
(MUP).
Comunicación entre procesos (IPC): RTAI proporciona una gran variedad

de mecanismos de comunicación entre procesos, tanto de tiempo real como no,
similares a POSIX. Entre estos mecanismos se encuentran: FIFOs, semáforos,
memoria compartida y los mailboxes.
Gestión de memoria: En las primeras versiones de RTAI, la memoria se

asignaba estáticamente y no era posible asignarla en tiempo real. Actualmente,
RTAI gestiona la memoria dinámica en tiempo real basándose en un interfaz
similar al del estándar de C.
Threads POSIX: Se implementan de forma similar al estándar de POSIX

1003.1c, también se proporcionan servicios de mutex y variables de condicio-
nales.
2.3.6. Xenomai
Xenomai es un framework de desarrollo de tiempo real que coopera con el

kernel de Linux, para proporcionar un soporte de hard real time a las aplicaciones
que se ejecutan en el espacio de usuario, integrado en el entorno de Linux.
Xenomai se basa en un núcleo abstracto RTOS, este se utiliza para construir

cualquier tipo de interfaz de tiempo real sobre un núcleo, el cual exporta un conjunto
de servicios RTOS genéricos.
Xenomai se aplica en sistemas de control de máquinas (PLC), en máquinas

de impresión (manroland), en impresoras/copiadoras, en conmutadores de red (por
ejemplo, Ruggedcom), en tomógrafos de resonancia magnética (Siemens Healthcare),
en OROCOS (framework de robótica OSS), en proyectos de investigación robótica,
...
Historia
La primera versión de Xenomai (Xenomai 1.0) se lanzó en agosto del 2001 como
un framework de portabilidad para aplicaciones RTOS. En el 2003 se fusionó con el
proyecto de Real Time Application Interface (RTAI) para producir una plataforma
de software gratuita de tiempo real para Linux llamada RTAI/fusion. Esta versión
implementaba un tiempo real básico y desarrolló la capa ADEOS para Linux y
RTAI.
En el 2005, el proyecto Xenomai se independizó de RTAI, el motivo era que

los objetivos de diseño eran incompatibles. Esta versión (Xenomai 2.0) evolucionó
ADEOS a la capa I-pipe y fue portado a 6 arquitecturas diferentes.
La última versión (Xenomai 3.0) se lanzó en el 2015 después de más de 5 años

de desarrollo. Esta versión reimplementó el núcleo, antes se basaba en el kernel y
ahora se centraba en POSIX, y dio soporte al Linux nativo.
Caracterı́sticas
Xenomai se basa en una arquitectura que mantiene activos dos núcleos si-
multáneamente, el de tiempo real con las caracterı́sticas y recursos propios de un
sistema operativo de tiempo real y un núcleo Linux estándar que mantiene todas
las caracterı́sticas y recursos de Linux. Entre ambos núcleos existen mecanismos de
comunicación que preservan la predictibilidad que requieren los sistemas de tiempo
real.
Fig. 1: Arquitectura Xenomai

Existe una capa de virtualización, llamada ADEOS, que permite que coexistan
ambos núcleos interceptando las interrupciones del hardware y redirigiéndolas a am-
bos núcleos. ADEOS permite que la transición de ejecución entre ambos núcleos sea
muy ligera consiguiendo que el tiempo de latencia de respuesta a las interrupciones
hardware sean mı́nimos.
Xenomai permite adaptar software diseñado desde otros sistemas operativos

como VxWorks, pSOS+ o VRTXsa. Para esto, Xenomai posee una serie de interfaces
especializados (skins) que emulan las APIs de estos sistemas operativos comerciales.
Fig. 2: Interfaces RTOS
Además de estas interfaces, Xenomai posee un API nativa que ofrece una serie
de familias de servicios. Cada familia de servicios dispone de un gran número de
funciones, la mayorı́a pueden ser invocadas tanto desde el espacio del usuario como
del núcleo. Las diferentes familias de servicios son las siguientes:
Gestión de tareas: Conjunto de servicios para gestionar los ciclos de vida

de los hilos de ejecución y el control de sus parámetros de planificación.
Servicios de temporización: Servicios para gestionar los diferentes tipos de

temporizadores: relojes de sistema, watchdogs y alarmas.
Mecanismos de sincronización: Servicios para la sincronización de las ta-

reas y el control de acceso a los recursos que requieren exclusión muta (conta-
dores, semáforos, mutex, variables condicionales y grupos de flags de eventos).
Servicios de comunicación y transmisión de mensajes: Servicios pa-

ra implementar los diferentes modos de intercambio de información entre las
2.4 Conclusiones en la elección del sistema operativo de tiempo real 23
tareas de tiempo real y entre éstas y los procesos Linux del espacio de usua-
rios (mensajes sı́ncronos entre tareas, colas de mensajes, pilas de memoria y
tuberı́as de mensajes).
Manejadores de dispositivos: Servicios para gestionar la entradas/salidas

del RTOS, la interfaz nativa solo ofrece mecanismos de gestión de interrupcio-
nes y de acceso a memoria de I/O desde el espacio de usuario.
Soporte de registros: Este servicio es muy especı́fico de la interfaz nativa y

dispone de funciones similares a las llamadas del sistema desde los diferentes
espacios de ejecución.
2.4. Conclusiones en la elección del sistema operativo de

tiempo real
El objetivo principal de los sistemas de tiempo real es que un evento obtenga

respuesta en un determinado tiempo. Esto no significa que la respuesta sea rápida
sino que este dentro de un intervalo de tiempo. Para esto, es necesario que las
tareas de tiempo real se ejecuten completamente en un tiempo lı́mite o máximo
(deadline). Si el tiempo de respuesta del sistema es crı́tico se utiliza el concepto
”Hard Real Time”(HRT), donde el resultado de la ejecución será erróneo si se ha
superado el deadline. Si las tareas no son tan crı́ticas y se permite sobrepasar este
tiempo ocasionalmente, se utiliza el concepto de ”Soft Real Time”(SRT). Por este
motivo, un sistema operativo de tiempo real debe garantizar que se cumplan todas
las restricciones crı́ticas de tiempo en la ejecución de las tareas del sistema.
La tendencia de los últimos años es la utilización de software libre en la experi-

mentación cientı́fica computacional, lo que ha permitido a Linux un gran crecimiento
y que se convierta en un estándar de facto para esta serie de disciplinas. Además,
ha generado un gran interés por desarrollar adaptaciones de este sistema operativo
de propósito general en un sistema operativo de tiempo real.
Actualmente, para lograr que Linux se comporte como un sistema operativo

de tiempo real existen dos tendencias. La primera, consiste en parchear el núcleo
para lograr menores latencias en las interrupciones, mejores tiempos en los cambios
de contexto, menor latencia en la planificación y tener mayor precisión en el tem-
porizador. La segunda tendencia, consiste en utilizar un nano-kernel de tiempo real
que ejecuta el kernel estándar de Linux como una tarea de baja prioridad, mientras
administra las interrupciones hardware y solo redirecciona al núcleo de Linux las
que son relevantes para este.
En ambas tendencias existen tanto ventajas como desventajas respecto a la

otra, pero dentro del software libre la tendencia más utilizada es la del nano-kernel.
Esta tendencia permite un mayor control de las latencias y por lo tanto un mayor
determinismo. Dentro de la tendencia del nano-kernel están las extensiones para Li-
nux: RTAI (Real-Time Application Interface) y Xenomai. Ambas alternativas están
basadas en el nano-kernel ADEOS (Adaptive Domain Environment for Operating
Systems).
En conclusión, el desarrollo del sistema de tiempo real del registrador jurı́dico

ferroviario se va a utilizar Xenomai para su implementación. Esta elección se debe
a las siguientes conclusiones:
Desarrollo en la plataforma Linux. La utilización de Linux como sistema ope-

rativo además de ser open source y por lo tanto ser gratuito, implica que detrás
hay una gran comunidad de desarrollo que permite tener un amplio soporte
en el desarrollo del sistema.
Xenomai tiene buenos rendimientos de tiempo real. Estudios comparativos

realizados demuestran que Xenomai logra un buen rendimiento en sistemas de
tiempo real (menor delay y menor jitter ) incluso mejor que otras alternativas
privadas y comerciales.
Xenomai permite ejecutar tareas tanto de tiempo real como no y también la

comunicación entre ellas. Esto facilita el establecimiento de prioridades entre
las tareas del sistema y su clasificación entre tareas crı́ticas como tareas no
crı́ticas. Un ejemplo, la adquisición de cambios de estados en las señales que
se registran respecto al tiempo en que se producen es una tarea crı́tica que
debe ser exacta en el tiempo. Por otro lado, la escritura de estos registros en
el fichero de registro no son crı́ticos respecto al tiempo en el que se realizan
por lo que no es crı́tica.
25
3. METODOLOGÍAS DE DESARROLLO SOFTWARE

UTILIZADAS
El objetivo de este capı́tulo será la enumeración y descripción de las principales

metodologı́as de desarrollo software empleadas en la implementación del proyecto.
Las metodologı́as utilizadas en este proyecto son muy especı́ficas para el desa-
rrollo de sistemas embebidos de tiempo real aunque también se utilizan en otros
ámbitos de desarrollo software.
3.1. Análisis Estructurado Moderno
El Análisis Estructurado consisten en representar el concepto del sistema en

datos y controlar la terminologı́a representada mediante diagramas de flujo de datos.
Esta metodologı́a se hizo popular en la década de 1980 y aún se sigue utilizan-

do en el desarrollo de muchos proyectos. En este proyecto se va a utilizar el Análisis
Estructurado Moderno desarrollado por Edward Yourdon que a continuación se des-
cribirá.
El proceso de análisis del sistema consta en el desarrollo de dos modelos fun-

damentalmente. Estos modelos son: el modelo esencial y el modelo de implantación
del usuario.
3.1.1. Modelo esencial
Este modelo representa lo qué el sistema debe hacer para satisfacer los requi-
sitos del usuario. Para ello, se considera un costo nulo de tecnologı́a y no se debe
realizar la especificación de los procesos. El modelo esencial a su vez está compuesto
por dos modelos: el modelo ambiental y el modelo de comportamiento.
Modelo ambiental: En este modelo se deben definir los elementos que son
parte del sistema y los que no, es decir se definen las interfaces entre el sistema
y el resto de elementos que lo rodean. Los elementos ha desarrollar en este
modelo son los siguientes:
• Declaración de propósitos: Enunciado del propósito del sistema ex-

presado en un solo párrafo.
26 3 METODOLOGÍAS DE DESARROLLO SOFTWARE UTILIZADAS
• Diagrama de contexto: Diagrama de flujo de datos que consta de una

sola burbuja que representa el sistema e incluye personas, datos y sistemas
que interactúan con el sistema a desarrollar.
• Lista de acontecimientos: Enumeración de los estı́mulos que ocurren
fuera del sistema y a los cuáles este debe responder. Los acontecimientos
se pueden clasificar como: de flujo (llegan datos), temporal y de control.
Modelo de comportamiento: Este modelo consiste en el desarrollo de los

diagramas de flujo del sistema a partir del diagrama de flujo de contexto y
los acontecimientos enumerados en el modelo ambiental. En un principio se
debe realizar un desarrollo descendente de los mismo a la vez que se genera un
diccionario de datos del sistema. El producto de este modelo es una serie de
diagramas de flujo de datos y un diagrama de entidad-relación para describir el
diccionario de datos del sistema. Además, los procesos finales son especificados
formalmente.
3.1.2. Modelo de implantación del usuario
En este modelo se definen las interfaces del sistema con el medio ambiente que
le rodea. Este modelo define las interfaces de usuario y las interfaces con otros sis-
temas. También, se identifican las actividades manuales para dar soporte al sistema
y las restricciones operacionales.
3.2. HRT-HOOD
HRT-HOOD es un método de diseño estructurado orientado para sistemas de

tiempo real estricto. El método es una evolución del método HOOD (Hierarchical
Object-Oriented Design).
Este método organiza el sistema como una jerarquı́a de objetos abstractos.

Cada objeto se caracteriza por sus operaciones y su comportamiento. A la vez, cada
objeto se puede descomponer en otros objetos de más bajo nivel.
En el caso de conocer el entorno de ejecución y que este sea predecible, se

puede analizar el comportamiento temporal del sistema. Esto es posible porque los
objetos tienen atributos temporales y las relaciones entre objetos están restringidas
para asegurar su análisis.
3.2 HRT-HOOD 27
HRT-HOOD define una serie de tipos de objetos:
Activos: Estos objetos controlan cuando se ejecutan sus operaciones y pue-

den invocar operaciones de otros objetos espontáneamente. Estos a su vez se
clasifican en cı́clicos y esporádicos. Las operaciones de estos objetos pue-
den bloquearse por restricciones de invocación (ası́ncrona, sı́ncrona, invocación
remota) y pueden tener un lı́mite de tiempo de ejecución por restricciones fun-
cionales. Los objetos cı́clicos solo pueden tener operaciones de transferencia
de control ası́ncrona (ATC) y estos suelen ejecutar su funcionalidad indefini-
damente de forma cı́clica en el tiempo. Por otro lado, los objetos esporádicos
suelen tener una única operación ası́ncrona (START) para comenzar la ejecu-
ción de su funcionalidad, está operación suele estar ligada a una interrupción.
Pasivos: Estos objetos no controlan cuando se ejecutan sus operaciones, sus

operaciones se ejecutan cuando se invocan, ni invocan operaciones de otros
objetos espontáneamente.
Protegidos: Estos objetos si controlan cuando se ejecutan sus operaciones

pero no invocan operaciones de otros objetos espontáneamente. Las operacio-
nes de estos objetos se ejecutan en exclusión mutua y la invocación puede ser
ası́ncrona o sı́ncrona, y en este caso pueden tener temporizaciones y restric-
ciones funcionales.
La metodologı́a consiste en la descomposición descendente e iterativa de los

objetos. El resultado final son objetos terminales (cı́clicos, esporádicos, protegidos
y pasivos). Existen reglas de descomposición y uso que posibilitan el análisis del
comportamiento temporal.
Fig. 3: Reglas de descomposición

Fig. 4: Reglas de uso
Además, con el objetivo de asegurar los requisitos no funcionales del sistema

se pueden asignar atributos temporales y de otros tipos a los objetos. De esta forma
también permite el análisis temporal del diseño.
3.3. Paradigma estructurado
El paradigma de programación estructurado está orientado a mejorar la clari-

dad, calidad y tiempo de desarrollo del software utilizando únicamente subrutinas y
tres estructuras básicas: la secuencia, la selección (if y switch) y la iteración (bucles
for y while).
Este paradigma surgió en la década de 1960, particularmente del trabajo de

Böhm y Jacopini y un famoso escrito de 1968: ((La sentencia goto, considerada
perjudicial)), de Edsger Dijkstra.
Las ventajas de la programación estructurada sobre el modelo anterior (hoy

llamado despectivamente código espagueti) son las siguientes:
Mayor facilidad de entender los programas, los programas son secuenciales (sin
GOTO).
Estructura clara de los programas, ya que las instrucciones están más relacio-
nadas entre sı́.
Esfuerzo optimizado en las fases de prueba y depuración.
Costes de mantenimiento reducidos.
3.4 Lenguaje C 29
Programación más sencilla y rápida.
Incremento del rendimiento de los programadores.
Algunos ejemplos de lenguajes de programación estructurada son: ALGOL,

Pascal, PL/I y Ada.
3.4. Lenguaje C
C es un lenguaje de programación desarrollado por Dennis Ritchie entre los

años 1969 y 1972 en los laboratorios Bell como evolución de un anterior lenguaje
llamado B, que a su vez estaba basado en BCPL.
C está orientado a la implementación de sistemas operativos, aunque también

se utiliza para implementar software de sistemas y aplicaciones. Es un lenguaje muy
apreciado por la eficiencia del código que genera.
Las caracterı́sticas principales de este son las siguientes:
Tipos de datos estáticos.
Débilmente tipificado.
Lenguaje de medio nivel, dispone tanto de estructuras de lenguajes de alto

nivel como de estructuras que permiten un control a muy bajo nivel.
Los compiladores suelen ofrecer extensiones para mezclar código en ensambla-

dor con código C o acceder directamente a memoria o dispositivos periféricos.
La estandarización del lenguaje C se denomina ANSI y fue desarrollada la pri-

mera versión en 1989. El lenguaje que define este estándar se denomina vulgarmente
ANSI C. La adopción de este estándar es muy amplia, lo que permite que el código
sea portable entre plataformas y/o arquitecturas.
Las principales ventajas del uso de este lenguaje son:
Lenguaje muy eficiente con la posibilidad de utilizar caracterı́sticas de bajo

nivel para implementaciones óptimas.
Lenguaje mas portado en existencia, existen compiladores para casi todas las
plataformas conocidas.
Proporciona una alta modularidad permitiendo la reutilización de código y

bibliotecas existentes.
El lenguaje C es muy utilizado para el desarrollo de sistemas operativos, apli-

caciones de escritorio, aplicaciones cientı́ficas (modelos y simuladores), aplicaciones
industriales (robótica y simulación), simuladores de vuelo, etc. Además, C es el len-
guaje más común para desarrollar sistemas embebidos debido a el código ligero que
un compilador C genera combinado con la capacidad de acceso a capas de software
muy cercanas al hardware.
3.5. Método en V
El Método en V es un procedimiento de desarrollo de productos software. Este

método es utilizado como estándar para los proyectos de la Administración Federal
Alemana y de defensa. El método describe tantos métodos para la gestión como
para el desarrollo de sistemas.
El método define el ciclo de vida de desarrollo de los sistemas, tanto los pro-
cesos de desarrollo como los procesos de V&V. El proceso se representa como una
V donde en la rama izquierda se representan las actividades y artefactos de las fa-
ses de desarrollo y en la rama derecha se representa la integración de las piezas y
su verificación. V significa ((Verificación y vendeta)). Es un método muy similar al
modelo de la cascada clásico ya que es muy rı́gido y contiene una gran cantidad de
iteraciones.
Fig. 5: Método en V
El método proporciona una guı́a para la planificación e implementación de

3.5 Método en V 31
proyectos. Los siguientes objetivos están destinados a ser alcanzados en la ejecución

del proyecto:
Minimización de los riesgos del proyecto. Se mejora la transparencia y control

del mismo, especificando los artefactos estandarizados esperados y las fun-
ciones de responsabilidad en cada fase. Esto permite la detección temprana
de desviaciones y la aparición de riesgos mejorando la gestión de procesos y
reduciendo los riesgos.
Mejora y garantı́a de calidad. Los procesos forman parte de un modelo estándar

lo que asegura que los resultados sean completos y con la calidad deseada.
Además, permite revisar los artefactos provisionales en fases tempranas. La
uniformidad en el contenido del producto mejora la legibilidad, comprensibili-
dad y verificabilidad.
Reducción de los gastos totales durante todo el ciclo de vida del proyecto. El
esfuerzo de todas las fases puede ser calculado, estimado y controlado.
Mejora de la comunicación entre todos los participantes del proyecto. La des-

cripción estandarizada y uniforme de todos los elementos pertinentes y térmi-
nos es la base para la comprensión mutua entre todos los participantes del
proyecto.
33
4. ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA
La tarea de especificación de requisitos de un sistema consiste en realizar una

descripción completa del comportamiento del sistema que se va a desarrollar. Esta
descripción incluye una serie de casos de usos que describen las interacciones en-
tre los usuarios del sistema con el mismo, estos también se conocen como requisitos
funcionales. Además, también existen otros tipos de requisitos no funcionales o com-
plementarios. Los requisitos no funcionales establecen una serie de restricciones en
el diseño y/o la implementación del sistema.
La especificación de requisitos del sistema va dirigida tanto al cliente como al

equipo de desarrollo.
Las caracterı́sticas que debe tener una buena especificación de requisitos soft-
ware son las siguientes:
Completa: Todos los requisitos del sistema deben estar incluidos en la espe-
cificación y las referencias deben estar bien definidas.
Consistente: Los requisitos deben ser coherentes entre ellos y con otros do-
cumentos de especificación.
Inequı́voca: La redacción de los requisitos no puede ser ambigua y no puede

dar lugar a interpretaciones incorrectas.
Correcta: Todos los requisitos de la especificación se deben cumplir en el

sistema implementado.
Trazable: Todos los requisitos deben estar identificados unı́vocamente y debe

permitir la verificación del historial, la ubicación y la aplicación de los mismos.
Priorizable: Los requisitos se deben clasificar según su relevancia para el

negocio. La clasificación utilizada puede ser como requisitos esenciales, condi-
cionales y opcionales.
Modificable: Los requisitos se deben poder modificar fácilmente.
Verificable: Se debe poder demostrar que el sistema cumple con los requisitos
especificados.
34 4 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA
4.1. Listado de los principales casos de uso del sistema
A continuación, se enumeran los principales casos de uso que el sistema debe

cumplir:
Calcular los datos de odometrı́a.
Registrar los cambios de velocidad del tren.
Registrar los cambios de fecha y hora del sistema.
Registrar los cambios de estado de las señales digitales del tren.
Registrar los cambios de estado de las señales analógicas del tren.
Registrar los cambios de estado de los mensajes MVB del tren.
Registrar los cambios de estado del sistema.
Actualizar las salidas digitales del equipo.
Actualizar los indicadores leds del equipo.
Enviar los mensajes MVB del equipo.
Comprobar el estado HW del equipo.
Visualizar el estado del sistema por el operador.
Actualizar la fecha y hora del sistema por el operador.
Actualizar la fecha y hora del sistema por MVB.
Descargar el fichero de registro completo por el operador.
Descargar el fichero de registro parcialmente por el operador.
Descargar el fichero de registro completo por USB.
Descargar el fichero de registro parcialmente por USB.
Borrado del fichero de registro por el operador.
Visualizar la configuración del sistema por el operador.
Modificar la configuración del sistema por el operador.

4.2 Descripción detallada de los casos de uso del sistema 35
4.2. Descripción detallada de los casos de uso del sistema
Ahora, se describirán de forma detalla algunos de los casos de uso del sistema.
Se elegirán los más representativos para que sirvan de muestra del proceso ya que el
objetivo de esta memoria no es servir de documento de descripción de casos de uso
sino para describir el proceso llevado a cabo.
La descripción de los campos de los casos de uso es la siguiente:
Identificador: Identificador único del caso de uso.
Nombre: Nombre descriptivo del caso de uso.
Actores: Actores que intervienen en el caso de uso.
Descripción: Breve descripción explicativa del caso de uso.
Trigger: Acción que lanza la ejecución del caso de uso.
Pre-Condición: Condiciones que se deben cumplir para que se ejecute el caso

de uso.
Post-Condición: Estado en el que se queda el sistema una vez ejecutado el

caso de uso.
Flujo normal: Listado de las acciones que se ejecutan en el flujo principal

del caso de uso.
Flujos alternativos: Descripción de flujos alternativos producidos por alter-

nativas, excepciones o errores en el flujo principal.
Inclusiones: Otros casos de uso que se incluyen en el caso de uso.
Frecuencia de uso: Periodicidad con la que se ejecuta el caso de uso.
Notas: Comentarios varios y aclaraciones sobre el caso de uso.
4.2.1. Calcular los datos de odometrı́a
Identificador: EVR-UC-0001
Nombre: Calcular los datos de odometrı́a
Actores: N/A
Descripción: El sistema actualiza los datos de odometrı́a periódicamente. Es-

tos cálculos se realizan basándose en los pulsos detectados de los tacos del tren.
Los datos que se calculan son los siguientes: velocidad, aceleración, distancia,
deslizamiento, estado de los tacos.
Trigger: Timer.
Pre-Condición: N/A
Post-Condición: Los datos de odometrı́a han sido actualizados en el sistema.
Flujo normal:
1. El sistema lee el número de pulsos detectados de los tacos del tren en el

intervalo de tiempo.
2. El sistema calcula los datos de odometrı́a basándose en los datos existen-
tes y los pulsos detectados.
3. El sistema actualiza los datos de odometrı́a.
Flujos alternativos: N/A
Inclusiones: N/A
Frecuencia de uso: 10 ms.
Notas: N/A
4.2.2. Registrar los cambios de estado de las señales digitales del tren
Nombre: Registrar los cambios de estado de las señales digitales del tren
Actores: N/A
Descripción: El sistema registra los cambios de estado detectados en las

señales digitales de entrada cableadas del tren. Los cambios de estado se agru-
pan en grupos de 16 señales digitales por paquete. El registro consiste en la
inserción de un paquete de registro con el nuevo estado del grupo de señales en
fichero de registro del equipo. Los datos que contiene un paquete de registro
de señales digitales es: identificador del paquete, fecha y hora, velocidad ins-
tantánea, aceleración instantánea, distancia recorrida desde el último paquete,
estado del grupo de las señales digitales y el CRC.
Trigger: Timer
4.2 Descripción detallada de los casos de uso del sistema 37
Post-Condición: Registrados los paquetes de cambio de estado de las señales

digitales en el fichero de registro.
Flujo normal:
1. El sistema lee el estado de las señales digitales del tren.

2. El sistema verifica los grupos de señales digitales que han cambiado desde
el último chequeo.
3. El sistema genera los paquetes de registro de los grupos de señales modi-
ficados.
4. El sistema registra los paquetes generados en el fichero de registro del
sistema.
Inclusiones: N/A
Notas: N/A
4.2.3. Actualizar los indicadores leds del equipo
Nombre: Actualizar los indicadores leds del equipo
Actores: N/A
Descripción: El sistema enciende o apaga los indicadores leds del equipo

según el estado del sistema. El significado de cada led está especificado en la
especificación de requisitos software del sistema.
Trigger: Timer
Post-Condición: El equipo tiene actualizado el estado de los indicadores leds

del equipo según el estado interno del sistema.
Flujo normal:
1. El sistema lee el estado interno del sistema.

2. El sistema actualiza el estado de los indicadores leds del equipo.

Inclusiones: N/A
Notas: N/A
4.2.4. Visualizar el estado del sistema por el operador
Nombre: Visualizar el estado del sistema por el operador
Actores: Operador
Descripción: El operador solicita visualizar el estado del sistema mediante
la interfaz web de mantenimiento del equipo.
Trigger: Solicitud del operador.
Pre-Condición: El operador está identificado en el sistema.
Post-Condición: El sistema muestra su estado al operador por medio de la
web de mantenimiento.
Flujo normal:
1. El operador solicita visualizar el estado del sistema.
2. El sistema muestra al operador su estado mediante su interfaz web de
mantenimiento.
Inclusiones: N/A
Frecuencia de uso: N/A
Notas: N/A
4.2.5. Descargar el fichero de registro completo por el operador.
Nombre: Descargar el fichero de registro completo por el operador.
Actores: Operador
Descripción: El operador solicita la descarga del fichero de registro completo
mediante la interfaz web de mantenimiento del equipo.
4.3 Descripción detallada de los requisitos no funcionales del sistema 39
Trigger: Solicitud del operador.
Pre-Condición: El operador está identificado en el sistema.
Post-Condición: El sistema realiza la descarga completa del fichero de regis-

tro del equipo por medio de la web de mantenimiento.
Flujo normal:
1. El operador solicita la descarga completa del fichero de registro del siste-

ma.
2. El sistema descarga el fichero completo del registro del equipo mediante
su interfaz web de mantenimiento.
Inclusiones: N/A
Frecuencia de uso: N/A
Notas: N/A
4.3. Descripción detallada de los requisitos no funcionales del

sistema
Ahora, se describirán de forma detalla algunos de los requisitos no funcionales

del sistema. Se elegirán unos pocos que sean representativos para que sirvan de
muestra del proceso ya que el objetivo de esta memoria no es servir de documento
de especificación de requisitos software sino para describir el proceso llevado a cabo.
La descripción de los campos de los requisitos es la siguiente:
Identificador: Identificador único del requisito.
Nombre: Nombre descriptivo del requisito.
Descripción: Descripción completa del requisito.
Estado: El estado indica la situación en la que se encuentra el requisito en el

ciclo de vida de los requisitos definido en el proyecto.
Prioridad: La prioridad de un requisito es un indicador para decidir en qué

iteraciones se acomete su implementación.
Importancia: La importancia de un requisito indica la relevancia del requisito

para los clientes y usuarios, y suele estar relacionada con la importancia de los
objetivos de negocio que el requisito ayuda a cumplir.
Estabilidad: La estabilidad de un requisito indica una estimación de la pro-

babilidad de que el requisito no cambie durante el resto del desarrollo.
Notas: Comentarios varios y aclaraciones sobre el requisito.
4.3.1. Periodo de registro de las señales digitales
Identificador: EVR-REQ-0038
Nombre: Periodo de registro de las señales digitales
Descripción: El sistema deberá registrar los cambios de las señales digitales

cada 20 ms.
Estado: APROBADO
Prioridad: ALTA
Importancia: ESENCIAL
Estabilidad: ALTA
Notas: N/A
4.3.2. Periodo de actualización del fichero de registro
Nombre: Periodo de actualización del fichero de registro
Descripción: El sistema deberá actualizar el contenido del fichero de registro

del equipo con los paquetes pendientes por registrar cada 1000 ms.
Estado: APROBADO
Prioridad: ALTA
Importancia: ESENCIAL
Estabilidad: ALTA
Notas: N/A
4.3 Descripción detallada de los requisitos no funcionales del sistema 41
4.3.3. Capacidad del fichero de registro
Nombre: Capacidad del fichero de registro
Descripción: La capacidad del fichero de registro del equipo deberá ser de

64MB de información.
Estado: APROBADO
Prioridad: ALTA
Importancia: IMPORTANTE
Estabilidad: MEDIA
Notas: N/A
43
5. ANÁLISIS DEL SISTEMA
El análisis software se puede definir como el proceso automatizado de analizar

el comportamiento del software. Dentro del proceso de análisis es fundamental que
el equipo de desarrollo mediante una especificación de requisitos del sistema, tanto
funcionales como no, comprenda completamente la naturaleza del sistema para el
desarrollo correcto del mismo.
La metodologı́a utilizada para realizar la fase de análisis del sistema es el

Análisis Estructurado Moderno, descrito anteriormente.
En la memoria del proyecto solamente se van a describir el modelo ambiental

y el modelo de comportamiento del modelo esencial de la metodologı́a, donde se
define lo que el sistema debe hacer para satisfacer los requisitos especificados para
el mismo.
5.1. Modelo ambiental
En este modelo se definen los elementos que son parte del sistema y los que
están fuera del mismo. Para ello, hay que definir los interfaces del sistema con el
resto de elementos que le rodean.
Este modelo está formado por los siguientes artefactos: Declaración de propósi-
tos, diagrama de contexto y lista de acontecimientos.
5.1.1. Declaración de propósitos
El propósito del Event Recorder es registrar el estado del tren y los eventos
que se producen en este y que son recibidos a través de los interfaces del sistema
con los otros sistemas del tren con fines legales.
44 5 ANÁLISIS DEL SISTEMA
5.1.2. Diagrama de contexto
Fig. 6: Diagrama de contexto
5.1.3. Lista de acontecimientos
Los acontecimientos se clasifican de flujo (F), temporales (T) y de control

(C).
1. El sistema recibe un pulso de los tacó-grafos del tren. (F)
2. El sistema registra los cambios de velocidad del tren cada 20 milisegundos.

(T)
3. El sistema recibe un cambio de fecha y hora del tren procedente del interfaz
MVB del tren. (F)
4. El operario solicita el cambio de fecha y hora del equipo a través de la interfaz

de mantenimiento. (F)
5. El sistema registra los cambios de fecha y hora del equipo, no actualizaciones

por avance del tiempo, cada 20 milisegundos. (T)
6. El sistema registra los cambios de estado de las señales digitales procedentes

del tren cada 20 milisegundos. (T)
5.1 Modelo ambiental 45
7. El sistema registra los cambios de estado de las señales analógicas procedentes

del tren cada 20 milisegundos. (T)
8. El sistema registra los cambios de estado de las variables de los mensajes

importados del interfaz MVB procedentes del tren cada 20 milisegundos. (T)
9. El sistema actualiza el estado de sus señales digitales cada 10 milisegundos.

(T)
10. El sistema actualiza el estado de sus indicadores leds cada 10 milisegundos.

(T)
11. El sistema actualiza el estado de las variables de los mensajes exportados al

interfaz MVB del tren cada 10 milisegundos. (T)
12. El sistema chequea el estado del HW del equipo periódicamente. (T)
13. El operario solicita visualizar el estado del equipo a través de la interfaz de

mantenimiento. (F)
14. El sistema registra los cambios de estado del propio sistema cada 20 milise-
gundos. (T)
15. El sistema actualiza el fichero de registro con los paquetes de registro pendien-
tes cada segundo. (T)
16. El operario solicita una descarga del fichero de registro a través de la interfaz
de mantenimiento. (C)
17. El operario solicita el borrado del fichero de registro a través de la interfaz de

mantenimiento. (C)
18. El operario solicita una descarga del fichero de registro mediante el puerto
USB. (C)
19. El operario solicita la modificación de la configuración del equipo a través de

la interfaz de mantenimiento. (F)
20. El operario solicita visualizar la configuración del equipo a través de la interfaz

de mantenimiento. (F)
5.2. Modelo de comportamiento
En el modelo de comportamiento se desarrollan los diagramas de flujo del siste-

ma a partir del diagrama de contexto y los acontecimientos del mismo desarrollados
en el modelo ambiental. Estos diagramas de flujo están organizados en niveles de
detalle y por funcionalidad.
A continuación se describirán los principales diagramas de flujo generados en

esta fase de análisis de los niveles de detalle más superiores.
5.2.1. Nivel 01. Event Recorder
Este es el diagrama de nivel más superior después del diagrama de contexto.

En el diagrama se representa el sistema completo y sus relaciones con las entidades
externas. Los procesos representan las funcionalidades principales del sistema.
Fig. 7: DFD Nivel 01. Event Recorder
Procesos
Odometry Management: Este proceso gestiona toda la funcionalidad rela-

cionada con la odometrı́a del sistema.
5.2 Modelo de comportamiento 47
Time Management: La funcionalidad relacionada con el mantenimiento de

la fecha y hora y la gestión de las actualizaciones horarias del sistema es
controlada por este proceso.
External Interfaces Management: Este proceso controla las comunicacio-

nes con las entidades externas mediante los diversos interfaces que dispone el
sistema.
EVR Status Management: La funcionalidad relacionada con la gestión del

estado interno del sistema es controlada por este proceso.
Record File Management: La funcionalidad relacionada con la gestión del

almacenamiento de la información de registro en el fichero es controlada por
este proceso.
Configuracion Management: Este proceso gestiona toda la funcionalidad

relacionada con la configuración del sistema.
5.2.2. Nivel 02. Odometry Management
Este diagrama gestiona la funcionalidad relacionada con la odometrı́a del sis-

tema.
Fig. 8: DFD Nivel 02. Odometry Management

Procesos
Odometry Data Updating: Este proceso gestiona la actualización de los

datos de odometrı́a del sistema dependiendo de los pulsos recibidos de los
tacógrafos y del tiempo transcurrido.
Current Speed Recording: La funcionalidad de registro de los cambios de
la velocidad del sistema.
5.2.3. Nivel 02. Time Management
Este diagrama gestiona la funcionalidad relacionada con la gestión de la fecha

y hora y las actualizaciones de la misma en el sistema.
Fig. 9: DFD Nivel 02. Time Management
Procesos
Date/Time Updating by MVB: Este proceso gestiona la actualizaciones

de fecha y hora recibidas por el interfaz de MVB.
Date/Time Updating by Operator: Este proceso gestiona la actualizacio-

nes de fecha y hora recibidas por el interfaz con el operador.
Date/Time Change Recording: La funcionalidad de registro de los cambios

de fecha y hora del sistema.
5.2.4. Nivel 02. External Interfaces Management
Este diagrama gestiona la funcionalidad de control de las comunicaciones me-

diante los interfaces del sistema.
Fig. 10: DFD Nivel 02. External Interfaces Management

Procesos
Digital Input Signals Recording: La funcionalidad de registro de los cam-

bios de estado de las señales digitales de entrada del sistema.
Analog Input Signals Recording: La funcionalidad de registro de los cam-

bios de estado de las señales analógicas de entrada del sistema.
MVB Input Signals Recording: La funcionalidad de registro de los cambios

de estado de las señales de los mensajes MVB de entrada del sistema.
Digital Output Signals Updating: Este proceso gestiona la actualizaciones

de las señales digitales de salida del sistema según el estado interno del mismo.
Leds Updating: Este proceso gestiona la actualizaciones de los indicadores

leds del sistema según el estado interno del mismo.
MVB Output Signals Updating: Este proceso gestiona la actualizaciones

de las señales de los mensajes MVB de salida del sistema según el estado
interno del mismo.
5.2.5. Nivel 02. EVR Status Management
Este diagrama gestiona la funcionalidad de gestión del estado interno del sis-
tema.
Fig. 11: DFD Nivel 02. EVR Status Management
Procesos
HW Self-Checking: Este proceso gestiona la ejecución de las pruebas de

HW internas del sistema.
EVR Status Visualization: Este proceso gestiona el envı́o del estado interno
del sistema bajo demanda del operador.
EVR Status Recording: La funcionalidad de registro de los cambios de

estado interno del sistema.
5.2.6. Nivel 02. Record File Management
Este diagrama gestiona la funcionalidad de control de la grabación de eventos

y solicitudes sobre el fichero de registro del sistema.
Fig. 12: DFD Nivel 02. Record File Management
Procesos
Record File Updating: Este proceso gestiona las actualizaciones del fichero
de registro con los paquetes pendientes de ser registrados periódicamente.
Record File Downloading by Maintenance Interface: Este proceso ges-

tiona las peticiones de descarga del fichero de registro por parte del operario
a través de la interfaz de mantenimiento del sistema.
Record File Downloading by USB: Este proceso gestiona las peticiones

de descarga del fichero de registro por parte del operario a través de la interfaz
USB del sistema.
Record File Erasing: Este proceso gestiona las peticiones de borrado del
fichero de registro por parte del operario a través de la interfaz de manteni-
miento del sistema.
5.2.7. Nivel 02. Configuration Management
Este diagrama gestiona la funcionalidad relacionada con la configuración del

sistema.
Fig. 13: DFD Nivel 02. Configuration Management
Procesos
Configuration Modification: Este proceso gestiona las peticiones de modi-

ficación de la configuración del sistema por parte del operador.
EVR Status Visualization: Este proceso gestiona el envı́o de la configura-

ción del sistema bajo demanda del operador.
55
6. DISEÑO DEL SISTEMA
El diseño se puede definir como el trabajo para establecer la arquitectura, los

componentes, las interfaces y otras caracterı́sticas de un sistema o componente.
En el ciclo de vida del desarrollo software, el diseño es la actividad que genera

un conjunto de modelos y artefactos que describen la estructura interna del software
a partir del análisis de los requisitos.
El diseño de un sistema software se compone de:
La arquitectura, que es la descripción del sistema descompuesto y organizado

en componentes y sus relaciones.
Las interfaces entre dichos componentes.
La descripción de los componentes a un nivel de detalle suficiente para su

implementación.
Normalmente, la descripción de la arquitectura se define como el diseño de

alto nivel y la descripción detallada de los componentes y su comportamiento como
el diseño de bajo nivel.
A continuación se irán describiendo los objetos en los que se va descomponiendo

el sistema mediante la metodologı́a HRT-HOOD descrita anteriormente.
56 6 DISEÑO DEL SISTEMA
6.1. Event Recorder
Este objeto es el objeto principal, el sistema. Los objetos que lo componen son
los objetos que gestionan la funcionalidad principal del sistema.
Fig. 14: Event Recorder

6.2 Date/Time Manager 57
6.1.1. Objetos
Date/Time Manager: Este objeto gestiona la funcionalidad relacionada con

la fecha y hora del sistema.
Odometry Manager: Este objeto gestiona la funcionalidad relacionada con

los cálculos de odometrı́a del sistema.
Events Recording Manager: Este objeto gestiona la funcionalidad relacio-

nada con el registro de eventos del sistema.
IO Manager: Este objeto gestiona las comunicaciones externas del equipo.
Operator Communications Manager: Este objeto gestiona las comunica-

ciones con el operador.
System Status Manager: Este objeto gestiona la funcionalidad relacionada

con el estado interno del sistema.
Configuration Manager: Este objeto gestiona la configuración del sistema.
6.2. Date/Time Manager
Este módulo gestiona las funciones de fecha y hora del sistema. Sus principales
funciones son actualizar la fecha y hora instantánea del sistema y gestionar las
actualizaciones de fecha y hora recibidas de fuentes externas.
Fig. 15: Date/Time Manager

6.2.1. Interfaz
El objeto proporciona una interfaz de acceso a la fecha y hora actual del sistema
y permite registrar las actualizaciones de fecha y hora recibidas.
6.2.2. Objetos
Date/Time Data Store: Este objeto protegido tiene la funcionalidad de

almacenar toda la información de fecha y hora del sistema, ofrecer un interfaz
de acceso y modificación de la misma y asegurar el acceso en exclusión mutua
de la información almacenada.
Date/Time Supervisor: Este objeto cı́clico actualiza la fecha y hora del sis-
tema y gestiona las actualizaciones de la misma recibidas de fuentes externas.
6.3. Odometry Manager
Este módulo gestiona las funciones de odometrı́a del sistema. Principalmente,

consiste en gestionar la detección de los pulsos de los tacos y realizar los cálculos de
velocidad, distancia y aceleración pertinentes.
Fig. 16: Odometry Manager

6.4 Events Recording Manager 59
6.3.1. Interfaz
El objeto proporciona una interfaz de acceso a los datos de odometrı́a del

sistema.
6.3.2. Objetos
Odometry Data Store: Este objeto protegido tiene la funcionalidad de al-

macenar toda la información de odometrı́a del sistema, ofrecer un interfaz de
acceso y modificación de la misma y asegurar el acceso en exclusión mutua de
la información almacenada.
Odometry Supervisor: Este objeto cı́clico calcula los valores de los datos
de odometrı́a (velocidad, aceleración, distancia, estado de los tacos) según los
pulsos recibidos y los actualiza en el sistema.
Tach Pulse Handler: Objeto esporádico que se activa al detectar un pulso del
taco. Este objeto al detectar el pulso lo registra para su posterior tratamiento.
6.4. Events Recording Manager
La funcionalidad principal de este módulo es gestionar el procedimiento de

registro de eventos en el sistema y gestionar el fichero de registro del mismo.
Fig. 17: Events Recording Manager

Fig. 18: Recording Manager
Fig. 19: Events Recording Supervision Manager
6.4.1. Interfaz
El objeto proporciona una interfaz para poder realizar las solicitudes de des-
carga y borrado del fichero de registro del sistema.
6.4 Events Recording Manager 61
6.4.2. Objetos
Recording Manager: La funcionalidad de este objeto es gestionar las ope-

raciones sobre el fichero de registro del sistema. Este objeto se descompone en
MRE File, Pending Recording Data Store y Recording Data Super-
visor.
Events Recording Supervision Manager: La funcionalidad de este objeto

es supervisar el estado del sistema y registrar los eventos programados que se
produzcan en el mismo. Este objeto se descompone en Speed Events Su-
pervisor, Date/Time Events Supervisor, System Events Supervisor,
Digital Signals Events Supervisor, Analog Signals Events Supervisor
y MVB Events Supervisor.
MRE File: Es el objeto encargado de proporcionar el interfaz de acceso fı́sico

al fichero de registro del equipo.
Pending Recording Data Store: Este objeto protegido tiene la funcionali-

dad de almacenar los eventos pendientes de registro del sistema y asegurar el
acceso en exclusión mutua de la información almacenada.
Recording Data Supervisor: Este objeto actualizará el fichero de registro

con la información pendiente de registro. Será el encargado de ir guardando
los paquetes de registro (eventos) y las cabeceras de fichero necesarias.
Speed Events Supervisor: Este objeto supervisa los eventos de cambio de

velocidad y solicita su registro.
Date/Time Events Supervisor: Este objeto supervisa los eventos de cam-

bio de fecha y/o hora y solicita su registro.
System Events Supervisor: Este objeto supervisa los eventos de cambio de

estado del sistema y solicita su registro.
Digital Signals Events Supervisor: Este objeto supervisa los eventos de

cambio en el estado de las señales digitales y solicita su registro.
Analog Signals Events Supervisor: Este objeto supervisa los eventos de

cambio en el estado de las señales analógicas y solicita su registro.
MVB Events Supervisor: Este objeto supervisa los eventos de cambio en

los datos de los mensajes recibidos por MVB y solicita su registro.
6.5. IO Manager
La funcionalidad principal de este módulo es gestionar las interfaces de comu-

nicación del sistema con el entorno. Las interfaces de las que dispone el sistema son
las siguientes: señales digitales, señales analógicas, multi-vehicle bus (MVB) y los
leds de indicación de estado.
Fig. 20: IO Manager
Fig. 21: Digital Signals Manager

6.5 IO Manager 63
Fig. 22: Analog Signals Manager
Fig. 23: MVB Manager

Fig. 24: Leds Manager
6.5.1. Interfaz
El objeto proporciona una interfaz de acceso (lectura y escritura) para los

diferentes dispositivos de los que dispone el equipo.
6.5.2. Objetos
Digital Signals Manager: La funcionalidad de este objeto es gestionar las

entradas y salidas digitales del equipo. Este objeto se descompone en Digital
Signals Data Store, Digital Signals Driver, Digital Input Supervisor
y Digital Output Supervisor.
Analog Signals Manager: La funcionalidad de este objeto es gestionar las
entradas analógicas del equipo. Este objeto se descompone en Analog Signals
Data Store, Analog Signals Driver y Analog Input Supervisor.
MVB Manager: La funcionalidad de este objeto es gestionar las comuni-
caciones MVB del equipo. Este objeto se descompone en MVB Messages
Data Store, MVB Driver, MVB Input Supervisor y MVB Output
Supervisor.
Leds Manager: La funcionalidad de este objeto es gestionar los dispositivos
leds del equipo. Este objeto se descompone en Led Signals Data Store, Led
Signals Driver y Led Supervisor.
Digital Signals Data Store: Este objeto protegido tiene la funcionalidad de
almacenar el estado de las señales digitales del sistema, ofrecer un interfaz de
6.5 IO Manager 65
acceso y modificación de los mismos y asegurar el acceso en exclusión mutua

Digital Signals Driver: Es el objeto encargado de proporcionar acceso fı́sico

a los dispositivos de las señales digitales del equipo.
Digital Input Supervisor: Este objeto actualizará la información leı́da de

las señales digitales de entrada periódicamente.
Digital Output Supervisor: Este objeto actualizará las señales digitales de

salida con la información del sistema periódicamente.
Analog Signals Data Store: Este objeto protegido tiene la funcionalidad de

almacenar el estado de las señales analógicas del sistema, ofrecer un interfaz de
acceso y modificación de los mismos y asegurar el acceso en exclusión mutua
Analog Signals Driver: Es el objeto encargado de proporcionar acceso fı́sico

a los dispositivos de las señales analógicas del equipo.
Analog Input Supervisor: Este objeto actualizará la información leı́da de

las señales analógicas de entrada periódicamente.
MVB Messages Data Store: Este objeto protegido tiene la funcionalidad

de almacenar los mensajes recibidos y enviados por MVB, ofrecer un interfaz
de acceso y modificación de los mismos y asegurar el acceso en exclusión mutua
MVB Driver: Es el objeto encargado de proporcionar acceso fı́sico a los

dispositivos de comunicaciones MVB del equipo.
MVB Input Supervisor: Este objeto actualizará la información de los

mensajes recibidos del interfaz MVB periódicamente gestionando el protocolo
MVB.
MVB Output Supervisor: Este objeto enviará los mensajes del equipo por
MVB periódicamente gestionando el protocolo MVB.
Led Signals Data Store: Este objeto protegido tiene la funcionalidad de

almacenar el estado de los leds de indicación de estado del sistema, ofrecer
un interfaz de acceso y modificación de los mismos y asegurar el acceso en
exclusión mutua de la información almacenada.
Led Signals Driver: Es el objeto encargado de proporcionar acceso fı́sico a

los dispositivos leds de indicación del equipo.
Led Supervisor: Este objeto actualizará las señales led de indicación con la
información del sistema periódicamente.
6.6. Operator Communications Manager
Este módulo gestiona las comunicaciones con el operador, tanto vı́a web como
por las interrupciones del USB. Estas comunicaciones se basan fundamentalmente en
solicitudes de información, actualización, descarga del registro o borrado del mismo
por parte del operario de mantenimiento.
Fig. 25: Operator Communications Manager
6.6.1. Objetos
Operator Request Manager: Este objeto cı́clico mantiene las comunicacio-

nes con el operador. Su principal funcionalidad es la de atender las solicitudes
que recibe por parte del operador vı́a web. Las comunicaciones se realizarán
entre este módulo y el back-end del servidor web mediante sockets.
USB Downloading Request Handler: Objeto esporádico que se activa al

detectar la conexión de un USB codificado para la descarga. La función del
mismo es ejecutar una descarga del fichero de registro, ya sea parcial o total,
en el USB conectado.
System Status Sender: Este objeto esporádico se activa cuando se recibe

una solicitud de envı́o de estado al operador y se termina cuando se recibe una
solicitud de parada, mientras tanto envı́a periódicamente el estado al operador.
6.7 System Status Manager 67
6.7. System Status Manager
La funcionalidad principal de este módulo es gestionar la información de estado

del sistema, tanto la actualización de los datos como de la exportación de los mismos
hacia el exterior del sistema mediante los interfaces de comunicación del mismo.
Fig. 26: System Status Manager
6.7.1. Interfaz
El objeto proporciona una interfaz de acceso (lectura y escritura) para los

atributos de estado del sistema. Se implementará un acceso por cada atributo del
sistema.
6.7.2. Objetos
System Status Data Store: Este objeto protegido tiene la funcionalidad de

almacenar toda la información de estado del sistema, ofrecer un interfaz de
acceso y modificación de la misma y asegurar el acceso en exclusión mutua de
la información almacenada.
HW Self Tester: Es el objeto encargado de realizar la ejecución de los test

HW del sistema para evaluar el estado del mismo. Estos test se ejecutarán
cı́clicamente y una vez finalizado cada ciclo se actualizará la información de

estado en el objeto System Status Data Store. Además, en la codificación se
implementará un objeto de estos por cada tipo de test que se quiera ejecutar,
es decir cada objeto estará especializado en un único test.
MVB Data Processor: Este objeto leerá la información recibida por MVB
y la actualizará cı́clicamente en el objeto System Status Data Store.
MVB Data Updater: Objeto encargado de exportar la información necesaria

del estado del sistema mediante el interfaz MVB.
Digital Signals Updater: Objeto encargado de exportar el estado del siste-

ma mediante las salidas digitales del mismo.
Leds Updater: Objeto encargado de exportar el estado del sistema mediante

el encendido y apagado de los leds de estado del equipo.
6.8. Configuration Manager
Este módulo gestiona las funciones de configuración del sistema.
Fig. 27: Configuration Manager
6.8.1. Interfaz
El objeto proporciona una interfaz de acceso (lectura y escritura) a la configu-

ración del sistema.
6.8 Configuration Manager 69
6.8.2. Objetos
Configuration Data Store: Este objeto protegido tiene la funcionalidad

de almacenar toda la información de la configuración del sistema, ofrecer un
interfaz de acceso y modificación de la misma y asegurar el acceso en exclusión
mutua de la información almacenada.
71
7. IMPLEMENTACIÓN DEL SISTEMA
La implementación en el desarrollo software es el proceso de realizar una espe-

cificación técnica o algoritmos como una aplicación, componente software o sistema
de software.
La elección de sistema operativo de tiempo real para desarrollar el proyecto ha

sido utilizar Linux con los parches de Xenomai. Esta elección implica que el proyecto
se desarrolle en el lenguaje de programación C, que es un lenguaje del paradigma
imperativo o estructurado.
En este capı́tulo no se va a mostrar el artefacto obtenido en la disciplina de

implementación, el código fuente del sistema, por motivos de propiedad del mismo y
confidencialidad. Sin embargo, se va a describir brevemente el proceso de implemen-
tación del sistema. En este capı́tulo se describe como se traduce a código el diseño
obtenido mediante la metodologı́a HRT-HOOD, la forma de aplicar la funcionalidad
de tiempo real con Xenomai y como se conjuga HRT-HOOD y Xenomai a la hora
de generar código.
7.1. HRT HOOD
Los objetos generados en la fase de diseño mediante la metodologı́a HRT-

HOOD se traducen a módulos C según el tipo de objeto que sea, generando una
estructura determinada para cada tipo. A continuación, enumeramos los tipos de
objetos y las traducciones que se corresponden para cada uno.
Objetos Activos: Cada objeto activo se traduce a un módulo implementando

cada operación como una función o procedimiento del mismo. Además, este
estará implementado con un conjunto de tareas internas (hilos de ejecución) y
mecanismos de sincronización.
Objetos Pasivos: Por cada objeto pasivo se genera un módulo siendo cada
operación una función o procedimiento del mismo.
Objetos Protegidos: Los objetos protegidos se traducen en módulos siento

cada operación una función o procedimiento del mismo. Estas operaciones
están implementadas mediante mecanismos de sincronización que aseguren la
exclusión mutua de las operaciones.
Objetos Cı́clicos: Cada objeto cı́clico se traduce a un módulo que tiene

cada operación ATC como una función o procedimiento del mismo. La imple-
mentación del módulo se realiza mediante una tarea cı́clica y mecanismos de
72 7 IMPLEMENTACIÓN DEL SISTEMA
sincronización que pueden afectar ası́ncronamente al flujo de ejecución de la

tarea periódica.
Objetos Esporádicos: El objeto esporádico se implementa como un módulo

que tiene cada operación ATC y la operación START como una función o
procedimiento del mismo. La implementación del módulo se realiza mediante
una tarea y mecanismos de sincronización que pueden afectar ası́ncronamente
al flujo de ejecución de la tarea que se ejecuta en una iteración. La operación
de START puede estar mapeada a una interrupción y es la que comienza la
ejecución de la tarea una única iteración.
7.2. Xenomai
Xenomai ofrece una API para acceder a su funcionalidad. La API está dividida
en módulos según la funcionalidad que gestionan. Existen módulos para gestionar
las tareas, los mutex, los semáforos, las colas de mensajes, las alarmas y señales, los
buffers, las variables condiciones, etc.
El desarrollo del sistema se realizará utilizando esta API para gestionar la

funcionalidad necesaria de Xenomai para el desarrollo de la aplicación de tiempo
real.
7.3. HRT HOOD, Xenomai y C
En este apartado, se va a realizar una breve descripción de como utilizando C

y Xenomai se van a implementar los diferentes tipos de objetos de diseño generados
con la metodologı́a HRT-HOOD.
El sistema se implementará en un solo proceso multihilo y el proceso en sı́ será

un hilo de Xenomai.
Xenomai necesita que toda la memoria esté disponible para que no se produz-
can interrupciones de paginado y ası́ no se rompa el tiempo real, para ello se hace
lo siguiente en la función main del sistema.
// Se b l o q u e a n t o d a s l a s p a g i n a s en memoria .
m l o c k a l l (MCL CURRENT | MCL FUTURE) ;
7.3 HRT HOOD, Xenomai y C 73
Además, será necesario introducir el proceso como una hebra de Xenomai, para
ello se realiza lo siguiente:
// D e s c r i p t o r de l a t a r e a .
s t a t i c RT TASK T a s k D e s c r i p t o r ;
// Se cambia a l h i l o de Xenomai .
r t t a s k s h a d o w (& T a s k D e s c r i p t o r , ”NombreTarea” ,
P r i o r i t y , Mode ) ;
En la implementación, para cada objeto del diseño se va a generar su pro-

pio módulo en C, esto es un fichero fuente (*.c) con su fichero de cabecera (*.h)
correspondiente. Cada módulo va a implementar un objeto fruto del diseño, para
ello lo que se hará será implementar las operaciones del objeto como funciones o
procedimientos públicos del módulo. Dependiendo el tipo de objeto de diseño, la
implementación utilizará diferentes herramientas para su codificación. A continua-
ción se describen las diferentes implementaciones dependiendo del tipo de objeto de
diseño que se desea desarrollar.
7.3.1. Objeto Activo
Los objetos activos serán módulos en C que contengan de forma privada sus
submódulos de diferentes tipos. Estos objetos proporcionarán una interfaz a los
módulos que los usen.
7.3.2. Objeto Cı́clico
Estos módulos serán implementados como una tarea cı́clica de Xenomai.
Para crear una tarea en Xenomai se puede hacer de dos formas.
Primer método:
// Se c r e a l a t a r e a .
r t t a s k c r e a t e (& T a s k D e s c r i p t o r , ”NombreTarea” ,
S t a c k S i z e , P r i o r i t y , Mode ) ;
// Se l a n z a l a t a r e a .
r t t a s k s t a r t (& T a s k D e s c r i p t o r , &EntryPoint , &Arguments ) ;
Segundo método:
// Se c r e a y s e l a n z a l a t a r e a .
r t t a s k s p a w n (& T a s k D e s c r i p t o r , ”NombreTarea” ,
S t a c k S i z e , P r i o r i t y , Mode ,
&EntryPoint , &Arguments ) ;
El código que ejecutará la tarea será cı́clico.

// Se c o n f i g u r a e l p e r i o d o de e j e c u c i o n .
r t t a s k s e t p e r i o d i c (NULL /∗ s e l f ∗/ ,
TMNOW /∗ i n i t i a l time ∗/ ,
PERIOD) ;
while ( 1 )
{
// Espera a l proximo p e r i o d o .
r t t a s k w a i t p e r i o d (NULL) ;
// E j e c u t a r a c c i o n e s .
...
Cuando el módulo sea destruido, se liberará la tarea.

// Se l i b e r a l a t a r e a .
r t t a s k d e l e t e (& T a s k D e s c r i p t o r ) ;
7.3.3. Objeto Esporádico
Estos módulos serán implementados igual que los cı́clicos salvo que la tarea se
ejecutará cı́clicamente pero cada iteración se hará esperando a que salte la interrup-
ción asociada.
Para configurar la captura de la interrupción y ejecutar la tarea se realiza de

la siguiente forma:
// D e s c r i p t o r de l a i n t e r r u p c i o n .
s t a t i c RT INTR I n t e r r u p t i o n D e s c r i p t o r ;
// Se c o n f i g u r a l a c a p t u r a de l a i n t e r r u p c i o n .
r t i n t r c r e a t e (& I n t e r r u p t i o n D e s c r i p t o r , ” I n t e r r u p c i o n ” ,
IRQ NUMBER, 0 ) ;
7.3 HRT HOOD, Xenomai y C 75
while ( 1 )
{
// Espera a l a c a p t u r a de l a i n t e r r u p c i o n .
r t i n t r w a i t (& I n t e r r u p t i o n D e s c r i p t o r , TM INFINITE ) ;
// E j e c u t a r a c c i o n e s .
...
7.3.4. Objeto Protegido
Los módulos que implementan objetos protegidos deberán implementar las

operaciones del objeto como funciones y procedimientos públicos del módulo.
Estos módulos deben asegurar la exclusión mutua a la hora de acceder a los

datos que gestionan. Para esta labor y debido a que el desarrollo del proyecto se
realizará en un solo proceso multihilo, se utilizarán los mutex de Xenomai para
implementar la exclusión mutua. Cada módulo protegido tendrá un mutex propio
para controlar el acceso a sus secciones crı́ticas.
En la inicialización del módulo se creará el mutex.

// D e s c r i p t o r d e l mutex .
s t a t i c RT MUTEX M u t e x D e s c r i p t o r ;
// Se c r e a e l mutex .
r t m u t e x c r e a t e (& MutexDescriptor , ”NombreMutex” ) ;
El acceso a la sección crı́tica se hará de la siguiente forma:

// El mutex e s a d q u i r i d o .
r t m u t e x a c q u i r e (& MutexDescriptor , TM INFINITE ) ;
// Se e j e c u t a l a s e c c i o n c r i t i c a .
...
// El mutex e s l i b e r a .
r t m u t e x r e l e a s e (& M u t e x D e s c r i p t o r ) ;
Cuando el módulo sea destruido, se liberará el mutex.

// Se l i b e r a e l mutex .
r t m u t e x d e l e t e (& M u t e x D e s c r i p t o r ) ;
7.3.5. Objeto Pasivo
La implementación de este tipo de objeto será como implementar un módulo

convencional de C. Es decir, se desarrollará un módulo que implemente las opera-
ciones del objeto como funciones y procedimientos públicos del módulo.
77
8. VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA
La verificación y validación son los procesos de comprobación y análisis que

aseguran que el software que se desarrolla está acorde con su especificación de re-
quisitos y cumple con las necesidades de los clientes.
La verificación y la validación son procesos diferentes aunque se tiende a con-

fundirlos. A continuación se hará una definición de ambos.
La verificación se puede definir como el proceso para comprobar que el software

que se está desarrollando cumple con la especificación de requisitos del sistema
a verificar. El proceso consta de comprobar que el sistema cumple tanto con los
requisitos funcionales como no funcionales que se han especificado para el mismo.
La validación se puede definir como el proceso para asegurar que el sistema

desarrollado cumple con las expectativas del cliente. La validación es un proceso más
general que va más allá de comprobar que el sistema cumple con la especificación de
requisitos, para comprobar que el sistema hace lo que se espera que haga a diferencia
de que cumpla con lo que se ha especificado.
Los procesos de V&V cubren el ciclo de vida de desarrollo completo. El proceso

se inicia con la revisión de la especificación de requisitos y continua con la revisión
de la arquitectura, el diseño, las inspecciones y pruebas de código hasta las pruebas
funcionales del sistema. Los procesos de V&V tienen actividades en cada una de las
fases de desarrollo del software.
8.1. Proceso de verificación
Entre los procedimientos de verificación que se realizan están los siguientes

grupos de comprobaciones o pruebas del sistema organizados en diferentes niveles:
Inspecciones: Las inspecciones se realizan tanto a la documentación generada

como a los modelos de análisis y diseño del sistema. Dentro de la documen-
tación inspeccionada se encuentra la especificación de requisitos software del
sistema. Las inspecciones analizan y comprueban tanto los contenidos y repre-
sentaciones como la trazabilidad entre elementos de los diferentes artefactos
del proyecto.
Pruebas unitarias: Las pruebas unitarias se ejecutan a nivel de módulo im-
plementado. El objetivo de estas pruebas es verificar que la funcionalidad que
debe cumplir cada módulo con su interfaz esta acuerdo con las especificaciones
y es valido.
78 8 VERIFICACIÓN Y VALIDACIÓN DEL SISTEMA
Prueba de integración: Las pruebas de integración se ejecutan a nivel de

componentes. El objetivo de estas es verificar los errores por combinación de
los módulos probados unitariamente y verificar las interfaces externas de estos.
Con estas pruebas se verifican las especificaciones de diseño del sistema.
Pruebas de sistema: Estas pruebas se realizan a nivel de sistema y el obje-

tivo es verificar que el sistema cumple con la especificación de requisitos del
mismo. Entre las pruebas de sistema se encuentran diferentes tipos: pruebas
de funcionalidad, pruebas de usabilidad, pruebas de rendimiento, pruebas de
seguridad, pruebas de esfuerzo, etc.
Todas las pruebas son especificadas, documentadas y trazadas adecuadamente,

igualmente se realiza con las iteraciones de verificación y sus resultados.
8.2. Proceso de validación
El proceso de validación del proyecto consiste en realizar las pruebas de acep-

tación especificadas para el cliente.
El objetivo de las pruebas de aceptación es validar que un sistema cumple con

el funcionamiento esperado y permitir al usuario de dicho sistema que determine
su aceptación, desde el punto de vista de su funcionalidad y rendimiento. En las
pruebas de aceptación, la ejecución y aprobación final corresponden al usuario o
cliente, que es el que valida y verifica que el alcance es el correcto.
79
9. RESULTADOS Y CONCLUSIONES
En esta sección se comentaran los resultados y conclusiones obtenidas en el

desarrollo del trabajo.
9.1. Resultados
El desarrollo del proyecto ha utilizado un ciclo de vida iterativo. Es decir, los

requisitos se han agrupado en conjuntos y cada conjunto se ha ido implementando en
cada iteración de desarrollo. En cada fase de iteración se han realizado las siguientes
tareas:
Análisis y estudio de los requisitos seleccionados.
Desarrollo del modelo de análisis.
Implementación del diseño HRT-HOOD.
Implementación del código según el diseño obtenido.
Análisis y resolución de los defectos encontrados en fases de verificación en

iteraciones previas.
Implementación de las nuevas pruebas unitarias de los módulos desarrolla-

dos, adaptación de las existentes, ejecución de todas y resolución de los fallos
encontrados.
Implementación de las nuevas pruebas de integración de los componentes del

sistema, adaptación de las existentes, ejecución de todas y resolución de los
fallos encontrados.
Ejecución de las pruebas funcionales integradas con el HW real.
Una vez alcanzado un hito, el sistema pasaba las pruebas de aceptación con el
cliente en las instalaciones del cliente en el tren con el resto de sistemas reales con
los que interactúa.
Al final de todas las iteraciones, el cliente dio por terminado el desarrollo y por
aceptado el producto. Los sistemas fueron instalados en todas las unidades (trenes)
desarrolladas y estos fueron enviados a las instalaciones del cliente final para la
explotación de los mismos.
80 9 RESULTADOS Y CONCLUSIONES
9.2. Conclusiones
El objetivo principal del proyecto es el desarrollo de un sistema embebido de

tiempo real utilizando un sistema operativo de tiempo real de distribución libre como
puede ser Linux. Este desarrollo necesita cumplir un objetivo secundario previo antes
de iniciar la implementación del sistema. El objetivo secundario es la elección del
sistema operativo que mejor se adapte a las necesidades del sistema de tiempo real
que se va a desarrollar.
Para el objetivo secundario se tiene que tener en cuenta que un sistema opera-
tivo de tiempo real debe cumplir una serie de requisitos especiales además de cumplir
los que cumple un sistema operativo de ámbito normal.
En los sistemas de tiempo real las respuestas de los eventos se deben tener
en un determinado tiempo, es decir la respuesta no debe ser rápida sino que debe
estar dentro de un intervalo de tiempo determinado. Esto implica que las tareas
de tiempo real se deben ejecutar completamente dentro de un intervalo de tiempo
lı́mite, llamado deadline. Este requisito debe estar garantizado en un sistema de
tiempo real que debe cumplir con todas las restricciones crı́ticas de tiempo en la
ejecución de las tareas del sistema.
Después de analizar las soluciones de software libre existentes respecto a sis-

temas operativos de tiempo real, una de las tendencias más utilizada actualmente
es utilizar un nano-kernel de tiempo real que ejecuta el kernel estándar de Linux
como una tarea de baja prioridad. Dentro de esta tendencia se encuentra la solución
Xenomai basada en el nano-kernel ADEOS, la cual ha sido la solución elegida para
la implementación del sistema.
La elección de Xenomai para la implementación del sistema aporta las siguien-

tes caracterı́sticas al sistema operativo:
Desarrollo en la plataforma Linux y en el ámbito de distribución de código

abierto, permitiendo un amplio soporte gracias a su gran comunidad de desa-
rrolladores.
Buenos rendimientos en tiempos crı́ticos en sistemas de tiempo real, bajo delay

y bajo jitter.
Aporta prioridades en la ejecución de tareas, lo que permite establecer priori-

dades según la criticidad de las tareas.
Por otro lado, el propio desarrollo de un sistema de tiempo real necesita apli-
car una serie de metodologı́as propias de estos con una serie de herramientas que
9.2 Conclusiones 81
permiten abordar los problemas caracterı́sticos de estos sistemas. En este proyecto

las metodologı́as propias de sistemas de tiempo real estudiadas y utilizadas son las
siguientes: “Análisis Moderno Estructurado”para el análisis del sistema y “HRT-
HOOD”para el diseño del mismo.
El objetivo principal del proyecto es el desarrollo de un sistema de tiempo

real crı́tico, concretamente el registrador jurı́dico ferroviario, el cual ha sido logrado
satisfactoriamente. Alcanzar este objetivo ha permitido estudiar y evaluar las fases
de desarrollo de estos tipos de sistemas incluso llegar hasta la implantación del
mismo en una flota de trenes para una lı́nea de metro especı́fica real.
9.2 Conclusiones 83
ANEXOS
Referencias 85
Referencias
[1] A. Burns, A.J. Wellings, “HRT-HOOD. A Structured Design Method for Hard
Real-time Systems”. Real-time and Distributed Systems Research Group, De-
partment of Computer Science University of York, Heslington, York, YO1 5DD,
UK.
[2] A. del Barrio, L. Barros, P. López, J.M. Drake, “Actas de las XIII Jornadas de
Tiempo Real”. Departamento de Lenguajes y Sistemas Informáticos, Universi-
dad de Granada. Feb, 2010.
[3] Edward Yourdon, “Análisis Estructurado Moderno”. 1993.
[4] Jan Kiszka, “Xenomai 3 – An Overview of the Real-Time Framework for Li-
nux”. Corporate Technology. Abr, 2016.
[5] Juan Antonio de la Puente, “Diseño de sistemas de tiempo real - Introducción

a HRT-HOOD”. DIT, UPM. 1997, 1998.
[6] J.M. Drake, P. López, “Verificación y Validación”. Departamento de Lenguajes

y Sistemas Informáticos, Universidad de Granada. 2009.
[7] Wikipedia, la enciclopedia libre, “C (lenguaje de programación)”. Abr, 2018.
[8] Wikipedia, la enciclopedia libre, “Especificación de requisitos de software”. Abr,

2018.
[9] Wikipedia, la enciclopedia libre, “Método en V”. Abr, 2018.
[10] Wikipedia, la enciclopedia libre, “Programación estructurada”. May, 2018.
[11] Wikipedia, la enciclopedia libre, “RTAI”. Nov, 2017.
[12] Wikipedia, la enciclopedia libre, “RTLinux”. Nov, 2017.
[13] Wikipedia, la enciclopedia libre, “Sistema de tiempo real”. Dic, 2017.
[14] Wikipedia, la enciclopedia libre, “Sistema operativo de tiempo real”. Nov, 2017.
[15] Wikipedia, la enciclopedia libre, “Tiempo real”. Sep, 2015.
[16] Wikipedia, la enciclopedia libre, “Xenomai”. Ago, 2017.
[17] Xenomai Development Group, “Xenomai”. www.xenomai.org.

PFC Victor Sanchez Munoz PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PFC Victor Sanchez Munoz PDF

Cargado por

Copyright:

Formatos disponibles

Escuela Técnica Superior de Ingenieros

Proyecto Fin de Carrera

AUTOR: Vı́ctor Sánchez Muñoz

Madrid, 06 de julio de 2018

Papa, estés donde estés, esto ya está chupado.

Quiero agradecer muy especialmente

a mi mujer y pareja, Mónica, porque me acompaña y apoya siempre en este

a mi tutor, Juan, gracias por ayudarme a llevar esto a buen puerto.

El objetivo principal de este proyecto es el desarrollo de un sistema embebido de

Además, existe un objetivo secundario que es la implementación del sistema

1.1. Propósito y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3. Registrador jurı́dico Ferroviario . . . . . . . . . . . . . . . . . . . . . 2

1.3.2. Registrador jurı́dico ferroviario . . . . . . . . . . . . . . . . . 3

1.3.3. Event Recorder de SEPSA . . . . . . . . . . . . . . . . . . . . 4

1.4. Deﬁniciones, acrónimos y abreviaturas . . . . . . . . . . . . . . . . . 5

1.5. Contenido del documento . . . . . . . . . . . . . . . . . . . . . . . . 7

2. SISTEMAS EMBEBIDOS DE TIEMPO REAL . . . . . . . . . . . . 9

2.1. Caracterı́sticas de los sistemas de tiempo real . . . . . . . . . . . . . 9

2.2. Computación en tiempo real . . . . . . . . . . . . . . . . . . . . . . . 10

2.3. Sistemas operativos de tiempo real . . . . . . . . . . . . . . . . . . . 10

2.3.1. Caracterı́sticas de los sistemas operativos de tiempo real . . . 11

2.3.2. Distribuciones de sistemas operativos de tiempo real . . . . . 13

2.3.3. Linux de tiempo real . . . . . . . . . . . . . . . . . . . . . . . 17

2.4. Conclusiones en la elección del sistema operativo de tiempo real . . . 23

3. METODOLOGÍAS DE DESARROLLO SOFTWARE UTILIZADAS 25

3.1. Análisis Estructurado Moderno . . . . . . . . . . . . . . . . . . . . . 25

3.1.1. Modelo esencial . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.2. Modelo de implantación del usuario . . . . . . . . . . . . . . . 26

3.3. Paradigma estructurado . . . . . . . . . . . . . . . . . . . . . . . . . 28

4. ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA . . . . . . . . 33

4.1. Listado de los principales casos de uso del sistema . . . . . . . . . . . 34

4.2. Descripción detallada de los casos de uso del sistema . . . . . . . . . 35

4.2.1. Calcular los datos de odometrı́a . . . . . . . . . . . . . . . . . 35

4.2.3. Actualizar los indicadores leds del equipo . . . . . . . . . . . . 37

4.2.4. Visualizar el estado del sistema por el operador . . . . . . . . 38

4.2.5. Descargar el ﬁchero de registro completo por el operador. . . . 38

4.3. Descripción detallada de los requisitos no funcionales del sistema . . . 39

4.3.1. Periodo de registro de las señales digitales . . . . . . . . . . . 40

4.3.2. Periodo de actualización del ﬁchero de registro . . . . . . . . . 40

4.3.3. Capacidad del ﬁchero de registro . . . . . . . . . . . . . . . . 41

5. ANÁLISIS DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . 43

5.1. Modelo ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1. Declaración de propósitos . . . . . . . . . . . . . . . . . . . . 43

5.1.2. Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . 44

5.1.3. Lista de acontecimientos . . . . . . . . . . . . . . . . . . . . . 44

5.2. Modelo de comportamiento . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1. Nivel 01. Event Recorder . . . . . . . . . . . . . . . . . . . . . 46

5.2.2. Nivel 02. Odometry Management . . . . . . . . . . . . . . . . 47

5.2.3. Nivel 02. Time Management . . . . . . . . . . . . . . . . . . . 48

5.2.4. Nivel 02. External Interfaces Management . . . . . . . . . . . 49

5.2.5. Nivel 02. EVR Status Management . . . . . . . . . . . . . . . 50

5.2.6. Nivel 02. Record File Management . . . . . . . . . . . . . . . 51

5.2.7. Nivel 02. Conﬁguration Management . . . . . . . . . . . . . . 53

6. DISEÑO DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1. Event Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2. Date/Time Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3. Odometry Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4. Events Recording Manager . . . . . . . . . . . . . . . . . . . . . . . . 59

6.6. Operator Communications Manager . . . . . . . . . . . . . . . . . . . 66

6.7. System Status Manager . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.8. Conﬁguration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7. IMPLEMENTACIÓN DEL SISTEMA . . . . . . . . . . . . . . . . . 71