Методология разработки программного обеспечения – информатика, программирование – referat-zona.ru
1.5. Методология разработки программного обеспечения.
Возрастающая сложность современного программного обеспечения привела к созданию специальной научной дисциплины — компьютерной инженерии (Software Engineering), основной задачей которой является создание эффективных методов разработки сложных программных систем.
1.5.1. История развития.
Объектно-ориентированные методологии разработки программного обеспечения (первое направление) стали интенсивно развиваться с конца 80-х годов. В 1997 г. OMG (Object Management Group) приняла UML, появившийся в результате слияния ряда известных методологий, в качестве стандарта языка объектно-ориентированного моделирования. Еще одним объектно-ориентированным подходом является методология ROOM, созданная для разработки систем реального времени. Одновременно в течение последних 20 лет международным комитетом ITU развиваются стандарты для разработки телекоммуникационных систем (второе направление): SDL, MSC и т.д. Кроме того, с 70-х годов развиваются структурные методологии разработки программного обеспечения (третье направление): SADT, IDEF-стандарты, метод Йордана и т.д. В настоящее время эти методологии прочно закрепились в области разработки информационных систем. Они являются эффективным средством анализа систем в целом и успешно применяются.
В данной работе описывается объектно-ориентированная методология Real. Методология Real основывается, главным образом, на UML, SDL, ROOM и отражает перечисленные интеграционные тенденции. Помимо стандартных для объектно-ориентированного подхода черт в Real добавлены дополнительные возможности, направленные на две специальные области программного обеспечения: для информационных систем и для систем реального времени.
Естественно, что Real не претендует на то, чтобы покрыть все возможности программных продуктов соответствующих областей. В то же время, учитывая современный уровень развития локальных и глобальных информационных сетей и возрастающую сложность программного обеспечения, в информационных системах все большую популярность приобретает технология клиент-сервер, т.е. многие информационные системы приобретают ярко выраженный событийно-ориентированный аспект, который глубоко проработан в методологиях разработки программного обеспечения систем реального времени. С другой стороны, большие распределенные системы реального времени нуждаются, как правило, в хранении, доступе и передаче огромного количества информации (например, тарификационной и аутентификационной), а не только управляющих сигналов и данных трафика. Таким образом, методология Real подходит для разработки программного обеспечения обеих областей, но наиболее эффективна для их пересечения.
1.5.2. Разработка программного обеспечения систем реального времени
Основное назначение Real применительно к системам реального времени — проектирование сложной управляющей логики с последующей возможностью автоматической генерации кода. Отметим, что методология Real не ориентирована специальным образом на разработку оборудования и программного обеспечения, непосредственно с ним контактирующего (драйверов устройств и т.п.), а также сетевых протоколов нижнего уровня. Однако мы считаем, что для этих задач она подходит примерно в той же степени, как и UML.
Как показывает практика, прямые ветки сложных алгоритмов достаточно удобно и наглядно определять с помощью сценариев. На начальных этапах разработки системы нужно четко определить логику всех взаимодействий. При этом правила поведения системы в ошибочных ситуациях в большинстве случаев можно доработать позднее. По сценариям можно сгенерировать STD- или SDL-диаграммы и продолжить создание спецификаций уже в этом стиле, учитывая все допустимые варианты поведения системы.
В терминах Real основной структурной единицей системы реального времени является объект. Объекты взаимодействуют друг с другом через интерфейсы. Под взаимодействием понимается посылка сообщений, вызов методов и обращение к атрибутам интерфейса. Поскольку в последнее время все большее число систем реального времени становятся распределенными и сетевыми, понятие интерфейса приобретает особую важность. Раньше ситуация была иной, примером чего служат ранние версии языка SDL, в которых интерфейсы отсутствовали. Интерфейсы Real сильно отличаются от портов (gate) SDL (составом, способом связи с классами) и интерфейсов UML (составом, способом связи с классами, способом изображения), а также интерфейсов в ROOM (составом и способом изображения).
В системах реального времени важную роль играют абстракции точек входа и выхода у различных компонент программного обеспечения. Поэтому в модель классов Real был добавлен из ROOM специальный элемент — порт.
Компонента программного обеспечения, определенная в виде класса с портами и интерфейсами, может иметь конечно-автоматное поведение, описываемое в терминах поведенческой модели Real. Поведенческая модель, в свою очередь, представляется двумя альтернативными нотациями: первая основана на варианте STD, представленном в ROOM, вторая — на расширенном конечном автомате SDL. С помощью STD-нотации удобно определять поведение компонент системы на ранних этапах разработки: множество мелких деталей можно временно убрать из поля зрения. В то же время на SDL-диаграммах можно наглядно изобразить мельчайшие подробности алгоритмов.
Эта возможность становится полезной на поздних этапах проектирования. При этом информацию, изображенную на STD-диаграммах, можно ”загрузить” на SDL-диаграммы, таким образом, результаты ранних этапов при переходе к более формальной спецификации не будут потеряны. В рамках Real, STD и SDL нотации предназначены для описания единой поведенческой модели, так что всегда возможно и обратное — загрузка на STD-диаграмму результатов работы с SDL-редактором. На поведенческую модель Real сильно повлияла технология SDL/PLUS 20: так же не используются типы данных и выражения SDL, но применяется более гибкая стратегия связи с языками реализации [7] вместо заранее фиксированного языка [11].
§
1.4.2. OS-9/Hawk фирмы Microware Systems.
Многозадачная, многопользовательская операционная система для встраиваемых приложений, работающих в режиме реального времени. Для производителей продуктов в таких областях, как мобильные телекоммуникационные устройства, встраиваемые терминалы доступа в Интернет, интерактивные цифровые телевизионные приставки.
1.4.2.1. Основные свойства OS-9/Hawk.
· Переносимая версия OS-9 позволяет применять в проекте наиболее подходящие микропроцессорные устройства (Motorola ColdFire; Motorola M-CORE; Intel Pentium; Intel StrongARM; PowerPC; ARM; Hitachi SuperH; MIPS; MicroSPARC).
· Система ввода-вывода ОС поддерживает различные форматы устройств массовой памяти и основных интерфейсов периферийных устройств: Raw, MS-DOS, True FFS, CardSoft PCMCIA, USB, IrDA.
· В среде OS-9 пользователь может выбирать несколько программных коммуникационных платформ: mwSoftStax (Microware), Harris & Jeffries, Trillium, – что ранее было исключительно прерогативой специализированных ОС.
· В инструментальный пакет Hawk встроена библиотека Tools.h из библиотеки Rogue Wave C Classes Lib.
· Hawk – интегрированная кросс-среда разработки приложений для OS-9 – функционирует на платформе MS Windows NT.
· Hawk является открытой средой и предоставляет сторонним разработчикам инструментальных средств более сотни API, позволяющих включать в рамках Hawk Partners Program в состав среды Hawk продукты известных фирм разработчиков инструментального ПО.
· Средство верификации программного обеспечения CodeTEST (Applied Microsystems) встроено в Hawk и представляет собой удобный и эффективный инструментарий трассировки встраиваемого ПО и контроля его характеристик, а также хода выполнения тестов и распределения памяти.
1.4.2.2. Поддержка приложений жёсткого реального времени.
· масштабируемое, полностью вытесняемое ядро ОС;
· поддерживает функционирование до 65535 процессов;
· предоставляет 65535 уровней приоритета;
· обеспечивает работу до 255 пользователей;
· более 90 системных вызовов ядра предоставляют возможность управлять динамическими режимами диспетчеризации, распределением памяти, межпроцессорной коммуникацией и т.д. вплоть до управления встроенным в ядро ОС режимом экономичного потребления питания.
· характеристики производительности: 5.6 мкс Interrupt Latence Time, 14 мкс для времени переключения контекста процесса (MC68040, 30MHz).
1.4.3. VxWorks фирмы Wind River Systems.
ОС РВ VxWorks предназначена для применения на встроенных компьютерах, работающих в системах “жесткого” реального времени. VxWorks является системой с кросс-средствами разработки прикладного программного обеспечения.
1.4.3.1. Основные свойства VxWorks.
· Поддерживаемые целевые архитектуры (targets): Motorola 680х0 и CPU32, PowerPC; Intel 386/486/Pentium, Intel 960; Sparc, Mips R3000/4000; AMD 29K, Motorola 88110; HP PA-RISC; Hitachi SH7600; DEC Alpha.
· Поддерживаемые инструментальные платформы (hosts): Sun SPARCstation (SunOS и Solaris); HP 9000/400,700 (HP-UX); IBM RS6000 (AIX); Silicon Graphics (IRIX); DEC Alpha (OSF/1); PC (Windows).
· Все аппаратно-зависимые части VxWorks вынесены в отдельные модули для того, чтобы разработчик встроенной компьютерной системы мог сам портировать VxWorks на свою нестандартную целевую машину.
· В последней версии VxWorks 5.2 реализованы совместимые с расширениями POSIX для приложений реального времени (POSIX Real-Time Extensions 1003.1b) функции асинхронного ввода-вывода, счётные семафоры, очереди сообщений, сигналы, управление памятью (блокировка страниц), управление диспетчеризацией, часы и таймеры.
· Стандартным языком программирования в инструментальном комплексе VxWorks является язык С. Система программирования на языке C не входит в стандартную конфигурацию инструментального комплекса VxWorks и поставляется как дополнительный продукт. Система программирования на языке Ada для VxWorks поставляется почти всеми Ada-производителями.
· Возможность исследования динамики исполнения программ и изменения данных предоставляют специальные средства отладки в реальном масштабе времени, которые трассируют интересующие пользователя события и накапливают их в буфере для последующего анализа.
1.4.3.2. Поддержка приложений жёсткого реального времени.
· Построена по технологии микроядра.
· Представляет собой архитектуру высокой готовности с распределенной передачей сообщений и поддержкой отказоустойчивости.
· ОС позволяет программистам изолировать совместно используемые библиотеки, данные и системное программное обеспечение, а также приложения.
1.4.4. QNX4 фирмы ОРАКУЛ.
QNX4 — многозадачная многопользовательская операционная система жесткого реального времени (ОСРВ) с архитектурой на основе микроядра и поддержкой ряда стандартов семейства POSIX.
1.4.4.1. Основные свойства QNX4.
· Состоит из микроядра и набора необязательных модулей.
· Предоставляет сервисы стандарта POSIX.1 и его расширения для систем реального времени POSIX.1b (POSIX.4).
· Можно использовать для расширения функциональных возможностей как штатные модули, так и свои собственные.
· Предоставляемое QNX4 окружение защищенного режима дает возможность легко и безопасно тестировать свои новые модули расширения.
· Возможности высокоскоростной трассировки диагностических событий.
· Позволяет запускать процессы по сети с полным наследованием окружения, включая открытые файлы, текущий каталог, файловые дескрипторы и идентификатор пользователя.
1.4.4.2. Поддержка приложений жёсткого реального времени.
· Являясь истинно микроядерной ОС, QNX4 строится вокруг компактного высоконадежного «стержня» – имеет микроядро размером всего 10 Кбайт.
· Микроядро QNX4 обладает достаточно малыми размерами для встраивания в ПЗУ.
· Обладает достаточно большой мощностью для управления распределенной сетью, содержащей нескольких сотен процессоров.
· Менеджер устройств является высокопроизводительным и вносящим очень малые накладные расходы серверным процессом, обеспечивающим интерфейс между процессами и терминальными устройствами.
1.4.5. Вывод.
Системы реального времени в настоящий момент являются востребованным продуктом на рынке программного обеспечения. Существует целая гамма средств данного направления, покрывающая практически весь спектр возможных применений подобных систем повышенной надежности.
§
1.3.3.2. Время переключения контекста.
В операционные системы реального времени заложен параллелизм, возможность одновременной обработки нескольких событий, поэтому все операционные системы реального времени являются многозадачными (многопроцессными, многонитиевыми). Для того чтобы уметь оценивать накладные расходы системы при обработке параллельных событий, необходимо знать время, которое система затрачивает на передачу управления от процесса к процессу (от задачи к задаче, от нити к нити), то есть время переключения контекста (диаграмма 7).
1.3.3.3. Размеры системы.
Для систем реального времени важным параметром является размер системы исполнения, а именно суммарный размер минимально необходимого для работы приложения системного набора (ядро, системные модули, драйверы и т. д.). Хотя, надо признать, что с течением времени значение этого параметра уменьшается, тем не менее он остается важным и производители систем реального времени стремятся к тому, чтобы размеры ядра и обслуживающих модулей системы были невелики.
Примеры: размер ядра операционной системы реального времени OS-9 на микропроцессорах МС68xxx – 22 KB, VxWorks – 16 KB.
1.3.3.4. Возможность исполнения системы из ПЗУ (ROM).
Это свойство операционных систем реального времени – одно из базовых. Оно позволяет создавать компактные встроенные СРВ повышенной надёжности, с ограниченным энергопотреблением, без внешних накопителей.
1.3.4. Вывод.
На столь широком поле деятельности как системы реального времени вполне закономерным оказалось возникновение множества подходов к их созданию. В основном они отличаются структурой создаваемой системы и аппаратной платформой, на которой ей предполагается функционировать. В настоящее время используются четыре основных параметра, которые могут характеризовать правильность выбранного подхода.
1.4. Современные представители рынка ОС РВ в России.
Среди коммерческих систем реального времени можно выделить группу ведущих систем – по объемам продаж и по популярности. Эти системы: VxWorks, OS9, LynxOS, QNX, pSOS, VRTX. В таблице 8 даны сведения о существующих в настоящее время СРВ и их характерных особенностях. В таблице 4 даны основные характеристики некоторых систем.
Четыре из перечисленных систем будут рассмотрены далее подробно. В системе, которая будет создана в рамках данной работы, не предусмотрены функции работы с работы с локальными или глобальными сетями. Поэтому в числе сравнительных параметров не были упомянуты эти возможности, которые являются немаловажной частью современных ОС РВ.
1.4.1. LynxOS® 4.x фирмы LinuxWorks, Inc.
Предназначена для разработки ПО встроенных систем, работающих в режиме жёсткого реального времени, производителями комплектного оборудования (OEM) и телекоммуникационного оборудования (TEM), в частности, изготовителями бортовых систем военного применения.
1.4.1.1. Основные свойства LynxOS:
· Поддерживает многозадачные и многопотоковые приложения.
· LynxOS обеспечивает совместимость с Linux на уровне ABI (Application Binary Interface), уровне форматов объектных файлов, вызовов API, динамически подключаемых библиотек (DLL), компоновки и загрузки на этапе выполнения. Это свойство LynxOS является уникальным для систем реального времени и очень полезным для пользователей (например в случае отсутствия исходных текстов). Система работает так же с Unix и Java.
· Полностью поддерживается стандарт POSIX.1003-1, а также подразделы POSIX.1003-1b и POSIX.1003-1c, определяющие расширения реального времени и работы с нитями (потоками).
· Многоплатформенность. Поддерживает множество аппаратных архитектур (IA-32, PowerPC, MIPS, ARM, XScale, IBM) для оборудования различных фирм производителей.
· Разработка может осуществляться как на самой целевой системе (self-hosted), так и на инструментальном компьютере (host).
· Является ОС для ответственных приложений. Имеет всё необходимое для создания современных систем, обладающих свойствами “горячей замены” / “высокой доступности” (Hot Swap, High Availability), и устройств с высоким коэффициентом резервирования.
· LynxOS-178 – это версия LynxOS, сертифицированная в соответствии со стандартом DO-178. Это означает полное соответствие с точки зрения надежности строгим требованиям для мобильных систем военного и аэрокосмического применения. Кроме того, LynxOS-178 имеет сертифицированный стек TCP/IP для ответственных приложений в области авионики, медицины, атомной промышленности и связи.
· Большое количество средств разработок как в рамках самой LynxOS, так и host-систем (Linux, Windows, Solaris).
1.4.1.2. Поддержка приложений жёсткого реального времени.
· количество задач: неограниченно;
· количество приоритетов: 256;
· диспетчеризация задач: вытеснение по приоритетам. 4 алгоритма диспетчеризации (FIFO, Priority Quantum, Round Robin, невытесняемый);
· детерминированное время переключения контекста благодаря эффективному алгоритму диспетчеризации реального времени;
· средства межзадачных взаимодействий как в стандарте POSIX (семафоры, разделяемая память, сокеты, сигналы, каналы, мьютексы, условные переменные), так и в терминах Unix SystemV (очереди сообщений, семафоры, разделяемая память);
· поддержка таймеров реального времени и часов POSIX;
· конфигурирование квантов времени для различных уровней приоритетов и для разрешения значения единицы (tick) таймера;
· выполнение задач в защищенном режиме, полная поддержка MMU (Memory Management Unit).
§
1.3.1.2. Ядра реального времени
В этот класс входят системы с монолитным ядром, где и содержится реализация всех механизмов реального времени этих операционных систем. Исторически системы этого типа были хорошо спроектированы. В отличие от систем других классов, которые появлялись как временные компромиссы и затем “наращивали мускулы” благодаря первым удачным реализациям (исполнительные системы реального времени и UNIX’ы реального времени), разработчики систем этого класса имели время для разработки систем именно реального времени и не были изначально ограничены в выборе средств (например фирма “Microware” имела в своем распоряжении три года для разработки первого варианта OS-9).
Одна из их особенностей – высокая степень масштабируемости. На базе этих ОС можно построить как компактные системы реального времени, так и большие системы серверного класса.
Как правило, ядра реального времени имеют два типа систем разработки – кроссовую и резидентную.
Системы этого класса, как правило, модульны, хорошо структурированы, имеют наиболее развитый набор специфических механизмов реального времени, компактны и предсказуемы. Наиболее популярные системы этого класса: OS9, QNX.
1.3.1.3. UNIX’ы реального времени
Исторически системы реального времени создавались в эпоху расцвета и бума UNIX’а и поэтому многие из них содержат те или иные заимствования из этой красивой концепции операционный системы (пользовательский интерфейс, концепция процессов и т.д.).
Часть разработчиков операционных систем реального времени попыталась просто переписать ядро UNIX, сохранив при этом интерфейс пользовательских процессов с системой, насколько это было возможно. Реализация этой идеи не была слишком сложной, поскольку не было препятствия в доступе к исходным текстам ядра, а результат оказался замечательным. Получили и реальное время, и сразу весь набор пользовательских приложений – компиляторы, пакеты, различные инструментальные системы.
В этом смысле создателям систем первых двух классов пришлось потрудиться не только при создании ядра реального времени, но и продвинутых систем разработки.
Однако Unix’ы реального времени не избавлены от следующих недостатков: системы реального времени получаются достаточно большими и реактивность их ниже, чем реактивность систем первых двух классов.
Наиболее популярным представителем систем этого класса является операционная система реального времени LynxOS.
1.3.2. Классификация по программной среде.
Становится очевидным то, что задачи реального времени необходимо реализовывать в рамках специфической системной программной среды. В соответствии с [12] системы реального времени можно разделить на 4 класса.
1.3.2.1. Программирование на уровне микропроцессоров.
В данном случае программы для программируемых микропроцессоров, встраиваемых в различные устройства, очень небольшие и обычно написаны на языке низкого уровня типа ассемблера или PLM. Внутрисхемные эмуляторы пригодны для отладки, но высокоуровневые средства разработки и отладки программ не применимы. Операционная среда обычно недоступна.
1.3.2.2. Минимальное ядро системы реального времени.
На более высоком уровне находятся системы реального времени, обеспечивающие минимальную среду исполнения. Предусмотрены лишь основные функции, а управление памятью и диспетчер часто недоступны. Ядро представляет собой набор программ, выполняющих типичные, необходимые для встроенных систем низкого уровня функции, такие, как операции с плавающей запятой и минимальный сервис ввода/вывода. Прикладная программа разрабатывается в инструментальной среде, а выполняется, как правило, на встроенных системах.
1.3.2.3. Ядро системы реального времени и инструментальная среда.
Этот класс систем обладает многими чертами ОС с полным сервисом. Разработка ведется в инструментальной среде, а исполнение – на целевых системах. Этот тип систем обеспечивает гораздо более высокий уровень сервиса для разработчика прикладной программы. Сюда включены такие средства, как дистанционный символьный отладчик, протокол ошибок и другие средства. Часто доступно параллельное выполнение программ.
1.3.2.4. ОС с полным сервисом.
Такие ОС могут быть применены для любых приложений реального времени. Разработка и исполнение прикладных программ ведутся в рамках одной и той же системы.
Системы 2 и 3 классов принято называть системами “жесткого” реального времени, а 4 класса – “мягкого”. Очевидно, это можно объяснить тем, что в первом случае к системе предъявляются более жесткие требования по времени реакции и необходимому объему памяти, чем во втором. Как мы видим, среда разработки и среда исполнения в системах реального времени могут быть разделены, а требования, предъявляемые к ним, весьма различны. Рассмотрим их более подробно.
1.3.3. Технические характеристики ОС РВ.
1.3.3.1. Время реакции системы.
Почти все производители систем реального времени приводят такой параметр, как время реакции системы на прерывание (interrupt latency).
В самом деле, если главным для системы реального времени является ее способность вовремя отреагировать на внешние события, то такой параметр, как время реакции системы является ключевым. Однако в настоящий момент нет, к сожалению, общепринятых методологий измерения этого параметра, поэтому он является полем битвы маркетинговых служб производителей систем реального времени. Есть надежда, что в скором времени положение изменится, так как уже стартовал проект сравнения операционных системах реального времени, который включает в себя в том числе и разработку методологии тестирования.
События, происходящие на объекте, регистрируются датчиками, данные с датчиков передаются в модули ввода-вывода (интерфейсы) системы. Модули ввода-вывода, получив информацию от датчиков и преобразовав ее, генерируют запрос на прерывание в управляющем компьютере, подавая ему тем самым сигнал о том, что на объекте произошло событие. Получив сигнал от модуля ввода-вывода, система должна запустить программу обработки этого события. Интервал времени – от события на объекте и до выполнения первой инструкции в программе обработки этого события и является временем реакции системы на события, и, проектируя систему реального времени, разработчики должны уметь вычислять этот интервал.
Время выполнения цепочки действий – от события на объекте до генерации прерывания – никак не зависит от операционных систем реального времени и целиком определяется аппаратурой, а вот интервал времени – от возникновения запроса на прерывание и до выполнения первой инструкции обработчика определяется целиком свойствами операционной системы и архитектурой компьютера. Причем это время нужно уметь оценивать в худшей для системы ситуации, то есть в предположении, что процессор загружен, что в это время могут происходить другие прерывания, что система может выполнять какие-то действия, блокирующие прерывания.
Неплохим основанием для оценки времен реакции системы могут служить результаты тестирования с подробным описанием архитектуры целевой системы, в которой проводились измерения, средств измерения и точным указанием, какие промежутки времени измерялись. Некоторые производители операционных систем реального времени результаты такого тестирования предоставляют. Их не увидишь в рекламных проспектах, но можно отыскать на WEB-страницах, в документах технической поддержки, в публикациях фирм, проводящих независимое тестирование.
Время реакции на прерывание, характерное для некоторых операционных систем реального времени, представлено на диаграмме 6.
§
1.2. Особенности управления задачами.
1.2.1. Управление временем.
Одним из основных свойств операционных систем реального времени является их способность изолировать друг от друга приложения, поэтому если в программе возникает сбой или выполняются какие-то нелегальные операции, ОС может быстро блокировать программу, инициировать восстановление и защиту других программ либо самой системы от серий вредоносных команд.
Если не выполняется обработка критических ситуаций либо она происходит недостаточно быстро, система жесткого реального времени прерывает операцию и блокирует ее, чтобы не пострадала надежность и готовность остальной части системы. Системы мягкого реального времени более «снисходительны» и «терпят» определенные, некритичные ошибки.
Особую важность приобретают такие инструменты как средства работы с таймерами, необходимые для систем с жестким временным регламентом. Развитость этих средств – необходимый атрибут операционных систем реального времени. Они, как правило, позволяют:
· измерять и задавать различные промежутки времени (от 1 мкс и выше),
· генерировать прерывания по истечении временных интервалов,
· создавать разовые и циклические будильники.
1.2.2. Управление памятью.
Система реального времени должна уметь управлять памятью в зависимости от критичности задач. Для устойчивой работы процессов требуются механизмы выделения памяти при их порождении, использования памяти при жизнедеятельности и освобождения.
ОС позволяет программистам изолировать совместно используемые библиотеки, данные и системное программное обеспечение, а также приложения. Та же самая защита предотвращает переполнение стеков памяти, вызываемое действиями любых программ.
1.2.3. Управление доступом (синхронизация).
При одновременной работе нескольких процессов в многозадачной системе реального времени операционная система должна обеспечить устойчивый механизм для обмена информацией между запущенными процессами. Связь между процессами (Interprocess communication, сокращенно IPC) является ключом к разработке приложений как совокупности процессов, в которых каждый процесс выполняет отведенную ему часть общей задачи.
Для операционных систем реального времени характерна развитость IPC-механизмов. К таким механизмам относятся: семафоры, события, сигналы, средства для работы с разделяемой памятью, каналы данных (pipes), очереди сообщений. Многие из подобных механизмов используются и в ОС общего назначения, но их реализация в операционных системах реального времени имеет свои особенности – время исполнения системных вызовов почти не зависит от состояния системы, и в каждой операционной системе реального времени есть по крайней мере один быстрый механизм передачи данных от процесса к процессу.
1.2.4. Вывод.
Так же как сами системы реального времени существенно отличаются от обычных ОС, так и способы выполнения задач в них имеют свою специфику. Работа по управлению их выполнением превращается в сложную инженерную задачу, которая включает в себя создание алгоритмов разделения ресурсов системы, планирования их независимого выделения и освобождения для задач системы.
1.3. Классификация систем реального времени.
Количество операционных систем реального времени, несмотря на их специфику, очень велико. В обзоре журнала “Real-Time Magazine” ещё за март 97 года было упомянуто около шестидесяти систем. За прошедшие годы этих систем стало ещё больше. Если же добавить к их числу некоммерческие операционные системы реального времени, то мы получим вполне солидное число, отражающее заинтересованность современного общества в подобных системах. Однако сама специфика применения операционных систем реального времени требует гарантий надежности, причем гарантий в том числе и юридических – этим, видимо, можно объяснить тот факт, что среди некоммерческих систем реального времени нет сколько-нибудь популярных.
На рис. 5 дано компактное
представление классификации систем по трём различным признакам: класс (отсутствие РВ, мягкое РВ, жесткое РВ), сложность (одноадресное пространство, многоадресное/защищенное), стандартизация (частное решение, подмножество POSIX, только POSIX, UNIX и POSIX).
1.3.1. Классификация по структурным характеристикам.
В мире операционных систем реального времени, как впрочем и в любой другой динамично развивающейся отрасли, в которой ещё нет установившейся достаточно строгой теории, существует несколько разнообразных подходов к построению подобных систем.
1.3.1.1. Исполнительные системы реального времени.
Признаки систем этого типа – различные платформы для систем разработки и исполнения. Приложение реального времени разрабатывается на host-компьютере (компьютере системы разработки), затем компонуется с ядром и загружается в целевую систему для исполнения. Как правило, приложение реального времени – это одна задача и параллелизм здесь достигается с помощью нитей (threads).
Системы этого типа обладают рядом достоинств, среди которых главное – скорость и реактивность системы. Главная причина высокой реактивности систем этого типа – наличие только нитей(потоков) и, следовательно, маленькое время переключения контекста между ними ( в отличие от процессов).
С этим главным достоинством связан и ряд недостатков: зависание всей системы при зависании нити, проблемы с динамической подгрузкой новых приложений.
Кроме того, системы разработки для продуктов этого класса традиционно дороги (порядка $20000). Хотя, надо отметить, что качество и функциональность систем разработки в этом классе традиционно хороши, так как они были изначально кроссовыми.
Наиболее ярким представителем систем этого класса является операционная система VxWorks. Область применения – компактные системы реального времени с хорошими временами реакций.
§
1.1.1. Ограниченное время ответа.
По сути, система реального времени – это аппаратно-программный комплекс, реагирующий в предсказуемые времена на непредсказуемый поток внешних событий. Это означает, что:
· Она должна успеть отреагировать на событие, произошедшее на объекте, в течение времени, критического для этого события (meet deadline). Величина критического времени для каждого события определяется объектом и самим событием, и, естественно, может быть разной, но время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие реакции в предсказанное время считается для СРВ ошибкой.
· Система должна успевать реагировать на одновременно происходящие события. Даже если два или больше внешних событий происходят одновременно, система должна успеть среагировать на каждое из них в течение интервалов времени, критического для этих событий.
По последствиям выхода за пределы интервала СРВ делятся на мягкие и жёсткие.
Системы жесткого реального времени не допускают никаких задержек реакции системы ни при каких условиях, так как:
· результаты могут оказаться бесполезны в случае опоздания;
· может произойти катастрофа в случае задержки реакции;
· стоимость опоздания может оказаться бесконечно велика.
Системы мягкого реального времени характеризуются тем, что задержка реакции не критична, хотя и может привести к увеличинию стоимости результатов и снижению производительности системы в целом.
Основное отличие между системами жесткого и мягкого реального времени можно выразить так: система жесткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени – не должна опаздывать с реакцией на событие.
В таблице 3 приведены времена отклика для нескольких ОС РВ.
1.1.2. Статическая основа проектирования.
Кроме того, применение операционных систем реального времени всегда конкретно. Если ОС общего назначения обычно воспринимается пользователями (не разработчиками) как уже готовый набор приложений, то операционная система реального времени служит только инструментом для создания конкретного аппаратно-программного комплекса реального времени.
Для большинства СРВ предполагается, что основная часть обрабатываемых данных априорно известна. Поэтому наиболее широкий класс пользователей операционных систем реального времени – разработчики комплексов реального времени, люди проектирующие системы управления и сбора данных. Проектируя и разрабатывая конкретную систему реального времени, программист всегда знает точно какие события могут произойти на объекте, знает критические сроки обслуживания каждого из этих событий.
1.1.3. Портирование.
Управление прокатными станами, роботами, движение на автомагистралях, контроль за состоянием окружающей среды, управление атомными и космическими станциями и многое другое – область задач реального времени. Для различных областей применения ОС РВ существуют разные аппаратные платформы и для каждой необходимо портирование, т.е процесс «состыковки» программной части ОС и её аппаратного обеспечения.
При выборе аппаратной платформы для систем реального времени основополагающими моментами являются жесткие требования к временным характеристикам и гибкости системы. Требования к аппаратному обеспечению в настоящее время довольно чётко определены. Большинство проектов реального времени осуществляется в рамках архитектурных решений магистрально-модульных систем (ММС).
Однако, как бы ни была важна сама ОС РВ, сейчас в условиях доступности совместимых аппаратных средств основное внимание уделяется разработке и отладке прикладного программного обеспечения, чья доля в затратах на разработку систем реального времени составляет до 70%.
По среде в которой функционируют системы их можно разделить на классы: программирование на уровне микроконтроллеров, минимальное ядро СРВ, ядро СРВ и инструментальная среда, ОС с полным сервисом.
1.1.4. Встроенные системы реального времени.
Следующее отличие – применение операционной системы реального времени всегда связано с аппаратурой, с объектом, с событиями, происходящими на объекте. Система реального времени, как аппаратно-программный комплекс, включает в себя датчики, регистрирующие события на объекте, модули ввода-вывода, преобразующие показания датчиков в цифровой вид, пригодный для обработки этих показаний на компьютере, и, наконец, компьютер с программой, реагирующей на события, происходящие на объекте. Операционная система реального времени ориентирована на обработку внешних событий. Именно это приводит к коренным отличиям (по сравнению с ОС общего назначения) в структуре системы, в функциях ядра, в построении системы ввода-вывода. Операционная система реального времени может быть похожа по пользовательскому интерфейсу на ОС общего назначения (к этому, кстати, стремятся почти все производители операционных системах реального времени), однако устроена она совершенно иначе – более подробно об этом в пункте 2.2.
В последнее время высокопроизводительные микропроцессоры, а с ними и операционные системы реального времени, все чаще используются в так называемых “глубоко встроенных” (deeply embedded) применениях. К таким компьютерным системам предъявляются два основных требования: малые габариты и низкая стоимость. Поэтому глубоко встроенные микропроцессорные системы ставят две проблемы на пути применения серийных ОС РВ: небольшие объемы используемой памяти и отсутствие “лишних” интерфейсов, по которым можно было бы связать целевую и инструментальную машины на этапе разработки встроенного ПО.
По структурным характеристикам программно-аппаратные комплексы можно разделить на классы: исполнительные системы реального времени, ядра реального времени, Unix’ы реального времени.
1.1.5. Вывод.
Были рассмотрены центральные отличия систем реального времени от систем разделения времени. В основе этих отличий лежит главное требование к подобным системам – предсказуемость. Пользователи СРВ должны быть заранее уверены в том, что отклик на внешнее воздействие будет получен в обозначенный интервал времени. Это влечет за собой необходимость представлять себе какие объёмы данных несут в себе внешние воздействия и какими аппаратными возможностями по обработке этих данных располагает система. Вполне логично, что системы реального времени не ориентированы на взаимодействие с человеком, а предполагают самостоятельную работу в критичных точках инженерных систем.
