Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Операционные системы реального времени и технологии разработки кроссплатформенного программного обеспечения. Ч.4. Учебное пособие
.pdf
3.7. Обеспечение отказоустойчивости систем реального времени
91
нивелируют влияние отказов, либо маскируют их. Кроме того, подобные
системы обладают определенными шаблонами поведения в случае возникновения критических ситуаций. При возникновении сбоя система оказывается готова к ней и запускается процесс ликвидации последствий.
Обеспечение живучести – это методика применения специализированных средств, которая позволяет системе продолжить корректную работу
при возникновении отказа ее аппаратных элементов или программ. Средства обеспечения живучести позволяют рационально распределять вычислительные ресурсы и повысить среднее время наработки до отказа.
В обеспечение живучести включены три основные функции:
1. диагностика;
2. локализация неисправности;
3. перестройка системы.
Другим аспектом является применение защитных инструментов систем, позволяющих поддерживать связь между компонентами и восстанавливаться при сбоях. Для любой системы со средствами защиты и восстановления характерны программная, информационная и временная избыточность.
Под временной избыточностью понимается выделение части ресурсов и квантов производительности для слежения за системой и получения
диагностических данных о ее состоянии.
Программная избыточность применяется для обеспечения достоверности решений по управлению системой и достоверности обрабатываемой информации. Применяется набор программ, обеспечивающих подходы к ее решению и расположенных сразу на нескольких дублирующих
узлах системы.
Для синхронизации функционирования отказоустойчивых подсистем
применяются протоколы согласования, которые выполняют синхронизацию решений одной и той же задачи на разных узлах.
На сегодняшний день известно несколько вариантов обеспечения отказоустойчивости функционирования систем:
1. фиксация константного отказа или сбоя системы в целом;
2. обеспечение отказоустойчивости с маскированием сбоев.
Фиксация константного отказа системы сопряжена с последующей реконфигурацией программ или оборудования, а также с прерыванием
3. Классификация ОС РВ
92
работы системы. Данный способ плохо применим в ОС РВ, так как он нарушает принципы детерминированности рабочего процесса.
Обеспечение отказоустойчивости системы с маскированием сбоев ра-
ботает по принципу мажорирования. Данный способ применяется в системах реального времени, так как наоборот ведет к детерминированности.
При аппаратной реализации потеря производительности связана с
необходимостью синхронизации процессов в резервированных каналах
связи, а каждая маскировка сбоя сопровождается локальной потерей производительности на 30 % в среднем и увеличением числа связей.
При аппаратном мажорировании ситуация с производительностью
хуже, чем при программном. Увеличение кратности маскируемых сбоев невозможно.
3.8. Настраиваемость операционных систем
реального времени
Существуют различные подходы к настраиваемости ОС.
Адаптация, производимая человеком
При статической адаптации, инициированной проектировщиком, все
системные функции и политики должны быть определены на этапе проектирования. При этом все системные сервисы встраиваются в ядро. В этом
случае для каждого приложения должна проектироваться и реализовываться новая система, а один тип устройств или компьютеров будет поддерживать только одно приложение (или ограниченное число приложений).
Для того чтобы избежать проектирования каждой новой ОС с нуля, могут
быть использованы следующие каркасы (framework):
− Flux OSKit;
− Scount;
− Choices;
− Pebble;
− PURE.
Динамическая адаптация, инициированная администратором, осуществляет поддержку адаптации во время выполнения, которую осуществляет администратор или пользователь. Подобная адаптация может быть достигнута двумя способами.
3.8. Настраиваемость операционных систем реального времени
93
1. Метод загружаемого модуля ядра. В этом случае администратор
имеет возможность выполнить загрузку модулей в ядро, что способно привести к изменению или расширению функциональности ОС. Основное преимущество данного метода – это простота, а главный недостаток заключается в потенциальном нарушении механизмов безопасности системы при
добавлении произвольного кода в ядро, что способно привести к выходу из
строя системы.
2. Настройка системы. Как правило, политики ОС могут изменяться
либо администратором, либо пользователем. Также существуют счетчики
производительности, которые помогают оценить преимущества той или
иной политики, настроенной через параметры. Преимущество данного подхода состоит в том, что механизмы зашиты не дискредитируются. Недостатком можно считать тот факт, что при таком подходе ограничиваются
широта применения и уровень детализации.
Динамическая адаптация от имени администратора широко применя-
ется во всех промышленных ОС (Linux, Solaris, Windows NT).
Адаптация, инициированная человеком
Данный вид адаптации производится только динамически, а её приме-
нение полезно в ОС общего назначения. Цель динамически настраиваемых
ОС состоит в том, чтобы достичь лучшей производительности всей системы в целом, разрешая настройки, которые приводят к преобладанию
преимуществ перед накладными расходами.
Новое поколение микроядерных ОС отвечает целям настраиваемости.
Однако критическим остается вопрос производительности, связанный со
значительным количеством переключений между доменами (как между
пользовательским уровнем и ядром, так и между адресными пространствами), а также с местоположением основной памяти.
Выбранный набор абстракций, интегрированных в ядро, существенным образом влияет на производительность и гибкость. Чем меньше абстракций, тем большая гибкость остается для приложений. В ядре должны
присутствовать только те абстракции, которые необходимы для деятельности самого ядра.
Результатом приближения микроядерной философии к ее логической
крайности становится ОС, в которой все системные сервисы выведены за
пределы ядра и реализованы в виде библиотек, а само ядро становится попросту абстракцией аппаратных ресурсов.
3. Классификация ОС РВ
94
Портал-ориентированная система – это микроядро, которое имеет минимально возможный код и работает в самом доступном привилегированном режиме. Такие системы обладают доменами защиты, которые обеспечивают безопасность работы пользователя. Порталы используются для взаимодействия между доменами.
Рефлективные операционные системы вводят явную парадигму, которая дает возможность приложениям динамически настраивать свою среду
выполнения. Приложение должно быть явно структурировано как совокупность объектов, а системные сервисы представляются в виде совокупности
мета-объектов.
Адаптация на уровне ядра
Системы, допускающие адаптацию на уровне ядра, обычно называются наращиваемыми ядрами (extensible kernels). Эти системы применяют
передовые технологии, которые гарантируют целостность ядра. Наращиваемые ядра принимают код пользователя и выполняют его в привилегированном безопасном режиме, динамически изменяя поведение ядра. Эта технология позволяет избавиться от переключений между режимами пользователя и ядра и между адресными пространствами. Поскольку коду, который вводится приложением в ядро, нельзя доверять, решающим фактором
для наращиваемых ядер становится применяемый механизм безопасности.
В системах с наращиваемыми ядрами полагаться на аппаратную защиту
невозможно, потому что расширение (ненадежный код) обладает теми же
полномочиями, что и ядро. Здесь необходимо применять программную защиту. Наиболее распространенными подходами к программной защите являются: программная локализация неисправностей и безопасные языки.
Программная локализация неисправностей обеспечивает защиту памяти в едином адресном пространстве. Она осуществляется в два этапа.
Сначала ненадежный код загружается в собственный изолированный домен
(так называемый «неисправный» домен), который является областью памяти, логически разделенной с ядром. Затем код модифицируется таким образом, что из него нельзя осуществить запись или выполнить команду перехода за пределы этого изолированного домена.
К недостаткам метода программной локализации неисправностей
можно отнести то обстоятельство, что каждый раз перед выполнением
ненадежной инструкции должны выполняться накладные инструкции.
3.8. Настраиваемость операционных систем реального времени
95
Другим распространенным способом сохранения целостности ядра является наложение ограничений на абстракции языка программирования.
Наиболее интересным механизмом такого типа является метод проверки
типов (type checking), который подразумевает, что безопасные языки являются типизированными и обладают типовой безопасностью. К безопасным
языкам относят: Modula-3, Java и ML.
Метод автоматической верификации основан на представлении кода в
определенном формате, называемом PCC (Proof-Carrying Code). PCC-модуль содержит формальное доказательство соответствия кода данной политике безопасности. Истинность доказательства гарантирует безопасность
кода, и программный модуль может выполняться без проверок во время выполнения. Несмотря на привлекательность этого подхода, применимость
его пока остается проблемой. Большие трудности возникают при попытках
автоматизировать генерацию доказательств и использовать доказательства
для языков высокого уровня.
Автоматическая адаптация
Инициируется самой ОС. Можно рассматривать переносимость, реализуемую через условную компиляцию, как статическую форму автоматической адаптации. Обнаружив, на какой платформе операционная система
должна быть скомпонована, система сама способна конфигурироваться,
например, с помощью C препроцессора.
Наиболее интересную категорию составляют ОС, которые сами динамически или статически адаптируются к выполняющимся приложениям.
С этой целью ОС должна быть способна отслеживать и анализировать приложения, и автоматически изменять свое поведение, чтобы поддерживать
приложения наилучшим образом. Промышленные ОС обычно поддерживают ограниченную форму динамической автоматической адаптации в специфических и хорошо понятных подсистемах, например, в файловой системе, которая может контролировать поведение пользовательских приложений для оптимизации своей производительности.
Создание автоматической динамически настраиваемой ОС общего
назначения можно рассматривать как конечную цель исследований в области настраиваемости ОС. Однако в связи с трудностями, возникающими
при компоновке таких систем, пока еще ничего не слышно об автоматических системах в полном смысле этого слова.
3. Классификация ОС РВ
96
3.9. Типы архитектур операционных систем
реального времени
Архитектуры классических ОС РВ основываются на архитектурах
UNIX-систем и используют традиционный процедурный подход к програм-
мированию. Сочетание объектно-ориентированных приложений и процедурных ОС имеет ряд недостатков:
− происходит разрыв парадигмы программирования: в едином рабо-
тающем комплексе (приложение + ОС РВ) разные компоненты используют
разные подходы к разработке программного обеспечения;
− не используются все возможности объектно-ориентированного
подхода;
− возникают потери производительности из-за разного типа интер-
фейсов в ОС РВ и приложении.
− Возникает идея осуществить построение ОС РВ, используя объ-
ектно-ориентированный подход. При этом:
− как приложение, так и операционная система полностью объектно-
ориентированы и используют все преимущества этого подхода;
− приложение и ОС РВ могут быть полностью интегрированы, по-
скольку используют один объектно-ориентированный язык программирования;
− обеспечивается согласование интерфейсов ОС РВ и приложения;
− приложение может «моделировать» ОС РВ для своих потребно-
стей, заказывая нужные ему объекты;
− единый комплекс приложение + ОС РВ является модульным и
легко модернизируемым.
Монолитная архитектура
ОС РВ с монолитной архитектурой можно представить в виде:
− прикладного уровня: состоит из работающих прикладных процессов;
− системного уровня: состоит из монолитного ядра ОС, в котором
можно выделить – интерфейс между приложениями и ядром (API), ядро системы, интерфейс между ядром и оборудованием (драйверы устройств).
API в таких системах играет двойную роль:
1. управление взаимодействием прикладных процессов и системы;
2. обеспечение непрерывности выполнения кода системы (т.е. отсут-
ствие переключения задач во время исполнения кода системы).
3.9. Типы архитектур операционных систем реального времени
97
Основным преимуществом монолитной архитектуры является ее отно-
сительная быстрота работы по сравнению с другими архитектурами. Однако достигается это за счет написания фрагментом системы на ассемблере.
Недостатки данной архитектуры следующие.
1. Системные вызовы, требующие переключения уровней привиле-
гий (от пользовательской задачи к ядру), должны быть реализованы API как
прерывания или ловушки (специальный тип исключений). Этот увеличивает время их функционирования.
2. Ядро не может быть прервано пользовательской задачей (non-
preemptable). Это может приводить к тому, что высокоприоритетная задача
может не получить управления из-за работы никзоприоритетной.
3. Сложность переносы на новые архитектуры процессора из-за зна-
чительных ассемблерных вставок.
4. Негибкость и сложность развития: изменение части ядра системы
требует его полной перекомпиляции.
Модульная архитектура
Модульная архитектура возникла как следствие исключить узкое ме-
сто – API и облегчить модернизацию системы и её перенос на новые процессоры.
API в модульной архитектуре обеспечивает связь прикладных процессов и специального модуля – менеджера процессов. Микроядро играет
двойную роль:
1. управление взаимодействием частей системы;
2. обеспечение непрерывности выполнения кода системы (возмож-
ность переключения задач во время исполнения микроядра отсутствует).
К недостаткам данной архитектуры относится то, что системный интерфейс по-прежнему не допускает переключения задач во время работы
микроядра.
Объектная архитектура на основе
объектов-микроядер
В данной архитектуре API отсутствует. Взаимодействие между компонентами системы (микроядрами) и пользовательскими процессами осуществляется посредством обычного вызова функций, поскольку и система,
и приложения написаны на C++, за счёт чего достигается максимальная скорость системных вызовов.
3. Классификация ОС РВ
98
Фактическое равноправие всех компонент системы обеспечивает воз-
можность переключения задач в любое время. Объектно-ориентированный
подход обеспечивает модульность, безопасность, легкость модернизации и
повторного использования кода.
Микроядра по своим характеристикам напоминают структуры, ис-
пользуемые в других ОС, однако существуют следующие различия.
1. Микроядра и модули. Многие ОС поддерживают динамическую
загрузку компонент системы, называемых модулями. Однако модули не
поддерживают объектно-ориентированный подход. Далее, обмен информацией с модуля происходит посредством системных вызовов, что является дорогостоящим.
2. Микроядра и драйверы. Многие ОС поддерживают возможность
расширения посредством драйверов. Драйверы часто должны быть статически связаны с ядром (т.е. образовывать с ним связанный загрузочный образ еще до загрузки) и должны работать в привилегированном (суперпользовательском) режиме. Как и модули они не поддерживают объектно-ориентированный подход и доступны приложениям только посредством системных вызовов.
3. Микроядра и DLL (Dynamically Linked Libraries, динамически свя-
зываемые библиотеки). Из библиотек берутся функции при динамическом
связывании, в виде специальных модулей, называемых DLL. DLL обеспечивает разделение своего кода и данных для всех работающих приложений,
в то время, как для микроядер можно управлять доступом для каждого конкретного приложения. DLL не поддерживает объектно-ориентированный
подход, код DLL не является позиционно-независимым, и потому он не может быть записан в ПЗУ.
3.1. Классические ОС РВ
99
ЗАКЛЮЧЕНИЕ
Задачи реального времени формируют одну из сложнейших областей
применения вычислительной техники. Такие задачи состоят в контроле и
управлении процессами, которые являются неотъемлемой частью современной жизни. Управление прокатными станами, роботами, движение на
автомагистралях, контроль за состоянием окружающей среды, управление
атомными и космическими станциями и многое другое – область задач реального времени. Подобные задачи предъявляют такие требования к аппаратному и программному обеспечению, как надежность, высокая пропускная способность передающей среды в распределенных системах, своевременная реакция на внешние события и т.д. Именно для выполнения таких
требований происходит разработка систем реального времени, а также аппаратного и программного обеспечения.
В процессе анализа систем реального времени важным условием является выбор оптимальной модели диспетчеризации потоков в рамках конкретной задачи. Определение метода распределения приоритетов, а также
обоснование диспетчеризации всех потоков жесткого реального времени
являются важнейшими действиями при проектировании систем реального
времени. Дополнительные сложности возникают вследствие отсутствия
строгих математических методов оценивания диспетчеризации непериодических динамических потоков.
Таким образом, выбор операционной системы для разработки системы
реального времени является ответственным шагом, который может определить успех реализации системы в целом.
Список литературы
100
СПИСОК ЛИТЕРАТУРЫ
1. ОС QNX. – URL: https://habr.com/ru/articles/124656/.
2. ОС RTLinux. – URL: https://kurl.ru/NcbVP.
3. ОС VxWorks. – URL: https://kurl.ru/EFUhJ.
4. ОС ChibiOS/RT. – URL: https://kurl.ru/SpJda.
5. ОС Contiki. – URL: https://techvidvan.com/tutorials/iot-contiki-os/.
6. ОС FreeRTOS. – URL: https://kurl.ru/WClPg.
7. ОС OSE RTOS. – URL: https://kurl.ru/FjoOY.
8. ОС Inferno. – URL: https://kurl.ru/Efcqp.
9. ОС OS-9. – URL: clck.ru/36cx75.
10. ОС Integrity. – URL: https://ghs.com/products/rtos/integrity.html.
11. ОС INtime. – URL: https://tenasys.com/products/intime-rtos/.
12. ОС ITRON. – URL: https://kurl.ru/XAKrV.
13. ОС LynxOS. – URL: https://kurl.ru/TcdLa.
14. ОС Microsoft Windows Embedded. – URL: https://kurl.ru/ohihG.
15. ОС pSOS. – URL: https://kurl.ru/OLJHE.
16. ОС RTEMS. – URL: https://www.rtems.org/.
17. ОС DeltaOS. – URL: https://kurl.ru/vERXJ.
18. ОС PikeOS. – URL: clck.ru/36cx9r.
19. ОС Embox. – URL: clck.ru/36cxCm.
20. ОС Chorus OS. – URL: https://kurl.ru/VqvGF.
21. ОС RTC. – URL: https://kurl.ru/TDLfg.
22. ОС JavaOS. – URL: https://kurl.ru/IzJLa.
23. ОС VRTX. – URL: https://kurl.ru/tpDMv.
24. ОС RTX. – URL: https://kurl.ru/MEIuK.
25. ОС TinyOS. – URL: https://kurl.ru/noRGp.
26. ОС Windows CE. – URL: https://kurl.ru/blejh.
27. ОС Багет. – URL: https://kurl.ru/yLdzc.
28. ОС БагроОС 4000. – URL: https://kurl.ru/uRgps.
29. ОС МАКС. – URL: https://mir.dev/rtos-macs/.
30. ОС Эльбрус. – URL: https://kurl.ru/sYuuB.
31. ОС Нейтрино. – URL: https://kpda.ru/products/kpda10964/.
32. ОС Заря РВ. – URL: https://kurl.ru/SgOIQ.
33. ОС РЕД ОС. – URL: https://redos.red-soft.ru/.
34. ОС Альт. – URL: https://os-alt.ru/.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]