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.
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.
La primera versión de ARINC 653 se publicó el 10 de octubre de 1996.
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.
La segunda revisión del estándar consta de tres partes que se publicaron entre marzo de 2006 y enero de 2007.[1]
Una plataforma ARINC 653 contiene:
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.
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.
Cada partición puede estar en varios estados:
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.
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.
La API de ARINC 653, APEX, contiene funcionalidades clasificadas en seis categorías:
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.
El dominio cubierto por ARINC 653 y ASAAC Def Stan 00-74 son similares. Aun así, hay diferencias entre los dos estándares.[8]
Algunas APIs de APEX tienen equivalentes POSIX, pero su definición puede diferir de la descrita en POSIX.[8]
Por ejemplo, la siguiente llamada definida en ASAAC:
receiveBuffer
Sería equivalente a la de esta función APEX:
RECEIVE_BUFFER()
Y también sería equivalente en POSIX a:
recv()