ЖУРНАЛ СТА 3/2011

ARINC 659 для обмена данными меж- ду модулями. Расписание обмена дан- ными подчинено расписанию выпол- нения вычислительных задач, которое строится в первую очередь. Алгоритм построения статического расписания обмена данными, описанный в [4], требует допустимости прерывания пе- редачи сообщений (в то время как для каналов с централизованным управле- нием прерывание выполнения работ обычно недопустимо). Кроме того, этот алгоритм предполагает возмож- ность начать передачу сообщения в любой момент времени (тем самым никакие сложные ограничения на корректность расписания не поддер- живаются). Важной особенностью рассматриваемой в [4] инструменталь- ной системы является возможность расширения подсистемы планирова- ния посредством программных моду- лей, однако в статье не показано, что таким образом можно преодолеть фундаментальные ограничения алго- ритма. Инструментальная система [5] пред- назначена для статического планиро- вания выполнения вычислительных задач. В данной системе ограничения на корректность расписания задают в процедурном виде. Существенными недостатками данной системы являют- ся требование возможности прерыва- ния задач и поддержка лишь ограниче- ний на временные интервалы выпол- нения задач, при том что такие огра- ничения, как «не более одной цепочки работ в каждом подцикле», не относят- ся к этому виду ограничений. Коммерческие программные ин- струменты проектирования систем ре- ального времени, такие как RapidRMA [6] и TimeWiz [7], специализируются на анализе возможности динамиче- ского построения расписаний в ВСРВ и основываются на теории частотно- монотонного планирования [8], кото- рая не учитывает введённые техноло- гические ограничения на коррект- ность расписания. В табл. 1 приведены сводные ре- зультаты оценки применимости ин- струментальных систем [4–7] для ста- тического построения расписания обмена с учётом описанных техноло- гических ограничений на коррект- ность расписания. Ни одна из этих систем «как есть» не подходит для ре- шения данной задачи, причём общим недостатком систем является отсут- ствие поддержки циклической схемы обмена и технологических ограниче- ний на расписание. Исходные коды рассмотренных инструментальных систем недоступны, а механизмы рас- ширения программными модулями (в случае наличия таковых) не могут устранить базовые ограничения этих систем. Т ЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС ПОСТРОЕНИЯ РАСПИСАНИЯ ОБМЕНА ДАННЫМИ Схема процесса Предлагаемый технологический процесс построения расписания об- мена данными предполагает следую- щую последовательность действий/ шагов: 1)создание проекта – наполне- ние базы данных информа- цией о структуре бортовой сети и характеристиках рабо- чей нагрузки на каналы пе- редачи данных; 2)автоматическое построение расписания обмена данны- ми, являющегося полным (включающим все работы) и корректным (удовлетворя- ющим всем ограничениям на корректность расписания): 3)при необходимости – ручная корректировка расписания; 4)в случае если нельзя по- строить полное и корректное расписание – автоматиче- ская корректировка техноло- гических ограничений таким образом, чтобы построение расписания с обновлёнными требо- ваниями было возможным; 5)генерация программного кода, зада- ющего расписание для устройств, присоединённых к каналу; 6)генерация отчётов о входных данных (заданных на шаге 1) и построенных расписаниях для включения в доку- ментацию бортовой ВСРВ. На рис. 3 показана диаграмма тех- нологического процесса построения расписания обмена данными по от- дельному каналу с централизованным управлением. Категориям данных со- ответствуют прямоугольники (с пре- рывистой границей – для входных данных, со сплошной – для выход- ных). Действиям соответствуют пря- моугольники со скруглёнными углами и курсивной подписью. Шаг 1 техно- логического процесса на диаграмме не отражён. Требования к инструментальной поддержке процесса Для поддержки описанного техноло- гического процесса инструментальная система построения расписания обме- на данными должна: ● поддерживать выполнение всех ша- гов процесса; ● иметь модульную структуру, соответ- ствующую шагам технологического процесса; ● обеспечивать хранение исходных данных и результатов каждого шага в базе данных; ● предоставлять графический интер- фейс для взаимодействия с пользова- телем. 80 СТА 3/2011 П РОГ Р АММНОЕ ОБ Е СП Е Ч Е НИЕ / ИНС Т Р УМЕ Н Т АЛ Ь НЫЕ СИС Т ЕМЫ www.cta.ru КРИТЕРИЙ ИНСТРУМЕНТАЛЬНАЯ СИСТЕМА (ИС) ИС [4] ИС [5] RAPIDRMA TIMEWIZ Поддержка построения статических расписаний + + – – Поддержка построения расписаний без прерывания работ – – + + Поддержка циклической схемы обмена – – – – Поддержка технологических ограничений на цепочки работ – – – – Поддержка технологических ограничений на резервы време- ни в расписании – + – – Таблица 1 Применимость инструментальных систем для построения расписания обмена с учётом технологических ограничений Рис. 3. Планирование обмена данными для отдельного канала Набор сообщений Код, задающий расписание Расписание Отчёты Построение расписания Корректировка ограничений Генерация отчётов Генерация кода Технологические ограничения © СТА-ПРЕСС