МЕНЮ


Фестивали и конкурсы
Семинары
Издания
О МОДНТ
Приглашения
Поздравляем

НАУЧНЫЕ РАБОТЫ


  • Инновационный менеджмент
  • Инвестиции
  • ИГП
  • Земельное право
  • Журналистика
  • Жилищное право
  • Радиоэлектроника
  • Психология
  • Программирование и комп-ры
  • Предпринимательство
  • Право
  • Политология
  • Полиграфия
  • Педагогика
  • Оккультизм и уфология
  • Начертательная геометрия
  • Бухучет управленчучет
  • Биология
  • Бизнес-план
  • Безопасность жизнедеятельности
  • Банковское дело
  • АХД экпред финансы предприятий
  • Аудит
  • Ветеринария
  • Валютные отношения
  • Бухгалтерский учет и аудит
  • Ботаника и сельское хозяйство
  • Биржевое дело
  • Банковское дело
  • Астрономия
  • Архитектура
  • Арбитражный процесс
  • Безопасность жизнедеятельности
  • Административное право
  • Авиация и космонавтика
  • Кулинария
  • Наука и техника
  • Криминология
  • Криминалистика
  • Косметология
  • Коммуникации и связь
  • Кибернетика
  • Исторические личности
  • Информатика
  • Инвестиции
  • по Зоология
  • Журналистика
  • Карта сайта
  • Разработка системы реального времени в виде планировщика исполнения заданий

    этой модели жизненного цикла является наличие обратных связей уже на этапах

    тестирования и верификации. Предполагается, что это позволит создать более

    гибкую в плане предоставляемых возможностей систему.

    Для приложения-протокола выбрана каскадная модель жизненного цикла.

    Она применяется для приложений в хорошо исследованных областях знаний. В

    данном случае системные требования на протокол уже описаны в технической

    документации.

    В данной работе будут выполнены этапы создания системных и

    функциональных требований к планировщику, а также определение его

    архитектуры. Для протокола будет выполнена функциональная модель и модель

    классов.

    2. Планировщик заданий.

    1. Выбор алгоритма планирования.

    1. Виды требований РВ, поддерживаемые планировщиком.

    Во многих системах можно заранее установить множество задач, которые

    будут использоваться, и предположить их характеристики работы в худшем

    случае. При этом можно либо провести фиксированное планирование, которое

    будет удовлетворять требованиям системы, либо определить предварительные

    приоритеты задач.

    Следующие ограничения будет возможно задавать с помощью создаваемого

    планировщика. Они основаны на временном поведении задач.

    1. Абсолютные ограничения.

    . Интервал выполнения.

    Выражает интервал, предоставляемый задаче для выполнения. Задаётся в

    микросекундах или как часть интервала выполнения всех задач. Определяет

    приоритетность определённой задачи на данном этапе вычислений. Может

    динамически изменяться.

    . Время реакции.

    Характеризует время, за которое должен быть получен отклик на внешнее

    воздействие. При превышении данного времени задаче выделяется больше

    ресурсов при помощи приостановки менее приоритетных задач.

    . Время выполнения.

    Выражает время выполнения задач в худшем случае. При превышении

    времени выполнения задача останавливается. В специальный стек

    «неуложившихся в срок» записывается её идентификатор. Для мягких задач

    данный параметр не фиксирован. Этот показатель также важен для

    распределённых (многопроцессорных) систем, где время выполнения задачи

    может зависеть от узла, на котором она выполняется.

    . Периоды.

    Период показывает, как часто задача должна выполняться. Период может

    ограничивать время реакции задачи, поэтому время реакции предполагается

    меньшим периода.

    2. Относительные ограничения.

    Ограничения данного класса также называют локальными. Они выражают то,

    как две задачи связаны друг с другом.

    . Приоритетные ограничения.

    Данные ограничения определяют какие задачи предполагается блокировать

    при угрозе невыполнения срока данной задачи. В первую очередь блокируются

    мягкие задачи.

    . Ограничения расстояния.

    Определяют минимальное расстояние во времени между выполнением двух

    задач.

    . Обновление.

    Этот тип ограничений противоположен предыдущему. Данные ограничения

    влияют на то, в каком порядке должны выполняться задачи. Для

    взаимосвязанных задач можно задать выделение интервала выполнения первой

    перед второй. Эти ограничения также зависят от архитектуры системы, так как

    поведение системы моделируется как последовательность действий.

    Это может быть необходимо в случае, когда одна задача использует

    результаты работы другой, и если между ними пройдёт относительно большой

    промежуток времени, то результаты могут оказаться устаревшими.

    . Гармонические ограничения

    Эти ограничения связаны с периодами двух взаимодействующих задач. Они

    имеют место, например, когда период одной задачи (например, получателя)

    зависит от периода другой (отправителя).

    3. Неподдерживаемые ограничения.

    . Отношения.

    Данные ограничения выражают максимальный интервал времени между

    временами завершения двух задач.

    . Разделительные ограничения.

    Эти ограничения выражают интервал, которому должен принадлежать период

    задачи. Период может быть ограничен минимальным и/или максимальным

    значениями, которые гарантируют, что необходимые действия будут выполнены в

    полученный интервал.

    2. Используемые алгоритмы.

    Выбор того или иного метода планирования зависит от назначения

    системы. В системах контроля, на которые ориентирован планировщик, все

    данные должны быть чётко определены заранее. В этом случае статический

    алгоритм более уместен. Однако, статические методы планирования не являются

    достаточно гибкими, так как для обеспечения корректной работы системы

    заранее необходимо предусмотреть все возможные ситуации.

    Немного более гибким является подход, в котором расписание

    генерируется оперативно. В этом случае для каждой задачи заранее

    определяются: время реакции и время выполнения. В данной разработке будет

    использовано планирование, основанное на времени. Время реакции задаёт

    интервал, в течение которого предполагается ответ системы и после которого

    возникает угроза пропуска срока, требующая выделения дополнительных

    ресурсов для задачи. Время выполнения задаёт интервал, после выхода за

    границы которого задача считается невыполненной и требуется уже

    приостановка выполнения задачи для сохранения стабильности всей системы в

    целом.

    Для динамического перераспределения ресурсов системы будет

    использована политика управления - round-robin. В этом случае процесс

    выполняется либо пока выделенный ему квант времени не истечёт, либо пока не

    будет приостановлен другим процессом с более высоким приоритетом. После

    того, как время, выделенное для данного процесса, истечёт, активируется

    следующий готовый к запуску процесс.

    Когда процесс получает более высокий приоритет и приостанавливает

    выполнение текущего, планировщик сохраняет контекст приостановленного

    процесса для того, чтобы потом продолжить его выполнение с места останова.

    Приостановленный процесс остаётся готовым к запуску.

    Процессы в списке готовых к запуску задач упорядочены, согласно методу

    EDF – в порядке возрастания времени реакции. При наличии блокировки

    запускаются только задачи с приоритетом выше или равным приоритету

    инициировавшей блокировку задачи.

    2. Описание функционирования приложения.

    Схема взаимодействия объектов создаваемой системы показана на

    диаграмме 10.

    1. Подготовка к запуску планировщика.

    Главная программа запускает функцию инициализации планировщика, в

    которую передается массив структур, состоящий из указателей на планируемые

    процедуры и из параметров выполнения. В число параметров входят:

    идентификатор (задается главной программой), приоритет, интервал/квант

    выполнения, время реакции, время выполнения (для мягких задач может не

    определяться), период (для периодических функций), количество запусков или

    время работы (для спорадических задач), порядок, относительно других задач.

    Также возможна передача указателя на входные параметры процедуры.

    В планировщике создается список задач. Создаётся процесс-таймер,

    который будет формировать последовательность сообщений для планировщика.

    2. Работа.

    Главная программа выполняет вызовы функции, отсылающей сообщения о

    начале работы определённой задачи. Планировщик создаёт отдельные процессы

    для каждого задания. Запущенные задачи сами могут вызывать функции

    планирования для себя или других задач.

    Таймер получает от планировщика сообщения и создаёт соответствующие

    метки отсылки сообщений для планировщика. В дальнейшем по достижении метки

    таймер посылает планировщику сообщение инициировать работу определённой

    задачи. Если это метка периодической или спорадической задачи, то таймер

    создаёт через «период» следующую. Планировщик посылает процессам-заданиям

    сигналы начала кванта времени для выполнения.

    При выходе определённой задачи за пределы времени реакции, таймер

    посылает сообщения о блокировании тех задач, у которых приоритет меньше.

    Если выход за пределы у двух одинаково приоритетных одновременно, то они

    продолжат выполняться вместе.

    3. Управление задачами.

    Во многих системах можно заранее установить множество задач, которые

    будут использоваться, и предположить их характеристики работы в худшем

    случае. При этом можно либо провести фиксированное планирование, которое

    будет удовлетворять требованиям системы, либо определить предварительные

    приоритеты задач. Однако неизбежно возникает необходимость изменения

    текущего режима/состояния системы. Можно выделить следующие типы операций

    по изменению режима:

    . Добавление задачи.

    Планировщик принимает сообщение об активации задачи, и помещает в

    число готовых к запуску с учётом абсолютных и относительных ограничений.

    Добавляется запись в процесс-таймер.

    . Изменение интервала выполнения задачи.

    Принимается сообщение об изменении интервала. Если задача, для которой

    он должен быть измен, активна, то она приостанавливается. Интервал

    изменяется. Затем цикл вычислений продолжается, начиная с этой задачи.

    . Изменение периода выполнения периодической задачи.

    Планировщик принимает сообщение и посылает к процессу-таймеру сигнал

    на изменение метки времени, соответствующей данной задаче.

    . Изменение времени реакции, времени выполнения или приоритета.

    Принимается сообщение о необходимости изменения параметра. Если

    задача, для которой он должен быть измен, активна, то она

    приостанавливается. Удаляется соответствующая метка в таймере. Параметр

    изменяется. Устанавливается новая метка в таймере. Если время реакции равно

    0, то блокируются задачи с приоритетом меньшим, чем у данной.

    . Удаление задачи.

    Задача завершает своё выполнение и посылает планировщику сообщение на

    удаление её из списка готовых к выполнению. Или планировщик удаляет задачу,

    вышедшую за пределы выделенного ей времени выполнения.

    3. Реализация протокола ARINC A.415 на основе разработанного модуля СРВ.

    1. Модель требований к системе.

    1. Описательная модель.

    Протокола A.415 ARINC, используется во встроенных системах реального

    времени самолётов ведущих авиаперевозчиков, таких как Airbus, McDonnel

    Douglas и др. Это протокол опроса бортовых устройств, позволяющий в заранее

    обозначенный промежуток времени получить от них информацию и

    сигнализировать о неисправности в оборудовании.

    Бортовые системы самолёта через жёстко заданные промежутки времени

    формируют специальные сообщения, в которых могут сообщать о возникновении

    внутри них неисправностей и описывать их. Специальные подсистемы самолёта

    должны получать сообщения бортовых систем и отправлять отчеты о

    неисправностях на диалоговую систему, предназначенную для взаимодействия с

    оператором в самолёте. Оператор, в свою очередь, должен иметь возможность

    акцентировать своё внимание на одной из контролируемых систем и вступить с

    ней во взаимодействие.

    2. Модель случаев использования.

    Данная модель представлена на рисунке 11.

    У разрабатываемой системы будет 2 вида взаимодействий с «внешним

    окружением»: в Диалоговом режиме и в Обычном режиме. Диалоговый режим

    используется при взаимодействии с оператором в самолёте. Обычный режим

    используется при стандартной работе интерфейсной подсистемы по индикации

    неисправностей.

    3. Функциональная модель.

    Функциональная модель системы представлена в виде диаграмм 12 и 13.

    В Обычном режиме система реализует следующие функции: начало работы

    (инициализация), тёплый старт, получение сообщения от бортовой системы,

    опрос APM (в случае необходимости), отсылка сообщений к CFDIU, переход в

    диалоговый режим.

    В Диалоговом режиме система реализует следующие функции: получение

    сообщения от бортовой системы, отсылка сообщений к CFDIU, получение команд

    от CFDIU, переход в Нормальный режим.

    2. Динамическая модель.

    1. Модель объектов.

    . Сообщение от бортовой системы.

    Бортовая система ? OMSI И Бортовая система ? Энергонезависимая память

    . Получить настройки из APM.

    APM ? OMSI

    . Отправить отчет к CFDIU.

    OMSI ? Шина передачи данных ? CFDIU

    ИЛИ

    General Format Manager

    . Запуск диалогового режима.

    CFDIU ? Шина передачи данных ? OMSI

    . Начало работы.

    Инициализация ИЛИ Тёплый старт

    . General Format Manager.

    Шина передачи данных ? OMSI

    . Получить команду.

    Шина передачи данных ? OMSI

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

    OMSI ? APM

    . Тёплый старт.

    Энергонезависимая память ? OMSI И APM ? OMSI

    . Получить команду от CFDIU.

    CFDIU ? Шина передачи данных ? OMSI

    . Запуск Обычного режима.

    CFDIU ? Шина передачи данных ? OMSI

    2. Модель взаимодействий.

    . Сообщение от бортовой системы.

    OMSI ( начал работу. Бортовая система ( начала работу. Бортовая

    система ( сохранила сообщение о неисправности в Энергонезависимой памяти.

    Бортовая система ( отправила сообщение о неисправности.

    . Получить настройки из APM.

    OMSI ( начал работу. OMSI ( запросил настройки у APM. APM ( передало

    необходимые настройки.

    . Отправить отчет к CFDIU.

    CFDIU ( начал работу. OMSI ( начал работу. Шина передачи данных (

    активна. OMSI ( проверил активность Шины передачи данных. OMSI ( отправил

    отчет. Шина передачи данных ( переправила отчет к CFDIU. CFDIU ( получил

    отчет.

    ИЛИ

    General Format Manager.

    . Запуск диалогового режима.

    CFDIU ( начал работу. OMSI ( начал работу. Шина передачи данных (

    активна. CFDIU ( отправил команду ENQ. Шина передачи данных ( передаёт

    команду на нужный OMSI. OMSI ( переходит в диалоговый режим.

    . Начало работы.

    Инициализация ИЛИ Тёплый старт

    . General Format Manager.

    OMSI ( начал работу. Шина передачи данных ( неактивна. OMSI ( проверил

    активность Шины передачи данных.

    . Получить команду.

    Шина передачи данных ( активна. Шина передачи данных ( передаёт

    команду на OMSI. OMSI ( предпринимает действие в соответствии с командой.

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

    OMSI ( размещение в памяти, инициализация переменных, запрос настроек.

    APM ( поиск и передача необходимых настроек.

    . Тёплый старт.

    OMSI ( размещение в памяти, инициализация переменных, запрос настроек.

    APM ( поиск и передача необходимых настроек. OMSI ( восстановление ранее

    передававшегося сообщения из Энергонезависимой памяти.

    . Получить команду от CFDIU.

    CFDIU ( начал работу. OMSI ( начал работу. Шина передачи данных (

    активна. CFDIU ( отправил команду. Шина передачи данных ( передаёт команду

    на нужный OMSI. OMSI ( предпринимает действие в соответствии с командой.

    . Запуск Обычного режима.

    CFDIU -> начал работу. OMSI -> начал работу. Шина передачи данных ->

    активна. CFDIU -> отправил команду Log Off. Шина передачи данных ->

    передаёт команду на нужный OMSI. OMSI -> переходит в номальный режим.

    3. Поведенческая модель.

    . OMSI.

    Диаграмма 14. Старт ( Проверить Энергозависимую память. ( Выбор: Есть

    ли непереданные сообщения в Энергонезависимой памяти? Да – Инициализация;

    Нет – Тёплый старт. Тёплый старт ( Забрать сообщения из Энергонезависимой

    памяти ( Загрузить настройки из APM. Инициализация ( Загрузить настройки из

    APM ( Работа ( Принять сообщения ( Получить команду ( Сформировать отчет (

    Проверить активность Шины передачи данных ( Выбор: Шина активна? Да –

    Отослать вопрос; Нет – Ждать активизации Шины передачи данных. Отослать

    отчет ( Принять сообщения. Ждать активизации шины ( Отослать отчет.

    . CFDIU.

    Диаграмма 15. Старт ( Включено ( Направить команду (необязательное

    действие) ( Получить отчет ( Отобразить отчет ( Выбор: Окончить работу? Да

    – Выключено; Нет ( Направить команду (необязательное действие).

    . APM.

    Диаграмма 16. Старт ( Получение запроса ( Передать настройки (

    Получение запроса.

    . Шина передачи данных.

    Диаграмма 17. Старт ( Неактивна ( Включение CFDIU => Активна ( Выбор:

    Перенаправление команды; Передача отчета. ( Выбор: Выключение CFDIU =>

    Неактивна; Активна.

    . Бортовая система.

    Диаграмма 18. Старт ( Работает ( Отправка сообщения в

    Энергонезависимую память ( Отправка сообщения к OMSI ( Работает.

    . Энергонезависимая память.

    Диаграмма 19. Старт ( Активна ( Записать сообщение от Бортовой системы

    ( Передать сохраненные сообщения OMSI (необязательное действие)( Уничтожить

    сообщения, не нужные OMSI ( Активна.

    3. Статическая модель.

    1. Модель классов.

    На диаграмме 9 представлены основные классы создаваемой системы: OMSI,

    CFDIU, Шина передачи данных, APM, Энергонезависимая память, Бортовая

    система.

    . OMSI – интерфейсная система, обеспечивающая взаимосвязь функциональной

    системы, (например, T2CAS – системы предупреждения сближения

    самолетов, правильнее «предотвращения столкновения») с центральным

    устройством отображения данных CFDIU.

    . Задача CFDIU предоставлять экипажу самолета данные о функционировании

    всех бортовых систем. С помощью меню экипаж (или техник на земле)

    может вступить во взаимодействие с конкретной функциональной бортовой

    системой (интерактивный режим). В остальных случаях CFDIU просто

    отображает (нормальный режим) состояние бортовых систем, которые через

    свои OMSI сообщают CFDIU свои состояния, посылая сообщения Label350.

    . Процесс взаимодействия OMSI и CFDIU происходит через Шину передачи

    данных. Если шина не активна, то это может означать, что бортовая

    система к CFDIU не подключена, а, следовательно, некому слать

    сообщения.

    . APM - это подсистема (таблица данных с интерфейсом) хранящая настройки

    данного самолета. Бортовая система типа T2CAS может ставиться на

    различные самолеты, и должна подстраиваться к работе конкретного

    борта. В частности, CFDIU не единственный вариант устройства

    отображения данных для экипажа. Могут быть и другие (на разных типах

    самолетов), тогда и протокол обмена реализуется с учетом

    соответствующей центральной системы.

    . После сбоя в электропитании OMSI должен извлечь отчет о неисправности

    из энергонезависимой памяти, которая в данном случае будет

    представлена отдельным объектом создаваемой программной системы.

    . Объект Бортовая система моделирует те сведения, которые должна иметь

    интерфейсная система о функциональной для взаимодействия.

    Заключение.

    Был проведён анализ предметной области систем реального времени.

    Определены основные отличия систем данного типа от других подобных систем и

    особенности управления исполнением задач. Были рассмотрены используемые

    классификации и отличительные особенности современных систем.

    На основе проведенного анализа была спроектирована система, состоящая

    из двух основных подсистем: планировщика заданий реального времени и

    прикладного приложения – авиационного протокола.

    Для обоих подсистем выполнены этапы создания системных и

    функциональных требований, определены используемые алгоритмы и архитектуры.

    Для протокола использована современная методология разработки ПО и

    создана модель классов системы. В целом стоит отметить, что классы в

    проектируемой системе обладают простотой проектирования за счёт отсутствия

    иерархических связей, однако применяемый метод позволяет с относительной

    простотой усложнять структурные связи и расширять область проектирования.

    На основе найденных при проектировании прикладного приложения

    недостатков используемой платформы в дальнейшем могут быть изменены

    функциональные или архитектурные особенности планировщика. Так же

    предполагается использование прикладного приложения для непосредственного

    тестирования планировщика.

    Литература.

    1. С. Кузнецов «Механизмы IPC в операционной системе Unix». учебные

    материалы конференции «Индустрия Программирования 96», Центр

    Информационных Технологий, 1996.

    2. Алексей Быков «Системное администрирование IBM AIX 4.x».

    3. Dr. Jurgen Sauermann, Melanie Thelen «Real-time Operating Systems.

    Concepts and Implementation of Microkernels for Embedded Systems».

    4. See-Mong Tan, David K. Raila, Roy H. Campbell «A case for nano-

    kernels». Department of Computer Science, University of Illinois at

    Urbana-Champaign, 1996, 11 стр.

    5. Michel Gien «Micro-kernel Architecture. Key to Modern Operating

    Systems Design». Chorus systems, 1990, 10 стр.

    6. Booch G. «Object-oriented analysis and design with application, second

    edition». The Benjamin / Cummings Publishing Company, Inc, 1994, 589

    стр.

    7. Романовский К., Ивановский Б., Кознов Дм., Долгов П. «Обзор нотаций

    методологии Real».

    //http://www.tepcom.ru/produkts/real/Report_Notations_A .asp.

    8. ITU «SDL methodology guidelines and bibliography». Appendices i to

    recommendation Z.100, 1993,107 стр.

    9. Selic B., Gullekson G., Ward P.T. «Real-time object-oriented

    modeling». John Wiley & Sons. Inc, 1994, 525 стр.

    10. ITU «Recommendation Z.100: Specification and Description Language

    (SDL)». 1993, 204 стр.

    11. Бардзинь Я.М., Калкиньш А.А., Стродс Ю.Ф., Сыцко В.А. «Язык

    спецификаций SDL/PLUS и его применения». Рига, 1988, 313 стр.

    12. IEEE Standards Project P1003.4a «Thread Extension for Portable

    Operating Systems. Draft 6». Draft 6.-IEEE, 1992.

    13. Алан Джок «ОС реального времени».

    Приложение

    [pic]

    Диаграмма 2. Стандартные прикладные интерфейсы.

    [pic]

    Таблица 3. Время отклика.

    [pic]

    Таблица 4. Сравнение различных операционных систем.

    [pic]

    Рисунок 5. ОС в пространстве "адресация-класс-стандартизация".

    [pic]

    Диаграмма 6. Время реакции различных систем на прерывание

    [pic]

    Диаграмма 7. Время переключения контекста

    |ОСРВ |Разработчик|Область |Web-адрес |Комментарии |

    | | |применения | | |

    |C |JIMI |Коммерческа|www.jmi.com |Система реального |

    |Executiv|Software |я | |времени для |

    |e |Systems | | |программ на Си; |

    | | | | |поддерживает |

    | | | | |процессоры |

    | | | | |архитектур CISC и |

    | | | | |RISC |

    |ITRON |ITRON |Коммерческа|www.itron.gr.jp/home-e.htm|Спецификация |

    | |Committee, |я |l |разработана |

    | |TRON | | |японской |

    | |Association| | |технологической |

    | | | | |ассоциацией; |

    | | | | |ориентирована на |

    | | | | |промышленные |

    | | | | |приложения |

    |LynxOS |LynuxWorks |Коммерческа|www.lynuxworks.com |Совместима с |

    | | |я | |Linux; |

    | | | | |поддерживает Unix |

    | | | | |и Java |

    |OS-9 |Microware |Коммерческа|www.microware.com |Поддерживает |

    | |Systems |я | |микроархитектуру |

    | | | | |Intel XScale; |

    | | | | |модульная |

    | | | | |структура |

    | | | | |стимулирует |

    | | | | |добавление к |

    | | | | |системе новых |

    | | | | |устройств |

    |QNX |QNX |Коммерческа|www.qnx.com |Изолирует |

    | |Software |я | |приложения, |

    | |Systems | | |библиотеки, данные|

    | | | | |и системное |

    | | | | |программное |

    | | | | |обеспечение |

    |VxWorks,|Wind River |Коммерческа|www.windriver.com |Позволяет |

    |VxWorks |Systems |я | |изолировать |

    |AE | | | |совместно |

    | | | | |используемые |

    | | | | |приложения, |

    | | | | |библиотеки, данные|

    | | | | |и системное ПО |

    |Chimera |Университет|Экспери- |www.cs.cmu.edu/afs/ |Поддержка |

    | |Карнеги- |ментальная |cs.cmu.edu/project/ |многозадачности и |

    | |Меллона | |chimera/www/chimera/ |многопроцессорных |

    | | | |chimera.html |систем; |

    | | | | |предназначена для |

    | | | | |роботов и |

    | | | | |автоматизированных|

    | | | | |систем |

    |Maruti |Университет|Экспери- |www.cs.umd.edu/ |Поддерживает |

    | |шт. |ментальная | |режимы "жесткого" |

    | |Мэриленд | | |и "мягкого" |

    | | | | |реального времени |

    Таблица 8. Современные представители систем реального времени.

    [pic]

    Диаграмма 9. Основные классы системы протокола.

    [pic]

    Диаграмма 10. Схема взаимодействия объектов СРВ.

    [pic]

    Рисунок 11. Модель случаев использования.

    [pic]

    Диаграмма 12. Обычный режим.

    [pic]

    Диаграмма 13. Диалоговый режим.

    [pic]

    Диаграмма 14. OMSI.

    [pic]

    Диаграмма 15. CFDIU.

    [pic]

    Диаграмма 16. APM.

    [pic]

    Диаграмма 17. Шина передачи данных.

    [pic]

    Диаграмма 18. Бортовая система.

    [pic]

    Диаграмма 19. Энергозависимая память.

    -----------------------

    Бортовая система

    OMSI

    APM

    Энергонезависимая память

    CFDIU

    Получение настроек

    GeneralFormatManager

    Событие-время

    Планировщик

    Запуск

    ФункцияК

    Таймер

    Запуск/Конец ФункцияК

    Главная програм ма

    Процесс1

    ПроцессN

    Планировать точку

    Функции

    Активные

    процессы

    Диалоговый режим

    Обычный режим

    CFDIU

    OMSI

    Обычный режим

    Получить данные из APM

    Отправить отчет к CFDIU

    Запуск диалогового режима

    Начать работу

    Тёплый старт

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

    General Format Manager

    Диалоговый режим

    Получить команду

    Отправить отчет к CFDIU

    Запуск обычного режима

    Шина активна

    Шина неактивна

    Получить сообщение от бортовой системы

    Сохранение сообщения

    General Format Manager

    Получить команду от CFDIU

    Шина передачи данных

    Получение команды

    Получена

    Передача команды

    Передана

    Получение отчета

    Получен

    Получены

    Получение сохраненного

    Получено

    Неполучено

    Получение сообщения

    Получено

    Получить сообщение от бортовой системы

    Сохранено

    Несохранено

    Старт

    Есть ли непереданные сообщения?

    Нет

    Да

    Забрать сообще-ния из Энергоза-висимой памяти

    Загрузить настройки из APM

    Тёплый старт

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

    Проверить Энергозависимую память

    Принять сообщения

    Получить команду

    Сформировать отчет

    Проверить активность Шины передачи данных

    Шина активна?

    Нет

    Да

    Ждать активизации Шины передачи данных

    Работа

    Отправить отчет

    Включение CFDIU

    Передача отчета

    Выключение CFDIU

    Неактивна

    Нет

    Окончить работу?

    Старт

    Старт

    Получение запроса

    Активна

    Направить команду

    Выключено

    Включено

    Отобразить отчет

    Получить отчет

    Да

    Перенаправление команды

    Передать настройки

    Старт

    Записать сообщение от Бортовой системы

    Отправка сообщения в Энергозависимую память

    Отправка сообщения к OMSI

    Активна

    Передать сохраненные сообщения OMSI

    Работает

    Старт

    Старт

    Уничтожить сообщения, не нужные OMSI

    требования/функции

    архитектура

    код

    тестирование

    верификация

    валидация

    планировщик

    приложение

    системные требования

    функциональные требования

    архитектура

    кодирование

    интеграция

    тестирование/верификация

    Страницы: 1, 2, 3, 4, 5, 6


    Приглашения

    09.12.2013 - 16.12.2013

    Международный конкурс хореографического искусства в рамках Международного фестиваля искусств «РОЖДЕСТВЕНСКАЯ АНДОРРА»

    09.12.2013 - 16.12.2013

    Международный конкурс хорового искусства в АНДОРРЕ «РОЖДЕСТВЕНСКАЯ АНДОРРА»




    Copyright © 2012 г.
    При использовании материалов - ссылка на сайт обязательна.