# ARINC 653

ARINC 653 (Avionics Application Standard Software Interface) es una especificación software para el particionado de tiempo y espacio en sistemas operativos de tiempo real críticos para aviónica. Permite la ejecución de varios aplicaciones en diferentes niveles software en un hardware común en el contexto de arquitecturas de aviónica integrada modular. Esta especificación es parte de la serie ARINC 600.

## Visión general

Con el fin de desacoplar la plataforma del sistema operativo en tiempo real de la aplicación Software, ARINC 653 define una API denominada APEX (APplication EXecutive).
Cada aplicación software se denomina partición y contiene su propio espacio de memoria aislado. Cada partición tiene, además, un espacio de tiempo asignado por la API APEX. Dentro de cada partición, se permite la ejecución de varias tareas. APEX provee servicios para el manejo de particiones, procesos y tiempo, así como rutinas para manejar de errores y servicios de comunicación entre particiones y procesos. Aunque no es un requisito, el entorno de participando se puede implementar mediante un hipervisor, para asignar particiones a máquinas virtuales o contenedores.
Actualmente, el subcomité AEEC APEX trabaja en incluir mejoras para el soporte de arquitecturas multi procesador en ARINC 653.

## Historia
### Versión Inicial

La primera versión de ARINC 653 se publicó el 10 de octubre de 1996.

### ARINC 653-1

La primera revisión del estándar se publicó en enero de 1997, introduciendo el concepto de APEX y el participando de tiempo y espacio.

### ARINC 653-2

La segunda revisión del estándar consta de tres partes que se publicaron entre marzo de 2006 y enero de 2007.
* La primera parte (servicios indispensables) define el manejo de particiones, así como los conceptos de arranque en frío y arranque en caliente. Además introduce las funcionalidades de manejo de errores en software y las APIs en Ada y C.
* La segunda parte (servicios opcionales), define los requisitos para el acceso a sistema de archivos, registro de datos y puntos de acceso entre otros.
* Por último, la tercera parte especifica las pruebas que debe pasar un sistema para ser certificado para ARINC 653.

### Organización actual del Estándar

* Parte 0 - Introducción a ARINC 653 (primera revisión en junio de 2013)
* Parte 1: Servicios Indispensables (cuarta revisión en agosto de 2015)
* Parte 2: Servicios Adicionales (tercera revisión en agosto de 2015)
* Parte 3: Pruebas de Conformidad (primera revisión el 16 de octubre de 2006)
* Parte 4: Subconjunto de Servicios (primera revisión en junio de 2012)
* Parte 5: Características recomendadas para el núcleo software. (primera revisión en diciembre de 2014)

## Principios básicos del particionado

Una plataforma ARINC 653 contiene:
* Una plataforma hardware que permite la computación en tiempo real determinista.
* Una capa de abstracción que majea las limitaciones de particionado de tiempo y espacio (memoria, CPU, Entrada/Salida).
* Implementación de la API APEX.
* Una interfaz para configurar la plataforma y su dominio de uso.
* Varias herramientas de instrumentación.

### Inicialización

En la rutina de inicialización de una partición en ARINC 653 se crean los recursos necesarios por la partición, como por ejemplo tareas (PROCESS), eventos (EVENT) y semáforos (SEMAPHORE) entre otros. Cada uno de estos recursos se crean mediante llamadas a la API con nombre CREATE_xxxx, por ejemplo, CREATE_PROCESS.

### Manejo de Errores

El manejo de errores y excepciones en una partición se realiza de forma apropiativa mediante un proceso que tiene asignada la máxima prioridad. Este proceso se crea en la etapa de inicialización de la partición mediante el servicio de la API CREATE_ERROR_HANDLER.
La API permite al proceso de manejo de errores detener la ejecución de un proceso que ha fallado mediante el servicio STOP_SELF. En este caso, el planificador del sistema operativo de tiempo real comienza a ejecutar el siguiente proceso con mayor prioridad.
El estándar ARINC 653 no especifica qué debe hacer el planificador si el proceso de manejo de errores no detiene la ejecución del proceso que ha fallado. En algunos casos (teóricos), esto puede dar lugar a un bucle infinito entre la aplicación que esta fallando y el proceso de manejo de errores.
El proceso de manejo de errores puede obtener información sobre la fuente y el contexto del error o excepción.

### Administración de modo

Cada partición puede estar en varios estados:
* COLD_START y WARM_START: Sólo el proceso de inicialización está en ejecución.
* NORMAL: El proceso de inicialización ha terminado, y los otros procesos de la partición se ejecutan por el planificador en función de su prioridad,
* IDLE: Ningún proceso se está ejecutando. Aun así, en teoría, algún proceso con la prioridad más baja podría comenzar a ejecutarse, por ejemplo un proceso que inicia un bucle infinito.
El servicio SET_PARTITION_MODE de la API permite seleccionar estos estados. Puede ser llamado por cualquier proceso en la partición. La entrada en modo IDLE es irreversible y solo un evento externo (por ejemplo el reinicio del sistema) puede cambiar este estado.

### Procesos de una partición

Cada partición tiene al menos un proceso. La planificación de procesos es apropiativo. El planificador se llama mediante un temporizador, o mediante la API.

## APEX, API de ARINC 653

La API de ARINC 653, APEX, contiene funcionalidades clasificadas en seis categorías:
* Administración de particiones
* Administración de procesos
* Administración de participando de tiempo
* Comunicación entre particiones
* Comunicación dentro de una misma partición
* Manejo de errores
APEX no define APIs para la administración de memoria, por lo tanto, cada partición debe manejar su propia memoria (aunque cumpliendo con las limitaciones de participando de memoria requeridos por ARINC 653).
Cada servicio de la API devuelve uno de los códigos de error que se definen a continuación para indicar si la llamada al servicio ha sido exitosa o se ha producido algún fallo.
* NO_ERROR: no se ha producido ningún error
* NO_ACTION: el estado del sistema no ha cambiado después de ejecutar el servicio
* NOT_AVAILABLE: el servicio no se encuentra disponible
* INVALID_PARAM: al menos uno de los parámetros del servicio es no es válido
* INVALID_CONFIG: al menos uno de los parámetros del servicio es incompatibles con la configuración actual del sistema
* INVALID_MODE: el servicio es incompatible con el modo actual del sistema
* TIMED_OUT: se ha alcanzado el tiempo límite de ejecución del servicio

## Enlaces a POSIX y ASAAC

El dominio cubierto por ARINC 653 y ASAAC Def Stan 00-74 son similares. Aun así, hay diferencias entre los dos estándares.
Algunas APIs de APEX tienen equivalentes POSIX, pero su definición puede diferir de la descrita en POSIX.
Por ejemplo, la siguiente llamada definida en ASAAC:
Sería equivalente a la de esta función APEX:
Y también sería equivalente en POSIX a: