PFC Victor Sanchez Munoz PDF
PFC Victor Sanchez Munoz PDF
Informáticos
Universidad Politécnica de Madrid
Desarrollo de un Sistema de
Registro Jurı́dico Ferroviario
Utilizando un Sistema Operativo
de Tiempo Real de Libre
Distribución
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.
AGRADECIMIENTOS
a mis padres, José y Maribel, porque sin ellos simplemente esto no hubiese sido
posible.
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.
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
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 también
tiene ciertas particularidades y se desarrollan con una serie de metodologı́as ideadas
especialmente para este propósito. En este proyecto se describirán algunas de estas
metodologı́as y se mostrará como se realiza el desarrollo de un sistema de tiempo
real con la aplicación de estas metodologı́as.
Índice
1. INTRODUCCIÓN Y OBJETIVOS . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3.4. RTLinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5. RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.6. Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. HRT-HOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Lenguaje C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5. Método en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2. Registrar los cambios de estado de las señales digitales del tren 36
6.1.1. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
x Índice
6.5. IO Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.5.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.1. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.7.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.8.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.8.2. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2. Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9. RESULTADOS Y CONCLUSIONES . . . . . . . . . . . . . . . . . . 79
9.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
xii Índice
Índice de cuadros xiii
Índice de cuadros
Índice de figuras
1. Arquitectura Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2. Interfaces RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Reglas de descomposición . . . . . . . . . . . . . . . . . . . . . . . . 27
4. Reglas de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Método en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Diagrama de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. IO Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1. INTRODUCCIÓN Y OBJETIVOS
El primer problema que se tiene que resolver antes de comenzar con el desa-
rrollo es establecer cual será el sistema operativo de libre distribución que reú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 realizará
un análisis de la oferta actual respecto a sistemas operativos de tiempo real y se
llegará a la conclusión de cual será la mejor opción para el desarrollo del sistema.
Una vez tomada la decisión del sistema operativo a utilizar para desarrollar
el registrador jurı́dico, se realizará el desarrollo del sistema utilizando técnicas de
desarrollo software orientadas a sistemas embebidos y de tiempo real.
1.2. Objetivos
van a estudiar para la elección del sistema operativo serán distribuciones de Linux
adaptadas a necesidades de sistemas de tiempo real.
Además del objetivo principal, también se deberá 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 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.
Una vez terminado el estudio de los sistemas operativos de tiempo real del
mercado basados en Linux, se deberá concluir cual será el elegido para desarrollar
el sistema del registrador jurı́dico y los motivos por los que se ha seleccionado.
1.3.1. Historia
Aunque la caja negra propiamente dicha es obra del australiano David Warren,
que en 1953 se le encomendó la tarea de descubrir la causa de una serie de accidentes
aéreos y para ello diseño un dispositivo de grabación de audio en la cabina del piloto.
En 1958, Warren diseño el primer prototipo de la Unidad de Memoria de Vuelo capaz
de grabar más de 4 horas de conversación de cabina y lecturas de mandos en una
bobina de acero magnetizado.
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 aceleració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 tacógrafo que mide
y almacena todo lo que ocurre en el tren al menos una media hora antes.
4 1 INTRODUCCIÓN Y OBJETIVOS
Operaciones de autochequeo.
Término Definición
HAL Hardware Abstraction Layer (Capa de Abstracción
de Hardware)
HOOD Hierarchical Object Oriented Design (Diseño
Jerá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-
sión Electrotécnica Internacional)
I/O Input/Output (Entrada/Salida)
IP Internet Protocol (Protocolo de Internet)
IPC Inter-Process Communication (Comunicación En-
tre Procesos)
ISO International Organization for Standardization
(Organización Internacional de Normalizació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
Lógico Programable)
PL/I Programming Language 1 (Lenguaje de Programa-
ción 1)
POSIX Portable Operating System Interface (Interfaz
Está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 Electŕonicos de Potencia, S.A.
SI Sistemas Informáticos
SMP Symmetric Multi-Processing (MultiProceso
Simétrico)
SIL Safety Integrity Level (Nivel de Integración de Se-
guridad)
1.5 Contenido del documento 7
Término Definición
SPI Serial Peripheral Interface (Interfaz de Periféricos
Serie)
SRT Soft Real-Time (Tiempo Real No Crı́tico)
TCP Transmission Control Protocol (Protocolo de Con-
trol de Transmisión)
UP UniProcessor (UniProcesador)
USB Universal Serial Bus (Bus Serie Universal)
V&V Verificación y Validación
Tab. 1: Términos, acrónimos y abreviaturas del proyecto.
Los sistemas de tiempo real se aplican a sectores de nuestra vida diaria como
por ejemplo: los aviones, los trenes, los automóviles, los televisores, las lavadoras,
los hornos microondas, los teléfonos móviles o las centrales telefónicas digitales.
También, aseguran la generación, transmisión y distribución de la energı́a eléctrica
y la calidad y seguridad de incontables procesos industriales.
Los sistemas de tiempo real cumplen tres condiciones básicas: interactúan con
el mundo real (proceso fı́sico), emite respuestas correctas y cumple 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 daño del motor; sistemas mé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 número de sistemas conectados. Ejemplos de sistemas pasivos
serı́a el sistema que gestiona los planes de vuelo de las compañı́as aé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.
cumpliendo con las restricciones temporales del sistema. Además, un sistema ope-
rativo de tiempo real debe proporcionar determinismo y hacer predecibles a las
aplicaciones de tiempo real que ejecuta.
Multi-arquitectura.
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 planificación especializado y a la
tasa de interrupción de reloj elevada.
Diseño
Sistema operativo guiado por eventos. Solo cambia de tarea cuando un evento
necesita un servicio.
Planificación
Semáforos. Los problemas con los diseños con semáforos son los siguientes:
inversión de prioridades (tareas más prioritarias están bloqueadas por tareas
menos prioritarias que poseen el semáforo) y puntos muertos (deadlocks) o
interbloqueos.
Mensajes. Tiene los mismos problemas que los semáforos: inversión de priori-
dades y puntos muertos.
Interrupciones
Memoria
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.
Haiku
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 OS for Safety: La versión está diseñada para cumplir las normas ISO
26262 en ASIL D y las normas IEC 61508 en SIL3. Se utiliza en sistemas
crı́ticos de automóviles, trenes y automatización industrial.
QNX OS for Medical: La versión está diseñada para cumplir las normas
IEC 62304. Se utiliza en sistemas crı́ticos médicos que requieren aprobaciones
regulativas.
2.3 Sistemas operativos de tiempo real 15
QNX OS for Security: La versión está diseñada para cumplir las normas
ISO/IEC 15408 EAL 4.
RT-11
MaRTE OS
LynxOS RTOS
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
16 2 SISTEMAS EMBEBIDOS DE TIEMPO REAL
Se comenzó a desarrollar por la empresa Red Hat, que en el 2004 delegó sus
derechos a la Free Software Foundation.
Drivers para puerto serie, ethernet, SPI, I2C, framebuffer, CAN, ADC, entre
otros.
VxWorks
Windows CE
Symbian
El objetivo del Symbian era crear un sistema operativo para terminales mó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
FreeRTOS
Una de las soluciones adoptadas fueron las basadas en hypervisor, las cuales
ejecutan Linux junto con un RTOS más dedicado. El problema de estas soluciones
es que incrementan la complejidad del sistema en detrimento de la usabilidad y
demandan una mayor especialización de los equipos de diseño embebido perdiendo
la esencia de utilizar Linux.
2.3.4. RTLinux
RTLinux es una distribución de Linux de tiempo real que ejecuta Linux como
un hilo de menor prioridad que los hilos de tiempo real. Este diseñ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 estándar en la misma máquina. Las tareas
de tiempo real como los manejadores de interrupciones ejecutan cuando se necesita
2.3 Sistemas operativos de tiempo real 19
Historia
En octubre del 2015 el proyecto pasa a estar tutelado por la Linux Foundation,
con la colaboración de compañı́as como Google, Intel, ARM, IBM, Qualcomm o
SanDisk entre otras para rescatar el proyecto.
Caracterı́sticas
Extensiones
2.3.5. RTAI
Caracterı́sticas
2.3.6. Xenomai
Historia
La primera versión de Xenomai (Xenomai 1.0) se lanzó en agosto del 2001 como
un framework de portabilidad para aplicaciones RTOS. En el 2003 se fusionó 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 versión
implementaba un tiempo real básico y desarrolló la capa ADEOS para Linux y
RTAI.
Caracterı́sticas
Xenomai se basa en una arquitectura que mantiene activos dos núcleos si-
multáneamente, el de tiempo real con las caracterı́sticas y recursos propios de un
sistema operativo de tiempo real y un núcleo Linux estándar que mantiene todas
las caracterı́sticas y recursos de Linux. Entre ambos núcleos existen mecanismos de
comunicación que preservan la predictibilidad que requieren los sistemas de tiempo
real.
Existe una capa de virtualización, llamada ADEOS, que permite que coexistan
ambos núcleos interceptando las interrupciones del hardware y redirigiéndolas a am-
bos núcleos. ADEOS permite que la transición de ejecución entre ambos núcleos sea
muy ligera consiguiendo que el tiempo de latencia de respuesta a las interrupciones
hardware sean mı́nimos.
Ademá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 número de
funciones, la mayorı́a pueden ser invocadas tanto desde el espacio del usuario como
del núcleo. Las diferentes familias de servicios son las siguientes:
tareas de tiempo real y entre é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).
Esta tendencia permite un mayor control de las latencias y por lo tanto un mayor
determinismo. Dentro de la tendencia del nano-kernel están las extensiones para Li-
nux: RTAI (Real-Time Application Interface) y Xenomai. Ambas alternativas están
basadas en el nano-kernel ADEOS (Adaptive Domain Environment for Operating
Systems).
Las metodologı́as utilizadas en este proyecto son muy especı́ficas para el desa-
rrollo de sistemas embebidos de tiempo real aunque también se utilizan en otros
ámbitos de desarrollo software.
Este modelo representa lo qué 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 especificación de los procesos. El modelo esencial a su vez está 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:
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. También, se identifican las actividades manuales para dar soporte al sistema
y las restricciones operacionales.
3.2. HRT-HOOD
Mayor facilidad de entender los programas, los programas son secuenciales (sin
GOTO).
Estructura clara de los programas, ya que las instrucciones están más relacio-
nadas entre sı́.
Esfuerzo optimizado en las fases de prueba y depuración.
Costes de mantenimiento reducidos.
3.4 Lenguaje C 29
3.4. Lenguaje C
Débilmente tipificado.
Lenguaje mas portado en existencia, existen compiladores para casi todas las
plataformas conocidas.
30 3 METODOLOGÍAS DE DESARROLLO SOFTWARE UTILIZADAS
3.5. Método en V
El mé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 integración de las piezas y
su verificación. V significa ((Verificación y vendeta)). Es un método muy similar al
modelo de la cascada clásico ya que es muy rı́gido y contiene una gran cantidad de
iteraciones.
Fig. 5: Método en V
Reducció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.
Las caracterı́sticas que debe tener una buena especificación de requisitos soft-
ware son las siguientes:
Completa: Todos los requisitos del sistema deben estar incluidos en la espe-
cificación y las referencias deben estar bien definidas.
Consistente: Los requisitos deben ser coherentes entre ellos y con otros do-
cumentos de especificación.
Verificable: Se debe poder demostrar que el sistema cumple con los requisitos
especificados.
34 4 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA
Ahora, se describirán de forma detalla algunos de los casos de uso del sistema.
Se elegirán los más representativos para que sirvan de muestra del proceso ya que el
objetivo de esta memoria no es servir de documento de descripción de casos de uso
sino para describir el proceso llevado a cabo.
Identificador: EVR-UC-0001
Actores: N/A
36 4 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA
Trigger: Timer.
Pre-Condición: N/A
Flujo normal:
Inclusiones: N/A
Notas: N/A
4.2.2. Registrar los cambios de estado de las señales digitales del tren
Identificador: EVR-UC-0004
Nombre: Registrar los cambios de estado de las señales digitales del tren
Actores: N/A
Trigger: Timer
Pre-Condición: N/A
4.2 Descripción detallada de los casos de uso del sistema 37
Flujo normal:
Inclusiones: N/A
Notas: N/A
Identificador: EVR-UC-0009
Actores: N/A
Trigger: Timer
Pre-Condición: N/A
Flujo normal:
Inclusiones: N/A
Frecuencia de uso: 10 ms.
Notas: N/A
Identificador: EVR-UC-0012
Nombre: Visualizar el estado del sistema por el operador
Actores: Operador
Descripción: El operador solicita visualizar el estado del sistema mediante
la interfaz web de mantenimiento del equipo.
Trigger: Solicitud del operador.
Pre-Condición: El operador está identificado en el sistema.
Post-Condició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.
Flujos alternativos: N/A
Inclusiones: N/A
Frecuencia de uso: N/A
Notas: N/A
Identificador: EVR-UC-0015
Nombre: Descargar el fichero de registro completo por el operador.
Actores: Operador
Descripción: El operador solicita la descarga del fichero de registro completo
mediante la interfaz web de mantenimiento del equipo.
4.3 Descripción detallada de los requisitos no funcionales del sistema 39
Flujo normal:
Inclusiones: N/A
Notas: N/A
Identificador: EVR-REQ-0038
Estado: APROBADO
Prioridad: ALTA
Importancia: ESENCIAL
Estabilidad: ALTA
Notas: N/A
Identificador: EVR-REQ-0053
Estado: APROBADO
Prioridad: ALTA
Importancia: ESENCIAL
Estabilidad: ALTA
Notas: N/A
4.3 Descripción detallada de los requisitos no funcionales del sistema 41
Identificador: EVR-REQ-0056
Estado: APROBADO
Prioridad: ALTA
Importancia: IMPORTANTE
Estabilidad: MEDIA
Notas: N/A
42 4 ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA
43
En este modelo se definen los elementos que son parte del sistema y los que
están fuera del mismo. Para ello, hay que definir los interfaces del sistema con el
resto de elementos que le rodean.
Este modelo está formado por los siguientes artefactos: Declaración de propósi-
tos, diagrama de contexto y lista de acontecimientos.
El propósito del Event Recorder es registrar el estado del tren y los eventos
que se producen en este y que son recibidos a través de los interfaces del sistema
con los otros sistemas del tren con fines legales.
44 5 ANÁLISIS DEL SISTEMA
3. El sistema recibe un cambio de fecha y hora del tren procedente del interfaz
MVB del tren. (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 través de la interfaz
de mantenimiento. (C)
18. El operario solicita una descarga del fichero de registro mediante el puerto
USB. (C)
Procesos
Procesos
Procesos
Procesos
Este diagrama gestiona la funcionalidad de gestión del estado interno del sis-
tema.
5.2 Modelo de comportamiento 51
Procesos
EVR Status Visualization: Este proceso gestiona el envı́o del estado interno
del sistema bajo demanda del operador.
Procesos
Record File Updating: Este proceso gestiona las actualizaciones del fichero
de registro con los paquetes pendientes de ser registrados periódicamente.
Record File Erasing: Este proceso gestiona las peticiones de borrado del
fichero de registro por parte del operario a través de la interfaz de manteni-
miento del sistema.
5.2 Modelo de comportamiento 53
Procesos
Este objeto es el objeto principal, el sistema. Los objetos que lo componen son
los objetos que gestionan la funcionalidad principal del sistema.
6.1.1. Objetos
Este módulo gestiona las funciones de fecha y hora del sistema. Sus principales
funciones son actualizar la fecha y hora instantánea del sistema y gestionar las
actualizaciones de fecha y hora recibidas de fuentes externas.
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 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.1. Interfaz
6.3.2. Objetos
Odometry Supervisor: Este objeto cı́clico calcula los valores de los datos
de odometrı́a (velocidad, aceleración, distancia, estado de los tacos) según los
pulsos recibidos y los actualiza en el sistema.
Tach Pulse Handler: Objeto esporádico que se activa al detectar un pulso del
taco. Este objeto al detectar el pulso lo registra para su posterior tratamiento.
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
6.5. IO Manager
6.5.1. Interfaz
6.5.2. Objetos
MVB Output Supervisor: Este objeto enviará los mensajes del equipo por
MVB periódicamente gestionando el protocolo MVB.
Led Supervisor: Este objeto actualizará las señales led de indicación con la
información del sistema periódicamente.
66 6 DISEÑO DEL SISTEMA
Este mó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 información, actualización, descarga del registro o borrado del mismo
por parte del operario de mantenimiento.
6.6.1. Objetos
6.7.1. Interfaz
6.7.2. Objetos
MVB Data Processor: Este objeto leerá la información recibida por MVB
y la actualizará cı́clicamente en el objeto System Status Data Store.
6.8.1. Interfaz
6.8.2. Objetos
Objetos Pasivos: Por cada objeto pasivo se genera un módulo siendo cada
operación una función o procedimiento del mismo.
7.2. Xenomai
Xenomai ofrece una API para acceder a su funcionalidad. La API está dividida
en módulos según la funcionalidad que gestionan. Existen módulos para gestionar
las tareas, los mutex, los semáforos, las colas de mensajes, las alarmas y señales, los
buffers, las variables condiciones, etc.
Xenomai necesita que toda la memoria esté 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 funció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
Además, será 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 ) ;
Los objetos activos serán módulos en C que contengan de forma privada sus
submódulos de diferentes tipos. Estos objetos proporcionarán una interfaz a los
módulos que los usen.
Primer método:
// 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 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 ) ;
74 7 IMPLEMENTACIÓN DEL SISTEMA
Segundo método:
// 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 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 ) ;
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 .
...
Estos módulos serán implementados igual que los cı́clicos salvo que la tarea se
ejecutará cı́clicamente pero cada iteración se hará esperando a que salte la interrup-
ción asociada.
// 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 .
...
// Se c r e a e l mutex .
r t m u t e x c r e a t e (& MutexDescriptor , ”NombreMutex” ) ;
// 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 ) ;
9. RESULTADOS Y CONCLUSIONES
9.1. Resultados
Una vez alcanzado un hito, el sistema pasaba las pruebas de aceptación con el
cliente en las instalaciones del cliente en el tren con el resto de sistemas reales con
los que interactú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
explotación de los mismos.
80 9 RESULTADOS Y CONCLUSIONES
9.2. Conclusiones
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 además de cumplir
los que cumple un sistema operativo de á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 rá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
ejecución de las tareas del sistema.
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
ANEXOS
84 9 RESULTADOS Y CONCLUSIONES
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. López, J.M. Drake, “Actas de las XIII Jornadas de
Tiempo Real”. Departamento de Lenguajes y Sistemas Informáticos, Universi-
dad de Granada. Feb, 2010.
[4] Jan Kiszka, “Xenomai 3 – An Overview of the Real-Time Framework for Li-
nux”. Corporate Technology. Abr, 2016.
[14] Wikipedia, la enciclopedia libre, “Sistema operativo de tiempo real”. Nov, 2017.