Лекции - Системы реального времени

Подождите немного. Документ загружается.

согласовывать между собой свою работу для повышения эффективности.

Если исключить эти сервисы из состава ядра ОСРВ, то задачи начнут

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

соседних задач.

5. Контроль уст ройства ввода/вывода. С ервисы этой группы обеспечивают

работу единого программного интерфейса, взаимодействующего со всем

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

большинства встро енных систем.

В дополнение к сервисам ядра, многие ОСРВ предлагают линейки

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

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

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

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

ОСРВ, они, тем не менее, основываются на его сервисах. Каждый из таких

компонентов включается во встроенную систему, только если её сервисы

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

свести расход памяти к минимуму.

8 МЕЖДУНАРОДНЫЕ СТАНДАРТЫ СРВ И ИХ РОЛЬ

На развитие СРВ влияют множество международных стандартов, как в

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

1. POSIX – переносимый интерфейс ОС на уровне исходных текстов. Один из

немногих стандартов, формально определяющих некоторые классические

требования к ОСРВ. Основная спецификация разработана как IEEE 1003.1 и

одобрена как международный стандарт ISO/IEC 9945-1:1990. В стандарте

POSIX 1003.4 изложены требования к вычислительно-управляющим

системам, в которых реализовано программное обеспечение РВ. Стандарт

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

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

2. UNIX – стандарт de-facto для ОС общего назначения. Однако ОС UNIX,

разработанная как система общего назначения, не имеет эффективного

механизма приоритетности задач и поэтому мало пригодна для задач

реального времени. В то же время многи е ОС реального времени можно

охарактеризовать как UNIX-подобные.

3. VMEbus – это стандартная, наращиваемая, аппаратно- и программно-

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

устройств (процессоров, ЦАП, АЦП, сетевых и графических контроллеров

и т. п.), принятая в качестве стандарта IEC, ANSI, IEEE и другими

международными и национальными организациями по стандартизации.

Около 50% всей техники для встроенных систем управления реального

времени выполняется на базе стандартов VME/VXIbus.

4. Протокол TIPC – ст андарт для обеспечения взаимодействия между ОС в

сетевых среда х, те лекомм уни кационных кл аст ера х и других

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

AdvancedTCA-архитектурой. Протокол TIPC реализован в некоторых ОСРВ,

например, VxWorks и QNX Neutrino;

5. Спецификация MPI (Message Passing Interface) для языков

программирования Cи и Фортран. Первый вариант спецификации MPI был

разработан в 1994 г. Спецификация MPI включает около 200 функций и

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

из наиболее распро странённых реа лизаций MPI является библиотека

MPICH. MPI/Pro оптимизирует время работы параллельных приложений и

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

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

Наиболее часто упоминаемыми зарубежными документ ами,

относящимися к современным требованиям к ОСРВ, являются:

1. Стандарт DO-178. Определяет процедуры сертификации ПО на основе

требуемого уровня качества ПО. Текущая версия DO-178B принята в 1992 г.

Стандартом определено пять уровней серьёзности отказа (A, B, C, D, E). Для

каждого уровня определён набор требований к ПО, которые должны

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

отказов данного уровня серьёзности.

2. ARINC-653. Стандарт разработан компанией ARINC в 1997 г. и вводит

к онцепцию изолированных разделов на основе универсального

программного интерфейса APEX между ОСРВ и прикладным ПО. В

качестве одного из основных требований для ОСРВ в авиации вводит

архитектуру изолированных виртуальных машин.

3. CCITSE – Общие критерии для оценки безопасности информационных

технологий. Это набор требований и условий безопасности, одобренный

Агентством национальной безопасно сти и Национа льным институтом

стандартов и технологий США, а также соответ ствующими органами в

других странах. Первая версия требований опубликована в январе 1996 г.,

вторая - в апреле 1998 г. В 1999 г. CCITSE получил статус международного

стандарта ISO 15408.

4. MILS – делает возможной математическую верификацию программного

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

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

5. RSC – повторно используемые компоненты. Определяет критерии

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

сертификации.

Среди российских документов, определяющих требования к П О (в т.ч. к

ОСРВ), назыаются следующие:

1. ГОСТ Р ИСО/МЭК 51904-2002 – Программное обеспечение встроенных

систем. Общие требования к разработке и документированию;

2. ГОСТ Р ИСО/МЭК 12207-99 – Информационная технология. Процессы

жизненного цикла программных средств;

3. ГОСТ Р ИСО/МЭК 15408-2002 – М етоды и средства обесп ече ния

безопасности. Кри терии оценки безопасности информационных технологий.

10 ОСНОВЫ UML

Объектно-ориентированные концепции особенно важны для анализа и

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

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

Унифицированный язык моделирования UML предлагает

стандартизованную нотацию для описания объектно-ориентированных

моделей. Объединение концепций объектно-ориентированного проектирования

с концепциями параллельного выполнения необходимо для успешного создания

распределенных приложений, работающих в реа льн ом масштабе времени.

Объектно-ориентированные методы основаны на концепциях сокрытия

информации, классов и наследования. Сокрытие информации позволяет

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

сопровождению системы. Наследование – это систематиче ский спо соб

адаптации классов.

Язык UML, пришедший на смену многочисленным системам нотации и

методикам проектирования предложил нотацию для опис ания объектно-

ориентированных моделей, которая стала промышленным стандартом. Однако

для эффективного применения нотации UML необходимо сочетать ее с каким-

либо методом объектно-ориентированного анализа и проектирования.

В н о т а ц и и U M L п од д е р ж и в а ю т с я де вя т ь в и д о в д и а г р а м м , н о в

проектировании СРВ участвуют только шесть:

• диаграммы вариантов использования – проектируемая программная система

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

взаимодействуют внешние сущности – актеры (любой объект, субъект или

система, взаимодействующая с моделируемой бизнес-системой извне);

служит для опис ания сервисов, которые система предоставляет актеру; при

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

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

использования;

• диаграммы классов – предназначена для представления статической

структуры модели системы в терминологии классов объектно-

ориентированного программирования; может содержать интерфейсы, пакеты,

отношения и даже отдельные экземпляры классификаторов, такие как

объекты и связи;

• диаграммы кооперации – спецификация множества объектов отдельных

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

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

• диаграммы последовательности – показывают взаимодействие элементов

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

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

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

• диаграммы со стояний – опис ание возможныой последовательно сти

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

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

динамическое поведение сущностей, на основе спецификации их реакции на

во сприятие некоторых конкретных событий;

• диаграммы развертывания – применяет ся для представления общей

конфигурации и топологии распределенной программной системы и

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

системы; показывает наличие физических соединений - маршрутов передачи

информации между аппаратными устройствами, задействованными в

реализации системы.

14 СТАНДАРТ CORBA

CORBA (единая архитектура брокера объектных запросов) – это стандарт

открытых систем, разработанный группой Object Management Group (OMG),

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

платформе.

Брокер объектных запросов (ORB) выполняет функции ПО

промежуточного слоя, поддерживающего отношения вида клиент-сервер между

распределенными объектами. Серверные объекты предоставляют сервисы,

которые клиенты могут запрашивать с помощью ORB. В общем случае клиенты

и серверы - э то вс его лишь роли объектов. Таким образом, объект способен

выступать в роли клиента в отношениях с одним объектом и в роли сервера – в

отношениях с другим. С помощью ORB клиентский объект в состоянии

вызывать операции серверного объекта, не зная, где тот находится, на какой

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

коммуникационные протоколы нужны для связи с ним и на каком языке он

написан.

Клиент, имеющий ссылку на серверный объект, может вызывать любые

сервисы (операции интерфейса), поддерживаемые этим объектом, через

посредство ORB. ORB обладает следующими достоинствами:

прозрачностью местоположения – ORB определяет местоположение

объекта по ссылке на него;

• прозрачностью реализации – клиент не должен знать, как реализован

серверный объект, на каком языке он написан, на какой аппаратной и

программной платформе исполняется;

• прозрачностью состояния выполнения объекта – если серверный объект

неактивен, то ORB активизирует его п еред доставкой запроса;

• прозрачностью коммуникационного механизма - клиент не знает, какой

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

• Интерфейс серверного объекта описывается на языке определения

интерфейсов (Interface Definition Language – IDL), не зависящем от

конкретных языков программирования. Интерфейс определяется независимо

от реализации. Спецификации, записанные на IDL, затем переводятся на язык

реализации. Реализация объекта кодируется сразу на целевом языке. Группа

OMG разработала стандартные отображения IDL на различные языки

программирования, в том числе С, C++ и Java. Компиляторы IDL генерируют

клиентские заглушки и серверные каркасы, аналогичные описанным выше

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

и передает его от имени клиента. Серверный каркас получает запрос и

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

CORBA.

Программная заглушка выполняет маршалинг параметров примерно так

же, как при вызовах удаленных процедур. Высокоуровневые типы данных перед

отправкой необходимо упаковать в такие структуры, которые можно передать

по сети, например в поток байтов. Принимающий каркас должен распаковать

входящее сообщение и вызвать запрошенную операцию серверного объекта.

В случае статического вызова заглушки и каркасы заранее скомпонованы

с исполняемыми файлами. Статические интерфейсы определены в IDL-

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

заглушек, каркасов и за головочных файлов, как определено в правилах

отображения на конкретный язык.

Большую гибкость обеспечивает динамическо е связывание. В этом случае

клиентский объект во время выполнения решает, с каким серверным объектом

он будет общаться. С ервер регист рирует IDL-описания в репозит арии

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

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

представляет собой обобщенную заглушку, не зависящую от IDL-опис ани я

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

обращаться к объекту во время выполнения, ничего не зная о его интерфейсе на

стадии компиляции.

CORBA поддерживает также интерфейс динамиче ского каркаса на

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

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

не имеющих скомпилированных из IDL-опис аний каркасов. Это полезно для

общения с такими внешними объектами, как шлюзы или браузеры.

Брокер объектных запросов позволяет клиенту прозрачно вызывать

операцию серверного объекта, предоставляя службу имен. Когда создается

объект CORBA, ему присваивается уникальная объектная ссылка. Получить

ссылку можно с помощью просмотра каталога. Иными словами, служба имен

CORBA дает ссылку на поименованный объект, а клиент затем вызывает

операцию этого объекта.

Другой сервис, предоставляемый CORBA, – это трейдинг. Он позволяет

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

объектов (например, типа обслуживания) с характеристиками, посланными

клиентом.

Многие унаследованные приложения достаточно сложно интегрировать в

каркас, состоящий из распределенных объектов. Один из применяемых для этой

цели методов состоит в написании объектов-оберток (wrappers). Объект-обертка

– это объект распределенного приложения, который обрабатывает запросы

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

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

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

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

модифицировать, чтобы объекты-обертки могли получить доступ к нему.

Однако часто это неприемлемо, так как документации практически нет, а

разработчики уже недо ступны. По этому обертки обычно общаются с

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

последовательные или индексированные. Обертывающий объект должен читать

и модифицировать файлы, создаваемые унаследованным приложением. Если

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

обратиться с помощью оберток, скрывающих дета ли доступа. Например, в

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

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

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

экран или принтер.