Раздел Б
Разработка информационно- управляющих систем
100
Раздел Б. Разработка информационно-управляющих систем
5. Системы реального времени
С
истемы реального времени — это автоматизирован‑
ные системы, работа которых определяется внешни‑
ми по отношению к системе, реальными временны́ми интервалами. Практически все ИУС являются системами именно ре‑
ального времени. Аспекты, связанные с реальным временем, прояв‑
ляются прежде всего там, где реализуется автоматическое управление объектом — на нижних трех уровнях модели (см. рис. 1). На уровне управления вводом‑выводом и часто на уровне диспетчерского управления приходится использовать специализированное систем‑
ное программное обеспечение — операционные системы реального времени.
5 . 1 . О п е р а ц и о н н ы е с и с т е м ы р е а л ь н о г о в р е м е н и
Работа операционных систем реального времени (ОС РВ) опреде‑
ляется внешними процессами, происходящими в управляемом объек‑
те. ОС РВ обязана реагировать на события, которые могут возникать в самом управляемом объекте или быть результатом внешнего воз‑
действия. Время ответной реакции ОС РВ строго регламентировано и определяется динамикой управляемого объекта.
С точки зрения ОС внешнее событие представляется прерыванием.
Генерирование прерывания вызывает следующий (существенно упро‑
щенный) поток событий (рис. 14):
• генерируется прерывание;
• через некоторое время T
il
, обработчик прерывания получает управление;
• обработчик в течение интервала времени T
int
выполняет критиче‑
скую по времени работу (чтение‑запись аппаратных регистров, сохранение полученной информации в памяти);
• ставится в очередь процесс, который будет осуществлять окон‑
чательную обработку прерывания;
101 5. Системы реального времени
• по завершении работы обработчика, через определенное время
Tiretвыполняется
выход из прерывания;
• если обрабатывающий прерывание процесс является самым при‑
оритетным, через некоторое время
Tslдиспетчер передает ему управление.
• по завершении этого процесса, обработка прерывания закан‑
чивается.
Возникновение прерывание
Обработчик прерывания получает управление
Обработчик завершает работу или вызывает внешнюю программу
Прерванный процесс продолжает работу или внешняя программа получает управление
Til Tint Tiret +
TslРис. 14. Упрощенная схема потока событий, вызываемых прерыванием
В этой схеме только время обработки прерывания
Tint зависит от со‑
держания прерывания. Все остальные временны́е интервалы определя‑
ются прежде всего архитектурой операционной системы. Для характе‑
ристики потока событий, вызываемых прерыванием, определяют еще один временной интервал — время переключения контекста
Tcont, кото‑
рый означает время передачи управления между процессами. Таким об‑
разом, мы получаем следующие характерные временные интервалы, ко‑
торые определяют так называемую
реактивность операционной системы:
• Til — время задержки прерывания либо ожидания обработки пре‑
рывания (Interrupt Latency);
• Tint — время обработки прерывания (Interrupt Time);
• Tiret — время возврата из прерывания (Interrupt Termination time);
• Tsl— время задержки диспетчеризации (Sheduler Latency);
• Tcont — время переключения контекста.
102
Раздел Б. Разработка информационно-управляющих систем
Обычно соотношение временных интервалов выглядит следующим образом:
Tsl >
Til >
TiretВремя переключения контекста —
Tcont 1.2
ТslПри проектировании ОС РВ ставится задача максимального снижения параметров реактивности, что отличает ее от ОС об‑
щего назначения. Однако главным требованием к ОС РВ явля‑
ется
обеспечение ее предсказуемого поведения. Это означает, что в любой ситуации можно рассчитать максимальную величину временного ин‑
тервала задержки прерывания. Если рассчитанная величина не устра‑
ивает, переходят на аппаратуру с более высоким быстродействием.
Если временные интервалы имеют очень малые значения, приходится часть операций реализовывать аппаратно, т. к. в этом случае исполь‑
зование чисто программных решений не представляется возможным.
Отметим, что
ядро ОС РВ устроено сложнее, чем ядро ОС обще‑
го назначения, и алгоритмы его работы являются более трудоемки‑
ми. Таким образом, ОС РВ не может обеспечить меньшие по сравне‑
нию с универсальной ОС значения временных интервалов задержки прерывания. Задача ОС РВ состоит в том, чтобы обеспечить стабиль‑
ность этих значений.
Для обеспечения предсказуемого поведения ОС прихо‑
дится принимать целый ряд мер. Важнейшая и простейшая из них состоит во введении достаточно
большого числа прио-ритетов.
Если каждый процесс и каждый поток будет выпол‑
няться со своим значением приоритета, то максимальная временная задержка есть результат суммы временной задержки, вносимой обра‑
ботчиком рассматриваемого прерывания, с временными задержками, вносимыми всеми более приоритетными процессами. Если же какие‑
либо процессы либо потоки будут выполняться с одним и тем же зна‑
чением приоритета, ситуация становится непредсказуемой и заранее нельзя сказать, какой из них получит управление.
В операционной системе может наблюдаться инверсия приори‑
тетов, т. е. явление, когда менее приоритетный процесс мешает вы‑
полнению более приоритетного процесса. Приведем пример такой ситуации.
Один из процессов обращается к системному вызову, в результате которого начинает выполняться функция ядра, для которой заблоки‑
рованы прерывания. В это время возникает прерывание с более высо‑
ким приоритетом, но обработчик не может начать его обработку из‑за блокировки. В результате этого более приоритетный процесс вынуж‑
103 5. Системы реального времени ден ожидать окончания менее приоритетного, т. е. возникает инвер‑
сия приоритетов.
Для универсальной ОС такая ситуация не страшна. Более того, по‑
добное синхронное выполнение системных вызовов с блокировкой прерываний позволяет упростить код ядра и увеличить скорость его работы. Например, для ОС Windows некоторые функции графическо‑
го интерфейса выполняются именно в таком синхронном режиме. Для
ОС РВ же такое недопустимо — все системные вызовы должны иметь возможность прерываться.
Ситуация с блокировкой прерываний возникает также при исполь‑
зовании примитивов синхронизации процессов и потоков. Эти систем‑
ные вызовы работают с объектами ядра, код которых, для обеспечения взаимоисключения, должен выполняться атомарно, т. е. без возмож‑
ности прерывания.
Для исключения блокировки прерываний и инверсии приоритетов приходится применять ряд мер:
• необходимо обеспечить прерываемость любого кода ядра, в т. ч. кода объектов синхронизации;
• при выполнении кода объектов синхронизации, объекты син‑
хронизации переопределяются, т. е. варьируются их приорите‑
ты во избежание инверсии приоритетов [46].
Приведем пример предотвращения инверсии в ОС QNX 6.2.1 [46].
Три базовых объекта синхронизации ОС QNX — мьютекс, условная переменная и семафор — реализуются на уровне микроядра системы и создаются путем вызова системной функции:
SyncTypeCreate (unsigned type, sync_t* sync, const struct _sync_attr_t* attr);
Здесь type может принимать значения:
_NTO_SYNC_MUTEX_FREE — для создания мьютекса;
_NTO_SYNC_SEM — для создания семафора;
_NTO_SYNC_COND — для создания условной переменной.
Типы атрибутов этих объектов являются псевдонимами одного‑
единственного типа sync_attr_t, содержащего поле protocol, значение которого определяет, каким способом ОС будет варьировать приори‑
теты. По умолчанию (например, когда вместо attr передается NULL) поле protocol принимает значение PTHREAD_PRIO_INHERIT. Это означает, что ОС будет использовать протокол наследования приори‑
тетов для предотвращения инверсии. Таким образом, все примитивы синхронизации QNX могут учитывать эффект инверсии приоритетов.
104
Раздел Б. Разработка информационно-управляющих систем
В любой развитой ОС доступ к периферийным устройствам осу‑
ществляется только через драйверы. Эти драйверы обязаны входить в состав ядра ОС, иначе они не смогут функционировать. Для ИУС характерно большое количество каналов ввода‑вывода, для каждой группы которых необходим драйвер. В итоге получаем большое коли‑
чество драйверов, разрабатываемых производителями устройств, ко‑
торые, работая в монолитном ядре, имеют доступ ко всему адресному пространству ядра. Любой плохо написанный драйвер может, таким образом, вызвать крах всего ядра. Эта проблема успешно решается при использовании микроядерной архитектуры ядра, когда каждый драйвер выполняется как отдельный процесс ядра, в собственном изолирован‑
ном адресном пространстве. Микроядерной называется архитектура ядра, при которой оно выполняется не в виде одного (возможно мно‑
гопотокового) процесса монолитного ядра, а в виде некоторого множе‑
ства процессов (каждый в своем виртуальном адресном пространстве, изолированном от доступа других процессов). Среди этих процессов ядра приходится выделять управляющий процесс — микроядро, ко‑
торый выполняется в привилегированном режиме и может получить доступ к адресному пространству любого процесса, реализуя функ‑
ции диспетчирования, обработки прерываний, взаимодействия про‑
цессов, сетевого взаимодействия.
Кроме того, микроядерная архитектура дает исключительный уро‑
вень масштабируемости — для добавления в ядро какой‑либо функ‑
циональной возможности достаточно запустить соответствующий процесс. По этой причине в ОС РВ микроядерная архитектура исполь‑
зуется очень широко. Например, широко распространенная в мире ОС
QNX [47, 50] имеет микроядерную структуру ядра.
Обратная сторона микроядерной архитектуры более слож‑
ное устройство, чем у монолитного ядра. Ядро с микроядер‑
ной архитектурой имеет бóльшие размеры, чем монолитное, и работает медленнее. Для элементарной передачи инфор‑
мации другой, подсистеме ядра вместо простого изменения значения переменной (в монолитном ядре) требуется использования средств межпроцессного взаимодействия (IPC). Для QNX, например, базо‑
вым средством IPC является передача синхронных сообщений, что непосредственно реализуется микроядром. В связи с этим микроя‑
дерная архитектура ядра в универсальных ОС практически не при‑
меняется. Фирма Microsoft в свое время при разработке Windows NT
105 5. Системы реального времени пыталась использовать микроядерную архитектуру, но в итоге от нее отказалась из‑за медленной работы. Микроядерое ядро GNU/HURD так и не было доведено до стабильной версии.
Управление памятью в ОС РВ отличается тем, что исклю‑
чается возможность применять выгрузку данных виртуаль‑
ной памяти в область свопинга (при страничном управления виртуальной памятью) и исключается применение свопинга в чистом виде (когда процесс выгружается целиком). Эти механизмы никак не согласуются с требованиями реального времени.
Еще одна особенность ОС РВ связана с их применением в промыш‑
ленных системах. Для таких ИУС время их жизненного цикла будет определяться длительностью эксплуатации управляемого объекта, со‑
ставляющей десятки лет и более. И несмотря на все принятые меры повышения длительности наработки на отказ, контроллеры ИУС бу‑
дут постепенно выходить из строя и требовать замены. Однако новые контроллеры того же типа могут быть недоступны, т. к. они уже сня‑
ты с производства. По этой причине, в частности, используется ин‑
терпретация TIC‑кода в случае применения языков программирова‑
ния стандарта IEC 61131 для целевой системы (несмотря на очевидную потерю производительности).
Аналогичная ситуация имеет место с серверами и рабочими станци‑
ями диспетчерского уровня. Они постепенно выходят из строя, и мы вынуждены заменять их устройствами другого типа, с другой систе‑
мой команд и другой операционной системой.
При отсутствии совместимости ОС по программному интерфейсу возникает
необходимость полного перепроектирования системы, что крайне затратно, занимает большое время, требует полного цикла ис‑
пытаний системы и последующей сертификации. Если новая и старая
ОС являются совместимыми, то достаточно сначала перетранслиро‑
вать нашу систему в новую ОС и затем ее собрать. После минималь‑
ного цикла испытаний она может быть введена в эксплуатацию.
Таким образом, для промышленных систем совместимость API и со‑
ответствие их стандартам открытых систем является жизненным важ‑
ным и поэтому большинство ОС РВ являются POSIX‑совместимыми.
В ИУС используется большое количество разнообразных устройств с ОС РВ, как это было показано на примере многоуровневой модели системы. Они выполняют различные функции и характеризуются на‑
личием различных ресурсов. Полностью же POSIX‑совместимые опе‑
106
Раздел Б. Разработка информационно-управляющих систем рационные системы имеют заслуженную репутацию ресурсоемких.
На многих контроллерах таких ресурсов нет. В этой связи приходит‑
ся урезать возможности ОС. Выделяют профили прикладных контек‑
стов реального времени (ISO/IEC ISP 15287‑2), под которыми пони‑
маются согласованные подмножества стандартов POSIX.
Минимальная система — встроенная система без виртуаль‑
ной памяти, файловой системы и терминала. Поддерживает один многопотоковый процесс.
Контроллер реального времени — минимальная система, допол‑
ненная файловой системой и терминалом.
Специализированная система — встроенная система с нескольки‑
ми, возможно многопотоковыми, процессами и без файловой системы.
Сформулируем основные требования к операционным системам реального времени.
1.
Требуется обеспечить предсказуемый характер поведения си‑
стемы и исключить инверсию приоритетов. Для этого ОС РВ долж‑
на обладать:
• развитой системой приоритетов;
• наследованием приоритетов в примитивах синхронизации процессов;
• исключением свопинга.
2.
Часто требуется размещение всей ОС в ПЗУ.
3.
Широко используется микроядерная архитектура, позволяющая обеспечить масштабируемость и изоляцию драйверов.
Выбор ОС для решения задач автоматизации определяется многи‑
ми параметрами и требованиями к ОС. Помимо указанных выше учи‑
тываются требуемые характеристики системы или изделия:
• архитектурные принципы (тип ядра и планировщика, модель многозадачности и т. д.);
• временные характеристики (время реакции на прерывание, время переключения контекста, время перепланирования и т. п.);
• поддержка реального времени;
• показатели надежности (например, среднее время восстанов‑
ления после отказа);
• метрики производительности (например, пропускная способ‑
ность файловой системы на данном носителе);
• необходимые технологии;
107 5. Системы реального времени
• готовые наработки и опыт компании‑разработчика;
• выбранное оборудование;
• целевой рынок системы либо изделия;
• экономические ограничения проекта.
5 . 2 . Х а р а к т е р и с т и к и и п р и м е р ы и с п о л ь з о в а н и я с и с т е м р е а л ь н о г о в р е м е н иВ табл. 5 [47–50] приведены характеристики наиболее популяр‑
ных операционных систем жесткого реального времени QNX Neutrino
(QNX 6) и
VxWorks, по которым можно определиться с ОС для соб‑
ственной задачи автоматизации.
Таблица 5 Сравнительные характеристики встраиваемых операционных систем, поддерживающие стандарт POSIX 1003.1Характеристики
QNX Neutrino
Wind River VxWorks
Разработчик
Канадская компания
QNX Software Systems
(QSS)
Американская компа‑
ния (США) Wind River
Первый выпуск
2001 1987
Тип ядра
Микроядро и взаимо‑
действующие процессы
Микроядро
Защита памяти
Да
Настраиваемая
Реальное время
Жесткое
Жесткое
Время отклика
Единицы микросекунд Единицы микросекунд
Количество
уровней приоритета256 256
Дисциплины планиро‑
вания
FIFO, карусельная, спорадическая
Карусельная
Поддержка квотирова‑
ния ресурсов процессо‑
ра (ARINC 653)
Да
Да
Требуемый объем ПЗУ Единицы мегабайтов
Сотни килобайтов
Возможность динами‑
ческого восстановления при отказе
Любые системные и пользовательские процессы
Только пользователь‑
ские процессы
108
Раздел Б. Разработка информационно-управляющих систем
Характеристики
QNX Neutrino
Wind River VxWorks
Поддерживаемые технологии (включая доступные
через партнерскую сеть)
Поддержка многопро‑
цессорности
SMP, AMP
SMP, AMP
Стек IPv4
Да
Да
Cntr IPv6
Да
Да
Средства графического интерфейса
Штатная графическая оболочка, Qt, Adobe
Flash Lite
Штатная графическая библиотека, Qt, пакет
Tilcon Graphics Suite
Поддержка мультимедиа Да
Да
Функции управления энергопотреблением
Да
Да
Поддержка реляцион‑
ных баз данных
Да
Да
Поддержка OPC либо
OPC
‑шлюзов
Да
Да
Поддержка эмуляторов
ПЛК (Soft‑PLC, МЭК
61131
‑3)
Да
Да
Поддержка промыш‑
ленных шин
Да
Да
Инструментарий разработчика
Интерфейс прикладно‑
го программирования
(API)
POSIX
POSIX
Интегрированная среда разработки
Штатная IDE на базе
Eclipse
Штатная IDE на базе
Eclipse
Поддерживаемые язы‑
ки программирования или моделирования
C/C++, Java, UML,
Phyton, Ruby, Ada, For
‑
tran
C/C++, Java, UML,
Ada, Fortran
Поддержка JTAG‑
отладчиков
Да
Да
Поддерживаемые ин‑
струментальные ОС
Windows, Linux
Windows, Linux, Solaris
Поддерживаемое оборудование
Поддерживаемые архи‑
тектуры процессоров
Х86, ARM, MIPS,
PowerPC
X86, ARM, MIPS, Pow
‑
erPC, GoldFire
Продолжение табл. 5
109 5. Системы реального времени
Характеристики
QNX Neutrino
Wind River VxWorks
Типовое применение и сертификация
Типовое применение
Ответственные систе‑
мы, авиация или кос‑
монавтика, промыш‑
ленные контроллеры, военные приложения, коммуникационные устройства, медицин‑
ские приборы
Ответственные систе‑
мы, авиация или кос‑
монавтика, промыш‑
ленные контроллеры, военные приложения, коммуникационные устройства, медицин‑
ские приборы
Сертификаты и серти‑
фикационные пакеты
МЭК 15408 («Общие критерии») EAL 4+,
МЭК 61508 SIL 3
МЭК 15408 («Об‑
щие критерии») EAL
4/4+/6+, DO
‑178B уровень А, МЭК
61508 SIL 3, CENELEC
EN 50128, FDA 510 (k)
Лицензирование
Доступность исходно‑
го текста
Полностью
Полностью
Лицензионные отчис‑
ления
Да
Да
Журнал Dedicated Systems, проводивший в 2011 г. срав‑
нительное тестирование QNX RTOS 6.1 и VxWorks AE 1.1 на x86 платформе, отметил следующие существенные отли‑
чия этих систем:
• задержка при реакции на прерывание у QNX значительно выше, чем у VxWorks;
• время переключения контекста у QNX в 1,5 раза меньше, чем у VxWork;
• по стабильности временных показателей QNX опережает
VxWorks при увеличении числа потоков с 2 до 128 ед., время переключения контекста у QNX выросло в 1, 65 раз, тогда как у VxWorks — в 2,24 раза.
По мнению журнала Dedicated Systems, ОС РВ QNX является совер‑
шенной с технической точки зрения, но по опыту применения в от‑
ветственных приложениях она проигрывает OC PB VxWorks. Автори‑
Окончание табл. 5
110
Раздел Б. Разработка информационно-управляющих систем тет VxWorks страдает из‑за проводимой компанией Wind River Systems стратегии более закрытых разработок в сравнении с QSS. Обе ОС оста‑
ются пока достаточно дорогими.
Отметим, что временны́е характеристики последних версий про‑
мышленных ОС практически элиминировали существовавшую грань между «жесткими» и «мягкими» ОС РВ. Сейчас OS‑9, кото‑
рая ранее рассматривалась как «мягкая» ОС, по временным параме‑
трам практически не уступает классическим «жестким» ОС — pSOS+ и VxWorks.
Наблюдается активный процесс слияния универсальных
OC и ОС реального времени. Появляются различные инстру‑
менты
поддержки режима реального времени, встраиваемые в привычные операционные системы. Этот класс продуктов сочетает в себе привычный пользовательский интерфейс, средства разработки программ и API‑интерфейс реального времени. Напри‑
мер, операционная система Linux изначально не проектировалась как система реального времени и не может быть ОС РВ по многим пара‑
метрам. Однако уже существует несколько дистрибутивов Linux, под‑
держивающих расширения реального времени, к ним относятся дис‑
трибутивы компаний IBM, RT Linux от Novell и Red Hat.
В
RT Linux [50] реализованы таймеры высокой точности: для представления системного времени теперь используется
64
‑битная величина, позволяющая хранить время с наносе‑
кундной точностью. Код управления таймерами и системным временем полностью переписан и теперь не допускается возникнове‑
ние задержек, превышающих несколько микросекунд. Другим важным расширением стало вытесняемое ядро: к существующим в основном ядре Linux‑моделям вытеснения было добавлено полное вытеснение, при котором большинство абсолютных блокировок внутри ядра заме‑
нено на семафоры [50]. Таким образом, RT Linux — это операционная система, в которой маленькое ядро реального времени сосуществует со стандартным POSIX‑ядром Linux. Функции ядра и обработчики пре‑
рываний, «обернутые» в обычные системные потоки, в данной версии
RT могут вытесняться другими более приоритетными потоками [50].
Функция наследования приоритетов в RT Linux позволяет решить проблему инверсии приоритетов.
Большое внимание в RT Linux уделено планированию в симметрич‑
ных многопроцессорных системах. Если задача предсказуемого плани‑
111 5. Системы реального времени рования на одиночном процессоре решается легко: достаточно толь‑
ко выбрать самый приоритетный процесс из очереди планировщика, то в многопроцессорных системах такая очередь существует уже для каждого процессора [50]. Ядро операционной системы должно регу‑
лярно «пересматривать» очереди, чтобы обеспечить первоочередное выполнение потоков с высоким приоритетом на любом из процессо‑
ров [50].
Изменения в операционной системе требуют также аппаратной под‑
держки. К примеру, многие современные серверы используют преры‑
вания по управлению системой (System Management Interrupt — SMI), связанные с ошибками оборудования и управлением питания. Эти прерывания обладают непредсказуемой латентностью и потому слож‑
но сочетаются с работой систем реального времени. Некоторые аппа‑
ратные платформы, такие как Blade‑серверы IBM, были специально модифицированы для работы с системами реального времени, и ос‑
новная часть SMI‑прерываний обрабатывается в BIOS и других аппа‑
ратных контроллерах в обход основной ОС.
Рассмотрим прикладной модуль, который использует ядро реаль‑
ного времени RT Linux в виде загружаемого модуля Linux:
#define MODULE
#include <Linux/module.h>
/*необходимо для задач реального времени*/
#include <Linux/rt_sched.h>
#include <Linux/rt_fifo.h>
RT_Task mytask;
В заголовке модуля определяется структура RT_TASK, которая со‑
держит указатели на структуры данных модуля, а также на управля‑
ющую информацию. В нашем случае, для связи между процессами, используются очереди сообщений FIFO. Модуль реального времени читает данные из устройства и кладет их в очередь сообщений, откуда их потом забирает обыкновенное приложение Linux.
Как и каждый модуль Linux‑ядра, процесс реального времени дол‑
жен выполнить процедуры инициализации и завершения, аналогич‑
ные процедурам в модулях Linux:
int init_module (void)
{
/*определить номер очереди сообщений*/
#define RTFIFODESC 1
112
Раздел Б. Разработка информационно-управляющих систем
/*взять локальное время*/
RTIME now = rt_get_time () rt_task_init (&mytask, mainloop,
RTFIFODESC, 3000, 4);
rt_task_make_periodic (&mytask, now+1000, 25000);
return 0;
}
Подобный модульный подход к написанию приложений характерен для многих расширений реального времени. Задача реального времени работает независимо от ОС и, будучи критичной к времени реакции, программируется с помощью API‑интерфейсов, предусмотренных рас‑
ширением реального времени. Все служебные и интерфейсные функ‑
ции возлагаются на традиционную операционную систему.
С технологической точки зрения в современных системах реаль‑
ного времени все чаще требуется поддержка различных коммуника‑
ционных протоколов, кластерных конфигураций, языков высокого уровня [47–50]. Более того, приложения реального времени стано‑
вятся все сложнее, и использовать низкоуровневые языки програм‑
мирования для их создания становится все труднее и дороже. Именно это послужило стимулом для новой разработки WebSphere Real‑Time
Java (WRT) — виртуальной Java‑машины, основанной на технологии
IBM J9, содержащей уникальную функциональность для полноцен‑
ной поддержки систем жесткого и мягкого реального времени.
WRT поддерживает Java 2 Standard Edition версии 5, включая стан‑
дартную библиотеку классов Java. Виртуальная машина реализует спецификацию Java реального времени (JSR 1), обеспечивая интер‑
фейс для потоков реального времени и различных схем управления памятью в условиях производительности реального времени. WRT поддерживает компиляцию в ходе исполнения программ в условиях реального времени и содержит набор утилит для диагностики и опти‑
мизации кода.
Еще одно важнейшее улучшение виртуальной Java‑машины — ре‑
ализация спецификации Real‑Time Specifications for Java (RTSJ, или
JSR 1), которая расширяет функциональность Java для решения задач реального времени. В реализации RTSJ от IBM поддерживается при‑ оритет потоков и наследование приоритетов. В WRT реализованы по‑
токи реального времени: с поддержкой приоритетов, заданными ин‑
113 5. Системы реального времени тервалами реакции системы, доступом к внешним областям памяти и обнаружением блокировок. Существует особая возможность запу‑
ска
потоков реального времени, и для них используется специаль‑
ная область памяти. Для полноценной поддержки систем реально‑
го времени, в виртуальной машине Java были реализованы функции по управлению синхронизацией потоков, доступу к системному вы‑
сокоточному таймеру и работе с асинхронными событиями. Многие участки кода виртуальной машины были полностью обновлены, что‑
бы соответствовать требуемой производительности.
Таким образом, приложения на базе WebSpere Real‑Time Java мо‑
гут существенно упростить создание и поддержку систем реально‑
го времени. Полное решение для систем реального времени от IBM включает в себя серверы‑лезвия IBM на платформе x86‑64, операци‑
онную систему реального времени RT Linux (дистрибутив IBM, Red
Hat MRG или Novell SLERT), виртуальную машину и среду разработ‑
ки WebSphere Real‑Time Java.
Еще одно направление развития ОС РВ — управление в реаль‑
ном времени группировками устройств с использованиемIoT, IIoT или IoBT
Скачать 2.23 Mb.