АРИНК 653

ARINC 653 (Стандартный интерфейс прикладного программного обеспечения авионики) — это спецификация программного обеспечения для разделения пространства и времени в критически важных для безопасности авионики операционных системах реального времени (RTOS). Это позволяет размещать несколько приложений с разными уровнями программного обеспечения на одном и том же оборудовании в контексте архитектуры интегрированной модульной авионики .

Он является частью стандартов ARINC 600-й серии для цифровых самолетов и авиасимуляторов.

Обзор

Чтобы отделить платформу операционной системы реального времени от прикладного программного обеспечения, ARINC 653 определяет API , называемый APplication EXecutive (APEX).

Каждое прикладное программное обеспечение называется разделом и имеет собственное пространство памяти. Он также имеет выделенный временной интервал, выделенный API APEX. Внутри каждого разрешена раздела . многозадачность API APEX предоставляет услуги для управления разделами, процессами и синхронизацией, а также взаимодействия между разделами и процессами и обработки ошибок. Среду разделения можно реализовать с помощью гипервизора. сопоставить разделы с виртуальными машинами, но это не обязательно.

Стандарт контролируется подкомитетом AEEC APEX [1] .

История

Начальная версия

Первоначальная версия ARINC 653 была опубликована 10 октября 1996 года.

АРИНК 653-1

Приложение 1 было опубликовано в январе 1997 года и представило концепции APEX и разделения времени и пространства.

АРИНК 653-2

Приложение 2 было опубликовано в трех частях в период с марта 2006 г. по январь 2007 г.:

• Часть 1 (обязательные услуги): управление разделами ARINC 653, определение холодного и горячего запуска, обработка ошибок прикладного программного обеспечения, соответствие ARINC 653, Ada и C ; привязка языков
• Часть 2 (дополнительные услуги): доступ к файловой системе , регистрация данных , точки доступа к службам, ...
• Часть 3 (Спецификация испытаний на соответствие);

Текущая организация стандартизации

• Часть 0. Введение в ARINC 653 (в настоящее время это версия 3, выпущенная в ноябре 2021 г.)

• Часть 1. Необходимые услуги (в настоящее время — версия 5, выпущенная в декабре 2019 г.)
• Часть 2. Расширенные услуги (в настоящее время — версия 4, выпущенная в декабре 2019 г.)
• Часть 3A. Спецификация испытаний на соответствие необходимых услуг (в настоящее время — редакция 2, выпущенная в ноябре 2021 г.)
• Часть 3B. Спецификация испытаний на соответствие для расширенных услуг (в настоящее время редакция c1, выпущенная в июле 2019 г.)
• Часть 4. Подмножество служб (в настоящее время версия 0, выпущена в июне 2012 г.)
• Часть 5. Рекомендуемые возможности основного программного обеспечения (в настоящее время — версия 1, выпущенная в августе 2019 г.)

Основные принципы разделения

Платформа АРИНК 653

ARINC 653 Платформа содержит:

• Аппаратная платформа, позволяющая выполнять детерминированные услуги в реальном времени .
• Уровень абстракции , управляющий ограничениями таймера и разделения пространства платформы ( память , ЦП , ввод/вывод ).
• Реализация сервисов ARINC 653 (APEX API).
• Интерфейс, позволяющий настроить платформу и область ее использования.
• Различные инструментальные средства.

Инициализация

Инициализация раздела ARINC 653 создает ресурсы, используемые этим разделом. Создание ресурсов (PROCESS, EVENT, SEMAPHORE...) выполняется путем вызова службы API с именем CREATE_xxxx .

Обработка ошибок

Обработчик ошибок процесса — это упреждающий процесс с наивысшим приоритетом, предназначенный для обработки исключений раздела. Он создается службой CREATE_ERROR_HANDLER во время инициализации раздела.

API позволяет обработчику ошибок остановить неисправный процесс ( STOP_SELF ). В этом случае планировщик RTOS вызовет следующий процесс с наивысшим приоритетом.

ARINC 653 не определяет, как должен вести себя планировщик, если обработчик ошибок не останавливает сбойный процесс. В некоторых (теоретических) случаях это может привести к бесконечному циклу между неисправным процессом и обработчиком ошибок.

Обработчик ошибок может получить информацию об источнике и контексте исключения.

Управление режимами

Каждый раздел может находиться в нескольких режимах активации:

• COLD_START и WARM_START: выполняется только процесс инициализации,
• НОРМАЛЬНЫЙ: процесс инициализации остановлен, а остальные процессы раздела вызываются планировщиком RTOS в зависимости от их приоритета.
• IDLE: ни один процесс не выполняется. Однако теоретически реализация все же может выполнить скрытый процесс с самым низким приоритетом, например, чтобы запустить бесконечный цикл.

Сервис SET_PARTITION_MODE позволяет управлять этими состояниями. Его может вызвать любой процесс в разделе. Переход в состояние IDLE необратим для раздела. Только внешнее событие (например, перезапуск платформы) может изменить состояние на другой режим, когда раздел находится в этом состоянии.

Планирование разделов и процессов

Стандарт определяет двухуровневый иерархический график. Первый уровень планирует разделы. Это циклический фиксированный график, повторяющий основной временной интервал. Основной временной интервал распределяет каждый раздел по второстепенному временному интервалу фиксированной продолжительности с фиксированным смещением от начала основного временного интервала.

Расписание разделов ARINC 653

В рамках Малого Временного интервала второй уровень использует планирование процессов. В каждом разделе есть хотя бы один процесс . Планирование процесса в пределах Малого Временного интервала является упреждающим . Планировщик вызывается либо таймером, либо службами API.

Многоядерный

ARINC 653 P1-5 был обновлен для поддержки многоядерных процессорных архитектур. В разделе 4.2.1 «Соответствие многоядерной реализации ОС» указано, что ОС, предназначенная для многоядерной обработки, должна поддерживать два случая:

• Использование нескольких ядер одним разделом (процессы которого охватывают несколько ядер)
• Использование нескольких ядер несколькими разделами

В документе с изложением позиции CAST-32A определяется набор требований и указаний, которые должны быть выполнены для сертификации и использования многоядерных процессоров в гражданской авиации ФАУ, и ожидается, что он будет заменен консультативным циркуляром AC 20-193. Авиационное управление Европейского союза EASA опубликовало AMC 20-193 в январе 2022 года.

API-сервисы

Службы ARINC 653 APEX — это API, вызовы относящиеся к шести категориям:

• Управление разделами
• Управление процессами
• Тайм-менеджмент
• Межраздельная связь
• Внутрираздельная связь
• Обработка ошибок

не предусмотрены службы ARINC 653 Для управления памятью разделов . Каждый раздел должен обрабатывать свою собственную память (все еще в рамках ограничений разделения памяти, налагаемых ARINC 653).

Каждая служба возвращает значение RETURN_CODE, которое указывает, был ли вызов успешным:

• NO_ERROR: услуга выполняется номинально после действительного запроса.
• NO_ACTION: состояние системы не изменилось после выполнения службы
• NOT_AVAILABLE: услуга временно недоступна.
• INVALID_PARAM: хотя бы один из параметров службы недействителен.
• INVALID_CONFIG: хотя бы один из параметров сервиса несовместим с текущей конфигурацией системы.
• INVALID_MODE: сервис несовместим с текущим режимом системы
• TIMED_OUT: задержка выполнения услуги истекла

Ссылки на POSIX и ASAAC

Поле, охватываемое ARINC 653, аналогично ASAAC Def Stan 00-74 . Однако между этими двумя стандартами существуют различия.

Некоторые вызовы ARINC 653 (APEX) имеют эквивалент POSIX , но отличаются от того, как они определены в POSIX.

Например, следующий вызов, определенный в ASAAC:

 receiveBuffer

будет переведен в ARINC 653 следующим образом:

 RECEIVE_BUFFER()

а также в POSIX:

 recv()

См. также

• Интегрированная модульная авионика
• АСАК
• АРИНК
• ДО-178Б