Программное Обеспечение Систем Реального Времени Тема лекции Операционное

Программное Обеспечение Систем Реального Времени Тема лекции: Операционное обеспечение СРВ БГТУ. Кафедра И 3. Асс. Куликов Д. Б.

Содержание лекции Система реального времени Функциональность Архитектура ОС. Способы повышения надежности. Требования к ОС РВ. Стандарты Характеристики Пример ОС

Система реального времени Система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в которое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы. При этом в системе должны существовать средства проверки соблюдения временных ограничений и, кроме того, заранее не очевидно, как эти временные ограничения соблюсти. Аппаратно-программный комплекс, реагирующий в предсказуемые времена на случайный поток внешних событий. Стандарт POSIX 1003. 1 : «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»

Основное назначение ОС Распределение ресурсов ВУ для множества задач.

Области применения Системы управления технологическими процессами (например, управление реакторами на атомных электростанциях, переработка различных материалов/сырья и т. п. ) Системы медицинского мониторинга и жизнеобеспечения Военные системы (системы наведения, разведки и пр. ) Робототехника (например, конвейерная сборочная линия) Подсистемы транспортных средств (антиблокировка тормозов, управление зажиганием, автопилоты на самолетах) Системы сбора данных в научных исследованиях Системы охранной сигнализации (аварийные системы) Системы управления промышленной безопасности Телекоммуникационные системы

Функциональность ОС Управление потоками/процессами Управление памятью (MMU) Управление таймерами Взаимодействие между задачами и синхронизация. Управление ресурсами Файловая система Устройства ввода/вывода

Диспетчеризация (управление потоками/процессами) FIFO(First Input First Output) Карусельная (Round Robin) Адаптивная (изменяет приоритет) Спорадическая (изменяет приоритет)

Управление приоритетами Статические алгоритмы планирования (RMS — Rate Monotonic Scheduling). Используют приоритетное вытесняющее планирование. Приоритет присваивается каждой задаче до того, как она начала выполняться. Преимущество отдается задачам с самыми короткими периодами выполнения. Динамические алгоритмы планирования (EDF — Earliest Deadline First Scheduling). Приоритет задачам присваивается динамически, причем предпочтение отдается задачам с наиболее ранним предельным временем начала (завершения) выполнения.

Управление памятью Выделение памяти Освобождение памяти Это один из процессов принципиально влияющих на быстродействие и надежность работы всей системы.

Архитектура ОС - Системы с монолитным ядром с использование планировщиком РВ - Многоуровневые системы - Микро-ядерные системы. Системы с использованием клиент-серверного подхода

Системы с монолитным ядром

Системы с монолитным ядром с использование планировщиком РВ Программы РВ Монолитное ядро Диспетчер РВ Аппаратура ПК

Многоуровневые системы без защиты памяти

Микро-ядерные системы.

Общие требования к ОС РВ Вытесняющую многозадачность Поддержка приоритетов Поддержка предсказуемых механизмов синхронизации Наследование приоритетов Предсказуемость. Поведение ОС должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т. д. ); это значит, что во всех сценариях рабочей нагрузки системы должно быть определено максимальное время отклика.

Отраслевые требования к ОСРВ должны обеспечивать высокую степень "живучести" системы так, чтобы при отказе какой-либо части ПО другая часть ПО продолжала нормально функционировать. ОСРВ должна гарантировать отсутствие общего отказа системы; ОСРВ должны удовлетворять жёстким требованиям по качеству ПО, что подразумевает соответствие различным отраслевым, национальным и международным стандартам. Особенностью требований к ОСРВ является то, что ПО должно иметь доказанное качество и во многих случаях должно быть сертифицировано уполномоченными организациями; требование по надёжности: вероятность сбоя в ПО должна быть очень маленькая; требования по безопасности (safety) и секретности (security) данных: в системе должны быть предусмотрены средства защиты наиболее важной информации.

DO-178 Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification). Определяет процедуры сертификации ПО на основе требуемого уровня качества ПО. Разработан и поддерживается ассоциацией RTCA (Radio Technical Commission for Aeronautics, http: //www. rtca. org). Первая версия стандарта принята в 1982 г. , вторая (DO-178 A) - в 1985. Текущая версия DO-178 B принята в 1992 г. Новая версия DO-178 C готовится специальным комитетом RTCA SC-205 WG 71 EUROCAE (European Organization for Civil Aviation Equipment) Важная особенность классификация уровней отказов. Стандартом определено пять уровней серьёзности отказа (A, B, C, D, E). Для каждого уровня определён набор требований к ПО, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьёзности;

ARINC 653 (Avionics Application Software Standard Interface). Стандарт разработан компанией ARINC (Aeronautical Radio, Inc. ) в 1997 г. и вводит концепцию изолированных разделов на основе универсального программного интерфейса APEX (Application/Executive) между ОСРВ и прикладным ПО. Требования интерфейса между прикладным ПО и сервисами ОС определяются таким образом, чтобы разрешить прикладному ПО контролировать диспетчеризацию, связь и состояние внутренних обрабатываемых элементов. В 2003 г. принята новая редакция. Стандарт ARINC 653 в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин; * Управление разделами (англ. Partition Management) * Управление процессами (англ. Process Management) * Управление временем (англ. Time Management) * Взаимодействие между разделами (англ. Interpartition Communication) * Взаимодействие внутри раздела (англ. Intrapartition Communication) * Реакция на ошибки (англ. Health Monitoring)

CCITSE Общие критерии для оценки безопасности информационных технологий (Common Criteria for Information Technology Security Evaluation - CCITSE). Это набор требований и условий безопасности, одобренный Агентством национальной безопасности и Национальным институтом стандартов и технологий США (http: //csrc. nist. gov/cc/), а также соответствующими органами в других странах (в данный момент ещё 13 стран, кроме США). Первая версия требований опубликована в январе 1996 г. , вторая - в апреле 1998 г. В 1999 г. CCITSE получил статус международного стандарта ISO 15408. (http: //www. commoncriteria. org. )

MILS (Multiple Independent Levels of Security/Safety). MILS делает возможной математическую верификацию программного ядра системы путём уменьшения функциональности за счёт предъявления к системам четырёх обязательных групп требований (Information Flow, Data Isolation, Period Processing, Damage Limitation). Развивается проект усилиями заинтересованных компаний и организаций, таких как U. S. Air Force Research Laboratory, Lockheed Martin, Агентство национальной безопасности США и др. (http: //mils. ois. com). Базовое понятие «разделенное ядро» . Тип защищенного ядра, симулирующего распределенное технического окружение. Защищает и разделяет все ресурсы машины Обеспечивает взаимодействие между различными частями Контролирует все взаимодействия.

Российские ГОСТЫ ГОСТ Р ИСО/МЭК 51904 -2002 ( «ПО встроенных систем. Общие требования к разработке и документированию» ) — аналог DO-178 B для военной авиации; ГОСТ Р ИСО/МЭК 12207 -99 ("Информационная технология. Процессы жизненного цикла программных средств"); ГОСТ Р ИСО/МЭК 15408 -2002 ("Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий").

Характеристики ОС РВ Время реакции на событие Время переключение контекста Количество приоритетов Количество задач Масштабируемость Типы диспетчеризации Контроль за исполнением

Обзор операционных систем Lynx. OS (POSIX, Linux) Vx. Works OS 9 (POSIX) QNX (POSIX) Windows Linux Платформа Java Singularity

Временные рекомендации Менее 10 мкс 10 - 100 мкс Операционные системы реального времени Специализированные ОСРВ. 100 мкс - 1 мс ОСРВ, RTAI, RT- UNIX и LINUX, расширения реального времени для Windows NT, CE 1 мс Linux и Windows NT, но не для систем, где опоздания реакции могут привести к тяжелым последствиям

Windows Расширение RTX Модификации от Microsoft Windows Embedded CE Windows XP Embedded Windows Automotive

Результаты сравнительного тестирования ОСРВ QNX 6. 1, Vx. Works и Windows CE. NET

Linux RTLinux Kurt Red. Hat RT Suse RT и другие.

Системы РВ и управляемым кодом Java , Real-Time Specification for Java (RTSJ) Android C#

Ключевые факторы - Используется концепция управляемого кода. - Использование виртуальной машины - Использование ООП - Автоматическое управление памятью(cборка мусора)

Модель запуска программы

Плюсы-минусы Достоинства Высокая масштабируемость Использование виртуальной машины Высокая надежность Широкая распространенность Недостатки/издержки автоматическое управление памятью

OS Android - Предназначена для использования в мобильных устройствах общего применения - Система построена на базе микроядра и виртуальной машины. - Используется концепция управляемого кода.

Архитектура Android

Singularity - Система построена на концепции управляемого кода. - Используется полностью типизированный язык программирования. Sing#. - Программно-изолированные процессы (Software-Isolated Process, SIP)

Свойства SIP * SIP-ы – это закрытые объектные, а не адресные пространства. Два процесса Singularity не могут одновременно получить доступ к объекту. * SIP-ы – это закрытые пространства кода. Процесс не может динамически загружать или генерировать код. * SIP-ы не используют для изоляции аппаратное управление памятью. В физическом или виртуальном адресном пространстве может находиться несколько SIP. * Связь между SIP осуществляется через двунаправленные, строго типизированные высокоуровневые каналы. Канал определяется коммуникационным протоколом и передаваемыми значениями, оба аспекта проверяются. * SIP-ы недорого создавать, а накладные расходы при коммуникациях между SIPами незначительны. Низкая стоимость делает практичным использование SIPов на более детальном уровне изоляции и в механизме расширения. * SIP-ы создаются и уничтожаются операционной системой. Поэтому при их уничтожении ресурсы, занятые SIP-ами гарантированно освобождаются. * SIP-ы исполняются независимо. Они могут иметь разные раскладки данных, исполняющие системы и сборщики мусора.

Вопросы?