
- •2. Ядра и операционные системы реального времени
- •2.1. Задачи, процессы, потоки
- •2.2. Основные свойства задач
- •2.3. Планирование задач
- •2.4. Синхронизация задач
- •2.5. Тестирование
- •2.6. Можно ли обойтись без ОС РВ?
- •3. Обзор некоторых операционных систем реального времени
- •3.1. Linux реального времени
- •3.2. Операционные системы реального времени и Windows
- •3.3. Операционная система QNX
- •3.4. Проект Neutrino
- •4.1. Организация промышленных систем
- •4.2. Аппаратная архитектура
- •4.3. Стандарты шин
- •4.4. Технологии VME и PCI
- •4.5. Мезонинные технологии
- •4.6. Полевые системы
- •4.7. Программное обеспечение промышленных систем
- •4.8. Управление производством
- •Часть 2. ПРОЕКТИРОВАНИЕ СРВ
- •5. UML проектирование систем реального времени
- •5.1. Объектно-ориентированные методы и UML
- •5.2. Метод и нотация
- •5.3. Системы и приложения реального времени
- •6. Обзор нотации UML
- •6.1. Диаграммы UML
- •6.2. Диаграммы прецедентов
- •6.3. Нотация UML для классов и объектов
- •6.4. Диаграммы классов
- •6.5. Диаграммы взаимодействия
- •6.6. Диаграммы состояний
- •6.7. Пакеты
- •6.8. Диаграммы параллельной кооперации
- •6.9. Диаграммы развертывания
- •6.10. Механизмы расширения UML
- •7.1. Среды для параллельной обработки
- •7.2. Поддержка исполнения в мультипрограммной и мультипроцессорной средах
- •7.3. Планирование задач
- •7.4. Вопросы ввода/вывода в операционной системе
- •7.6. Технология World Wide Web
- •7.7. Сервисы распределенных операционных систем
- •7.8. ПО промежуточного слоя
- •7.9. Стандарт CORBA
- •7.10. Другие компонентные технологии
- •7.11. Системы обработки транзакций
- •8. Разбиение на задачи
- •8.1. Вопросы разбиения на параллельные задачи
- •8.2. Категории критериев разбиения на задачи
- •8.3. Критерии выделения задач ввода/вывода
- •8.4. Критерии выделения внутренних задач
- •8.5. Критерии назначения приоритетов задачам
- •8.6. Критерии группировки задач
- •8.7. Пересмотр проекта путем инверсии задач
- •8.8. Разработка архитектуры задач
- •8.9. Коммуникации между задачами и синхронизация
- •8.10. Спецификация поведения задачи
- •9. Проектирование классов
- •9.1. Проектирование классов, скрывающих информацию
- •9.2. Проектирование операций классов
- •9.3. Классы абстрагирования данных
- •9.4. Классы интерфейса устройства
- •9.5. Классы, зависящие от состояния
- •9.6. Классы, скрывающие алгоритмы
- •9.7. Классы интерфейса пользователя
- •9.10. Внутренние программные классы
- •9.11. Применение наследования при проектировании
- •9.12. Примеры наследования
- •9.13. Спецификация интерфейса класса
- •10. Детальное проектирование ПО
- •10.1. Проектирование составных задач
- •10.2. Синхронизация доступа к классам
- •10.4. Логика упорядочения событий
- •11.1. Теория планирования в реальном времени
- •11.2. Развитие теории планирования в реальном времени
- •11.5. Пример анализа производительности с помощью анализа последовательности событий
- •11.6. Пример анализа производительности с применением теории планирования в реальном времени
- •11.8. Пересмотр проекта
- •11.9. Оценка и измерение параметров производительности
- •12. ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ
Какую работу нужно написать?
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
133 |
связанность. Компонент (процесс или поток) в одном узле посылает сообщение, не указывая явно имя получателя, а задавая выходной порт. Компонент-получатель забирает сообщения из своего входного порта. На стадии конфигурации системы выходной порт одного ком- понента подключается к входному порту другого компонента (это называется связыванием). Подобная организация повышает гибкость и имеет больше шансов на повторное использование, поскольку на этапе проектирования компонент не должен явно знать, с кем он бу- дет соединен. Такие решения принимаются позднее, поэтому экземп-
ляры одного и того же компонента могут исполняться в различных средах и приложениях. Механизм обмена сообщениями через порты реализован в нескольких операционных системах, в том числе V, Mach, CHORUS и Amoeba. В качестве примеров распределенных сред программирования, предоставляющих порты и средства гибкой кон- фигурации, можно назвать Conic и Regis.
7.7.6. Восстановление после ошибок. Предполагается, что при
условии нормальной работы сети сообщение будет доставлено на удаленный узел. Например, если произошла ошибка четности, то се- тевое коммуникационное ПО (мы включаем его в состав распреде- ленной операционной системы) передаст сообщение повторно. Одна- ко если удаленный узел не отвечает в течение заданного времени – из-за разрыва соединения или потому, что он вышел из строя, – пере- дача будет прекращена по причине тайм-аута. В таком случае ло- кальное ядро получит отрицательное подтверждение от коммуни- кационного ПО, свидетельствующее о том, что удаленный узел не получил сообщения. При этом локальное ядро известит о неудаче за- дачу-отправителя. Если сообщение не доставлено на удаленный узел, то сам отправитель должен решить, что делать дальше, поскольку та- кое решение зависит от логики приложения.
7.8. ПО промежуточного слоя
Распределенным системам часто приходится работать в гетеро- генных средах, когда в разных узлах установлено различное оборудо- вание и операционные системы. Например, когда клиенту на ПК под управлением Windows нужно общаться с сервером под управлением системы UNIX. ПО промежуточного слоя – это слой программного обеспечения, располагаемый поверх ОС с целью создания од- нородной платформы, на которой могут функционировать распреде-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
134 |
ленные приложения. Одной из ранних форм ПО промежуточного слоя был механизм вызова удаленных процедур RPC. Другие приме-
ры – это система DCE (Distributed Computing Environment – среда распределенных вычислений), основанная на RPC, технология вызова удаленных методов (RMI) в языке Java, а также технологии СОМ и
CORBA.
Предоставляя единообразный метод взаимодействия объектов, технологии ПО промежуточного слоя, такие как CORBA, СОМ и Java Beans, поощряют повторное использование компонентов, поэтому их часто называют компонентными технологиями.
7.8.1.Платформы для распределенных вычислений. Изначально
платформы для распределенных вычислений базировались на модели клиент-сервер. Но в последнее время все большую популярность за- воевывает объектная модель [14]. Коммуникации в модели клиент- сервер часто основаны на вызове удаленных процедур. При таком
подходе процедуры находятся в адресном пространстве сервера и дистанционно запрашиваются клиентами. Сервер получает от клиен- та запрос, активизирует нужную процедуру и возвращает ответ.
В объектной модели объекты получают глобальные имена и мо- гут вызываться непосредственно на сервере. Существует два подхода
краспределенным вычислениям: модель распределенных объектов и модель мобильного кода [14]. В первом случае объекты размещаются на сервере и вызываются дистанционно, как в Java RMI и CORBA. Во втором случае требуемые объекты мигрируют с сервера на клиент – ярким примером такого метода служат Java-апплеты.
7.8.2.Вызовы удаленных процедур. Некоторые распределенные системы поддерживают механизм вызова удаленных процедур (RPC). Клиент в одном узле запрашивает удаленную процедуру сервера, на- ходящегося в другом узле. Вызов удаленной процедуры аналогичен вызову локальной процедуры, поэтому тот факт, что сервер находит- ся далеко, скрыт от клиента. Процедура, необходимая клиенту, часто называется клиентской заглушкой (Client Stub). Она принимает запрос и произвольные параметры, упаковывает их в сообщение (данный процесс называется маршалингом) и отправляет сообщение серверу.
Удаленная серверная заглушка (Server Stub) распаковывает со- общение (это действие носит имя демаршалинга) и вызывает нужную процедуру, передавая ей параметры. Когда серверная процедура за- канчивает обработку запроса, она возвращает результаты серверной
www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
135 |
заглушке, которая упаковывает их в ответное сообщение и отправля- ет клиентской заглушке. Клиентская заглушка извлекает результаты из сообщения и возвращает их клиенту в виде выходных параметров.
Рис. 7.15. Вызов процедур: а – локальной; б – удаленной
Таким образом, роль клиентской и серверной заглушек сводится к тому, чтобы представить вызовы удаленных процедур так, как если бы они были локальными. На рис.7.15а изображен объект, обращаю- щийся к локальной процедуре другого объекта. На рис.7.15б пред- ставлено распределенное решение той же задачи, когда объект на клиентском узле вызывает удаленную процедуру, принадлежащую объекту на удаленном серверном узле. Локально вызывается клиент- ская заглушка, которая упаковывает имя и параметры процедуры в сообщение, отправляемое по сети. Интерфейсный уровень удаленно- го узла получает сообщение и передает его серверной заглушке, ко-
www.pdffactory.com

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
136 |
торая распаковывает сообщение и вызывает указанную процедуру серверного объекта. После завершения процедуры серверная заглуш- ка упаковывает ответ и посылает его по сети. Затем клиентская за- глушка распаковывает сообщение и передает его клиентскому объек- ту.
Рис. 7.16. Вызов удаленных методов (RMI)
7.8.3. Вызов удаленных методов в языке Java. Среда программи-
рования на языке Java (она называется Java Development Kit – JDK) поддерживает технологию ПО промежуточного слоя RMI (Remote Method Invocation – вызов удаленных методов), которая позволяет распределенным Java-объектам общаться друг с другом. В этом слу- чае вместо отправки сообщения некоторой процедуре (как в RPC)
клиентский объект посылает сообщение другому объекту и вызывает метод этого объекта (процедуру или функцию).
www.pdffactory.com