ARINC 653 Спецификация Годунов А.Н., Солдатов В.А. НИИСИ РАН, Москва

Спецификация
ARINC 653
Годунов А.Н., Солдатов В.А.
НИИСИ РАН, Москва
Основные сведения
• Спецификация ARINC 653 определяет интерфейс (APEX –
APplication EXecutive) прикладного программного
обеспечения с операционной системой (ОС) на основе
концепции, обеспечивающей временное и
пространственное разделение ресурсов.
• Корпорация «Авиационное радио» (Aeronautical Radio,
Incorporated, ARINC) — компания, основанная в 1929 году.
Штаб-квартира в Аннаполисе (штат Мэрилэнд, США).
• Первая версия ARINC 653 вышла в октябре 1996 года. В
дальнейшем было опубликовано несколько дополнений,
последние из которых датируются декабрём 2014 года.
Состав
• Part 0 – Overview of ARINC 653 - общий обзор всех документов
спецификации.
• Part 1 – Required Services - описывает основные (обязательные)
требования
• Part 2 – Extended Services - дополнительные возможности.
• Part 3 – Conformity Test Specification For ARINC 653 Required
Services - тесты для проверки соответствия интерфейса
спецификации ARINC 653.
• Part 4 – Subset Services - подмножество интерфейсов.
• Part 5 – Core Software Recommended Capabilities рекомендации по организации ядра ОС.
Особенности
• Держателем ресурсов является раздел (partition), в рамках
которого возможно параллельное выполнение нескольких
процессов (process).
• Требуемые ресурсы и взаимосвязи между отдельными
частями системы определяются системным интегратором
при конфигурировании системы.
• Ресурсы выделяются только на этапе инициализации
раздела.
• Каждый раздел может находиться в одном из состояний
(DORMANT, WAITING, READY, RUNNING). Создание объектов
ОС возможно только при инициализации раздела
• Ошибки, в зависимости от их уровня и этапа выполнения
раздела, могут обрабатываться либо средствами ОС, либо
прикладной программой (с помощью процесса Error
Handler).
• Небольшое количество интерфейсных функций
• Для всех объектов ОС определено имя объекта,
идентификатор объекта и однотипный интерфейс функций.
Основные возможности
(Required Services)
•
•
•
•
•
•
Управление разделами (partition)
Управление процессами (process)
Управление временем
Управление памятью
Взаимодействие разделов (sampling и queuing порты)
Взаимодействие процессов (buffers, blackboards,
semaphores, events)
• Обработка ошибок (Health Monitor).
Управление разделами (partition)
• Разделы и выделяемые им ресурсы определяются системным
интегратором при конфигурировании системы.
• Загрузка и создание разделов возможны только на этапе
инициализации модуля, далее создание разделов невозможно,
но возможен рестарт.
• Спецификация ARINC 653 предусматривает как
пользовательские, так и системные процессы. Интерфейс
пользовательских процессов должен соответствовать ARINC
653. Интерфейс пользовательских процессов не определен.
• Каждый раздел может находиться в одном из четырёх режимов
(состояний): COLD_START, WARM_START, NORMAL, IDLE.
• В рабочий режим раздел переводится прикладной программой
в случае успешного завершения этапа инициализации.
• Для смены состояния раздела предназначена функция
SET_PARTITION_MODE().
Планирование разделов
• Планирование в ARINC 653 двухуровневое:
- планирование разделов;
- планирование процессов.
• Планирование разделов периодическое и определяется
расписанием. В расписании определяется длительность
основного периода (major frame), который разбивается на
непересекающиеся временные интервалы (окна).
• После завершения основного периода он повторяется снова до
окончания работы системы или до смены расписания.
• Для каждого окна назначается раздел, который может
выполняться в этом окне.
• Возможно использование разных расписаний на разных этапах
работы (дополнительная возможность)
• Все расписания определяются системным интегратором при
конфигурировании системы.
Функции управления
расписаниями
SET_MODULE_SCHEDULE() - установка расписания окон,
GET_MODULE_SCHEDULE_STATUS() - опрос идентификатора расписания окон
по имени,
GET_MODULE_SCHEDULE_ID() - опрос расписания.
Пример расписания
Основной период 10 мс (100 гц)
7 мс
5 мс
2 мс
Раздел A
2 мс
(200 гц)
Раздел B (100 гц)
3 мс
Раздел А (200 гц)
Раздел C (100 гц)
2 мс
3 мс
Управление процессами
(process)
• Для организации (псевдо) параллельных вычислений внутри
раздела используются процессы.
• Каждый процесс должен быть создан на этапе инициализации
раздела, когда планирование запрещено.
• Процесс может находиться в одном из состояний DORMANT,
WAITING, READY, RUNNING .
• После создания процесс находится в неактивном состоянии
(DORMANT) до тех пор, пока он не будет запущен функцией
START() или DELAYED_START().
• Уничтожить процесс невозможно, но можно его перевести в
неактивное состояние (DORMANT) функцией STOP() или
STOP_SELF().
• Процессы делятся на периодические и непериодические.
Функции управления
процессами
CREATE_PROCESS() – создание процесса;
START(), DELAYED_START() - запуск процесса на выполнение.
STOP(), STOP_SELF() - останов выполнения процесса.
SET_PRIORITY() - установка приоритета процесса;
LOCK_PREEMPTION() - запрещение переключения процессов.
UNLOCK_PREEMPTION() - разрешение переключения процессов.
SUSPEND_SELF(), SUSPEND() - приостановка процесса;
RESUME() - возобновление выполнения приостановленного процесса.
GET_PROCESS_ID(), GET_MY_ID() - опрос идентификатора процесса;
GET_PROCESS_STATUS() - опрос статуса процесса.
Служба времени
• Все процессы используют одни и те же часы, которые
отсчитывают время от пуска системы.
• Время измеряется в наносекундах и имеет тип
SYSTEM_TIME_TYPE (64-разрядное целое со знаком).
• Для задания интервалов времени можно использовать
значение INFINITE_TIME_VALUE (неограниченное время)
• Функции службы времени:
TIMED_WAIT() - временная приостановка процесса.
GET_TIME - опрос текущего системного времени.
PERIODIC_WAIT() - ожидание начала следующего периода.
REPLENISH() - изменение лимита времени выполнения процесса.
Периодические процессы
• При создании периодического процесса следует указать
период процесса и лимит времени. Лимит времени
ограничивает время работы процесса с начала периода.
• Периодические процессы используют следующие функции:
PERIODIC_WAIT() – ожидание начала следующего периода;
REPLENISH() – изменение лимита времени (deadline) потока.
• Текст главной функции периодического процесса:
void main_cycle() {
RETURN_CODE_TYPE ErrorCode; // код возврата
while(1) {
((ErrorCode = period_func(…)) != NO_ERROR) break ;
PERIODIC_WAIT(&ErrorCode) ;
if (ErrorCode != NO_ERROR) break;
}
. . .
}
Планирование процессов
• Процессы конкурируют за использование процессора только с
процессами одного и того же раздела.
• Выполняться могут только процессы в состоянии READY или
RUNNING
• Планирование процессов производится на основании
приоритетов процессов. Приоритеты процессов могут быть
динамически изменены.
• Планирование аналогично SCHED_FIFO в POSIX (SCHED_RR
отсутствует). Аналогом функции sched_yield() является
функция TIMED_WAIT().
• Планирование процессов текущего раздела может быть
запрещено (а затем разрешено) прикладной программой.
• Процесс может быть временно или постоянно приостановлен.
Взаимодействие разделов I
• ARINC 653 предусматривает только один способ взаимодействия
разделов - путем передачи сообщений через каналы. Каналы
могут использоваться для передачи сообщений:
– между процессами, выполняемыми на одном и том же
процессорном модуле;
– между процессами, выполняемыми на разных процессорных
модулях;
– между процессами и внешними устройствами.
• Такие ограничения на способы взаимодействия ARINCпроцессов делает их слабо взаимосвязанными и облегчает
восстановление (restart) процессов при сбоях.
• Интерфейс взаимодействия прикладных программ с каналами
не зависит от способа передачи данных по каналам.
Независимость интерфейса от способа передачи данных
повышает мобильность прикладных программ и удобна при
отладке.
Взаимодействие разделов II
• Каналы могут работать в двух режимах: с очередью
сообщений (QUEUING) и без очереди сообщений
(SAMPLING).
• У каждого канала один порт, передающий сообщения и
один или несколько портов, принимающих сообщения.
• У канала, работающего в режиме с очередью сообщений
может быть только один порт приёма сообщений.
• Создание портов и каналов производится при
инициализации.
• Каналы и порты описываются при конфигурировании
системы и их параметры нельзя изменить во время работы
системы.
Функции управления портами
Queuing порты
CREATE_QUEUING_PORT() - создание порта с очередью сообщений;
GET_QUEUING_PORT_ID() - опрос идентификатора порта с очередью;
GET_QUEUING_PORT_STATUS() - опрос состояния порта с очередью;
SEND_QUEUING_MESSAGE() - отправка сообщения в порт с очередью;
RECEIVE_QUEUING_MESSAGE() - получение сообщения из порта с очередью;
CLEAR_QUEUING_PORT() - сброс порта с очередью сообщений.
Sampling порты
CREATE_SAMPLING_PORT() - создание порта без очереди сообщений;
GET_SAMPLING_PORT_ID() - опрос идентификатора порта без очереди;
GET_SAMPLING_PORT_STATUS() - опрос состояния порта без очереди;
WRITE_SAMPLING_MESSAGE() - вывод сообщения в порт без очереди;
READ_SAMPLING_MESSAGE() - ввод сообщения из порта без очереди.
Взаимодействие процессов
• Семафоры (semaphores),
• События (events),
• Буфера (buffers),
• Доски объявлений (blackboards).
Различия между
ARINC и POSIX семафорами
• ARINC и POSIX используют разный интерфейс для работы с
семафорами.
• ARINC позволяет реализовать как целочисленные, так и
двоичные семафоры.
• В ARINC дисциплина обслуживания очереди к семафору
определяется пользователем (приоритетная или FIFO).
• Созданные в рамках одного раздела ARINC-семафоры могут
использоваться только процессами данного процесса и не
влияют на выполнение потоков других процессов.
• Каждый ARINC-семафор имеет имя, уникальное в пределах
данного процесса.
Интерфейс семафоров
• В ARINC предусмотрены следующие функции для управления
семафорами :
CREATE_SEMAPHORE() – создание семафора;
GET_SEMAPHORE_ID() – опрос идентификатора семафора;
GET_SEMAPHORE_STATUS() – опрос состояния семафора;
SIGNAL_SEMAPHORE() – останов выполнения процесса;
WAIT_SEMAPHORE() – захват семафора.
• Функция WAIT_SEMAPHORE() спецификации ARINC
обеспечивает ту же функциональность, что и три функции
POSIX: sem_wait(), sem_try_wait() и sem timedwait().
Обработка ошибок I
• Диагностика ошибок производится аппаратурой, ОС и
прикладной программой (RAISE_APPLICATION_ERROR()).
Обработка ошибок производится операционной системой и
прикладной программой.
• Реакция на ошибки определяется интегратором при
конфигурировании системы.
• Уровень ошибки определяется интегратором при
конфигурировании системы. Ошибки бывают уровня модуля
(MODULE), раздела (PARTITION), процесса (PROCESS).
• Ошибки уровня модуля и раздела обрабатываются ОС.
• Возможная реакция на ошибки уровня модуля: останов
модуля, рестарт модуля, игнорирование ошибки.
• Возможная реакция на ошибки уровня раздела: останов
раздела, рестарт раздела, игнорирование ошибки.
Обработка ошибок II
• Обработка ошибок уровня процесса определяется прикладным
программистом с помощью специального процесса обработки
ошибок (error handler).
• Процесс обработки ошибок создается с помощью функции
CREATE_ERROR_HANDLER() при инициализации раздела.
• Процесс обработки ошибок может остановить, а также
остановить и вновь запустить ошибочный процесс с помощью
функций STOP() и START(), а также повторно запустить или
остановить раздел с помощью функции SET_PARTITION_MODE().
• Для вывода сообщений об ошибке процесс обработки ошибок
может использовать функцию REPORT_APPLICATION_MESSAGE(),
а для получения сведений об ошибке – функцию
GET_ERROR_STATUS().
• Ошибки при работе процесса обработки ошибок трактуются как
ошибка уровня раздела.
Дополнительные возможности
(Extended Services)
• Функции работы с файлами (File System)
• Структуры данных Sampling портов
• Управление планированием разделов (использование
нескольких расписаний)
• Книги записей (Logbook)
• Дополнительные возможности sampling портов
• SAP-порты (Service Access Points)
• Управление именами (Name Service)
• Блоки памяти (Memory Blocks)
• Дополнительные возможности при обработке ошибок
(Health Monitor Extensions)
• Списки портов (Queuing Port List Service)
Доступ к файловым системам
• Средства доступа к файловым системам спецификации ARINC
аналогичны тем, которые предоставляет стандарт POSIX, но
при этом используется другой интерфейс.
• Запоминающие устройства для хранения данных должны
быть описаны при конфигурировании модуля.
• Имена нечувствительны к регистру, полное имя файла
содержит имя тома.
• Для каждого тома только один раздел имеет право на чтение
и запись, право на чтение могут иметь несколько разделов.
• Каждая функция имеет два аргумента для идентификации
ошибки: код возврата идентифицирует ошибку по
спецификации ARINC, в аргумент ERRNO записывается код
совпадающий со стандартом POSIX для аналогичной
функции.
Книги записей (logbook)
• Книги записей предназначены для хранения сообщений
(записей) между сеансами работы (при выключении питания)
во флэш-памяти.
• Одновременно можно использовать несколько книг записей,
но каждая книга записей может использоваться только одним
разделом.
• Используемые книги записей должны быть описаны при
конфигурировании системы.
• При создании книги записей область флэш-памяти связывается
с создаваемым объектом и все сообщения, ранее записанные
в эту область, становятся доступными для чтения.
• Функции записи WRITE_LOGBOOK() и OVERWRITE_LOGBOOK()
помещают выводимое сообщение в буфер. Копирование
сообщений из буфера во флэш-память производится не сразу, а
по мере возможности.
SAP-порты (Service Access Point)
• SAP-порты являются разновидностью портов с очередью
сообщений.
• В функции отправки сообщения может быть указан адрес
получателя; в функции получения сообщения получен адрес
отправителя.
• Дополнительная функция отправки позволяет указать адрес
источника сообщения, а дополнительная функция приема
сообщения позволяет получить адрес получателя.
• Основные функции для работы с SAP-портами:
CREATE_SAP_PORT(), GET_SAP_PORT_ID (), GET_SAP_PORT_STATUS() ,
SEND_SAP_MESSAGE (), RECEIVE_SAP_MESSAGE ()
• Дополнительные функции:
SEND_EXTENDED_SAP_MESSAGE (), RECEIVE_EXTENDED_SAP_MESSAGE()
Списки портов (queuing port list)
• Списки портов позволяют получать сообщения, прибывающие
по нескольким каналам в контексте одного процесса, без
постоянного опроса портов.
• Списки портов могут содержать только порты с очередью
сообщений, предназначенные для получения сообщений.
• Создание списка портов, а также добавление портов в список
возможно только на стадии инициализации раздела.
• Изменение уровня активности порта в списке возможно как на
стадии инициализации, так и в нормальном режиме работы.
• Функции для работы со списками портов:
CREATE_QUEUING_PORT_LIST(), ADD_PORT_TO_QUEUING_PORT_LIST(),
SET_PORT_ACTION_IN_QUEUING_PORT_LIST(),
GET_QUEUING_PORT_ACTION_STATUS(),
RECEIVE_MESSAGE_FROM_QUEUING_PORT_LIST(),
WAIT_FOR_MESSAGE_FROM_QUEUING_PORT_LIST()
Блоки памяти
• Блоки памяти создаются при инициализации модуля и
позволяют осуществлять доступ к ним из различных разделов.
• Блок памяти идентифицируется своим именем.
• Прова доступа из раздела к блоку памяти определяется при
конфигурации (доступ запрещён; разрешён на чтение;
разрешён на чтение и запись).
• Имеется единственная функция для работы с блоком памяти
GET_MEMORY_BLOCK_STATUS(), которая позволяет по имени блока
определить адрес и длину блока памяти, а также права
доступа.
Конфигурирование I
• Спецификация ARINC 653 требует составления конфигурации
системы. Конфигурирование производится интегратором (не
прикладным программистом).
• Описание конфигурации представляет собой документ на
языку XML.
• Последние версии ARINC 653 не определяют полную схему
XML-документа (как это было в первых версиях), а
определяют лишь отдельные ее элементы.
• Первая часть спецификации (Required Services ) описывает
элементы, относящиеся к конфигурированию:
- процессов;
- расписаний;
- обработки ошибок (Health Monitor).
Конфигурирование II
• Вторая часть спецификации (Required Services ) описывает
элементы, относящиеся к конфигурированию:
- расписаний;
- SAP-портов;
- томов (например, дисков) ;
- книг записей (logbook) ;
- блоков памяти.
Тесты проверки соответствия
(Conformity Test Specification)
• Дано описание тестов, предназначенных для
демонстрации соответствия ОС требованиям
спецификации.
• Даны указания по разработке тестов
• Даны рекомендации по организации процесса
тестирования.
• Документ охватывает только функции, описанные в
первой части спецификации (Required Services ).
Подмножество интерфейсов
(Subset Services )
• В четвёртой части спецификации определены функции,
которые можно использовать в рамках подмножества
интерфейсов, а также описаны особенности их реализации.
Одной из целей разработки подмножества было создание
более простых и надежных систем.
• В одном разделе может выполняться не более двух
процессов: один периодический и/или один
непериодический процесс.
• Приоритеты процессам не назначаются, периодический
процесс всегда более приоритетный, чем непериодический
процесс.
• В подмножестве отсутствуют средства взаимодействия
процессов внутри одного раздела (семафоры, события,
очереди сообщений и доски объявлений).
Операционные системы,
соответствующие спецификации
ARINC 653
• VxWORKS AE653 (Wind River),
• LynxOS-178 2.0 (LynuxWorks, Inc.),
• INTEGRITY-178B (Green Hills Software Inc.).
• ОС РВ Багет 3.х
СПАСИБО
THANK YOU
MERCI
DANKE
GRACIAS
GRAZIE
Список литературы I
1. IEEE Standard for Information Technology - Portable Operating System
Interface (POSIX) - Part 2: System Interface. - IEEE Std 1003.1-2004, vol. 2.
2. Avionics application software standard interface, Part 1 - Required services,
Aeronautical radio, Inc, March, 2007.
3. Годунов А.Н., Операционные системы реального времени Багет 3.0.
Программные продукты и системы, 2010 г., № 4. С. 15-19.
4. Безруков В.Л., Годунов А.Н., Назаров П.Е., Солдатов В.А., Хоменков И.И.
Введение в oc2000// Вопросы кибернетики / под ред. В.Б. Бетелина. –
М.: НИИСИ РАН, 1999. C.76-106.
5. Годунов А.Н., Солдатов В.А., Операционные системы семейства Багет
(сходство, отличия и перспективы). Программирование, 2014 г., № 5. С.
69-76
6. Герлиц Е.А., Кулямин В.В., Максимов А.В., Петренко А.К.,Хорошилов А.В.,
Цыварев А.В. Тестирование операционных систем//Труды Института
системного программирования РАН, том 26, 2014 г. Выпуск 1. С. 73-108.
Список литературы II
7. Wind river platform for safety critical ARINC 653//
http://www.windriver.com/products/platforms/safety_critical_arinc_653/res
ources/platform_sc_arinc653_ds.pdf
8. LynxOS-178 2.0// http://www.lynuxworks.com/rtos/lynxos-178.pdf
9. Safety Critical Products: INTEGRITY-178B RTOS//
http://www.ghs.com/download/datasheets/INT_178B.pdf
10. Tanenbaum A.S.; Herder J.N.; Bos H., Can we make operating systems reliable
and secure?// Computer, Volume 39, Issue 5, May 2006. P. 44 – 51.
Конфигурирование 1
• В спецификации ARINC 653 на языке XML-схема определяются
структуры и типы данных, необходимые для конфигурирования
любой системы, реализующей эту спецификацию.
• Модуль: имя; разделы; расписание; обработка ошибок.
• Раздел: имя; идентификатор; периодичность и длительность
выполнения; области памяти раздела; порты.
• Память: имя; тип (Ram, Flash, Input/output); размер; права
доступа; физический адрес; атрибут «кэш».
• Порт: имя; тип (QueingPort или SamplingPort); максимальный
размер сообщения; направление передачи сообщений в порте
(source или destination); для порта с очередью сообщений максимальное количество сообщений в очереди.
Конфигурирование 2
• Расписание: окна.
• Окно: ссылка на имя раздела; длительность окна; смещение
относительно начала основного периода; для периодического
процесса, точка старта этого процесса.
• Обработка ошибок: ошибки системы; ошибки модуля; ошибки
разделов; ошибки раздела.
• Ошибка системы: идентификатор; описание.
• Ошибка модуля: идентификатор этапа; описание этапа;
реакции на ошибку.
• Реакция на ошибку: идентификатор ошибки; действие.
• Ошибка разделов: имя раздела; реакции на ошибку.
• Ошибка раздела: идентификатор; имя; реакции на ошибку.