330 / ЗаданКурсЖурналПолныйМПУСУ / ВыборОСРВ

О Б З О Р / В С Т Р А И В А Е М Ы Е С И С Т Е М Ы

будет использоваться руками, потому

Менее 10 мкс

17,3%

что, как известно, чем круче джип, тем

11–49 мкс

дольше идти за трактором. Иными сло

14,1%

51–99 мкс

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

9,4%

рее, чтобы сразу приступить к делу,

101–249 мкс

9,4%

всегда

чреват необходимостью

иметь

251–499 мкс

3,9%

дело с последствиями этого выбора на

501–999 мкс

4,7%

протяжении всей жизни проекта.

1 и более мс

25,5%

Рациональный выбор всегда слож

Нет информации

15,7%

нее, потому

что чёрт,

как известно,

0

10

20

30

кроется в деталях, а деталей в техниче

ских системах много. Но и это ещё не

Рис. 2. Технические требования к времени реакции на прерывание для текущего проекта

всё: чтобы оценить применимость про

(% респондентов, по данным опроса VDC за 2010 год)

дукта в той или иной задаче, нужно не

просто знать его характеристики, но и

ся в ТЗ и контролируются на приёмо

ОС «мягкого» реального времени или

выразить их в терминах поставленного

сдаточных

испытаниях; возможность

ОС общего назначения. Примечатель

технического задания (ТЗ), потому что

их обеспечить тесно связана с техни

но, что по результатам опросов в боль

иначе получается «в огороде бузина, а в

ческими характеристиками используе

шинстве проектов от ОС требуется ли

Киеве дядька». Настоящая статья под

мой ОС. Со стороны ОС в число заяв

бо очень медленная (от единиц мс), ли

ходит к выбору ОС «от задачи», пред

ляемых производителями характерис

бо, наоборот, очень быстрая (до десят

полагая, что в наличии имеются следу

тик обычно входят:

ков мкс) реакция (рис. 2).

ющие исходные данные:

● архитектурные принципы (тип ядра

Аналогично, когда речь идет об

● требуемые

характеристики

систе

и планировщика, модель многоза

оценке надёжности, следует иметь в

мы/изделия;

дачности и т.п.);

виду, что надёжность

программной

● необходимые технологии;

● временны<е характеристики (время

системы складывается из двух основ

● готовые наработки и опыт, имеющи

реакции на прерывание, время пе

ных составляющих:

еся у компании разработчика;

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

● безотказности;

● выбранное оборудование;

планирования и т.п.);

● отказоустойчивости.

● целевой рынок системы/изделия;

● поддержка реального времени («жёст

Безотказность, в свою очередь, скла

● экономические ограничения проекта.

кое», «мягкое» или отсутствует);

дывается из безотказности как самой

В каждой группе выделяются изме

● показатели надёжности (например,

ОС, так и прикладного кода, а значит,

римые (а значит, позволяющие произ

среднее время восстановления после

зависит не только от ОС, но и от при

вести сравнение) характеристики ОС,

отказа);

нятого для нее инструментария прик

влияющие на конечный выбор, и при

● метрики

производительности (на

ладного программирования (чем со

водится несколько конкретных иллю

пример,

пропускная способность

вершеннее инструментарий разработ

страций. В качестве примеров встраи

файловой системы на заданном но

ки, отладки и диагностики, тем больше

ваемых ОС, доступных для выбора, ис

сителе).

у разработчика возможностей написать

пользуются:

Все эти показатели могут использо

код с минимальным количеством де

● VxWorks и Wind River Linux американ

ваться для оценочных расчётов конеч

фектов). К факторам, определяющим

ской компании Wind River;

ных свойств системы, причём полез

безотказность, можно также отнести

● QNX

канадской

компании

QNX

ными здесь могут оказаться не только

используемый в ОС механизм защиты

Software Systems;

численные характеристики, но и об

от проблемы инверсии

приоритетов,

● Windows

Embedded

Standard

и

щие архитектурные принципы, потому

которой страдают все ОС с вытесняю

Windows Embedded Compact амери

что многие свойства ОС непосред

щим планировщиком, – если ОС не

канской корпорации Microsoft;

ственно вытекают из её архитектуры

умеет корректно обрабатывать ситуа

● RTOS 32 немецкой компании On

(как принято говорить у химиков,

цию инверсии приоритетов, то некор

Time Informatik.

строение определяет свойства).

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

Итак, пойдем по порядку.

К примеру, чтобы оценить, справит

ствие программных компонентов мо

ся ли система с расчётной нагрузкой,

жет стать причиной потери детермини

ВЫБОР ОС И ТРЕБУЕМЫЕ

нужно обращать внимание на время

рованности, что в системах жёсткого

ХАРАКТЕРИСТИКИ СИСТЕМЫ

реакции и метрики производительно

реального времени зачастую ведёт к ка

Для любой системы существуют кри

сти ОС, а также на их детерминирован

тастрофе.

терии качества, которым она должна

ность, поскольку обработать событие

Что касается отказоустойчивости, то

соответствовать, чтобы успешно вы

быстро – это одно дело, а обработать

здесь большую роль играет архитектура

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

его вовремя – совсем другое. Если в ис

ОС. В частности, ОС на основе микро

различных случаях

индивидуальны

и

ходной задаче жёстко регламентирова

ядра считаются более отказоустойчи

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

но максимальное

время отработки

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

способность, допустимое время вне

внешнего события, то для решения за

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

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

дачи необходима ОС «жёсткого» реаль

ями) выполняется только критический

ва интерфейса, скорость обработки

ного времени, временны<е характе

системный код; аналогично, повышен

внешнего события и т.п. Это измери

ристики которой

детерминированы;

ную отказоустойчивость обеспечивают

23

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

в противном случае можно обойтись

защита памяти и другие механизмы

изоляции компонентов, позволяющие,

тано сторонними компаниями и

во первых, локализовать отказ, а во

приобретается отдельно).

вторых, восстановить

нормальное

Из того, какие технологии поддер

функционирование отказавшего ком

живаются данной ОС (стеки протоко

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

лов, базы данных, 3D графика, управ

темы.

ление энергопотреблением, Java и т.п.),

Примеры выбора встраиваемой ОС по

непосредственно следует, какую часть

заданным характеристикам (табл. 1)

требуемой функциональности можно

Пример 1. Согласно ТЗ система

получить в готовом виде, какую при

должна обрабатывать входной аналого

дётся дополнительно

приобретать, а

вый сигнал с заданной граничной час

какую необходимо разрабатывать (или

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

переносить) самостоятельно.

разрешающую способность. С учётом

Примеры выбора встраиваемой ОС по

выбранного оборудования анализ по

поддерживаемым технологиям (табл. 1)

казал, что для корректной обработки

Пример 3. Согласно ТЗ система

сигнала без потери отсчётов необходи

должна обеспечивать высокий уровень

мо обеспечить время реакции на пре

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

рывание «прерывание – поток» не бо

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

лее 8 мкс. Временем отклика, способ

тельную среду и назначить ряду задач

ным обеспечить гарантированную об

выделенные ядра. С точки зрения тех

работку в таких ограничениях, облада

нических требований, это требует от

ют ОС VxWorks, QNX и RTOS 32.

ОС поддержки асимметричной мно

Пример 2. ТЗ содержит ограничения

гопроцессорности (Asymmetric multi

на время внепланового простоя систе

processing – AMP), её поддерживают не

мы в минутах в год (так называемый

все ОС. В нашем случае для реализа

коэффициент готовности). С учётом

ции задачи подойдут ОС VxWorks, QNX

выбранного оборудования анализ по

и Wind River Linux.

казал, что необходимо обеспечить воз

Пример 4. Согласно ТЗ система будет

можность восстановления отказавшего

содержать сторонние

компоненты,

программного компонента за время, не

разработанные на Java, требуемый про

превышающее 100 мс. Учитывая, что

филь Java – J2EE. Большинство встра

время перезагрузки ОС обычно состав

иваемых ОС поддерживает только про

ляет не менее единиц секунд, необхо

филь J2ME; в данном случае для реше

димо применение ОС, способной вос

ния задачи подойдет только ОС Win

станавливать отказавшие компоненты

dows Embedded Standard.

индивидуально, без полной переза

грузки. Таким свойством обладает ОС

ВЫБОР ОС И ИМЕЮЩИЕСЯ

QNX.

НАРАБОТКИ/ОПЫТ

Любое предприятие состоит из лю

ВЫБОР ОС И НЕОБХОДИМЫЕ

дей. Эти люди обладают определённым

ТЕХНОЛОГИИ

опытом и квалификацией, используют

Чтобы реализовать требуемую функ

привычные инструменты и технологии

циональность, приложению может по

и за время существования предприятия

требоваться поддержка тех или иных

накопили некоторое количество нара

технологий, например,

организация

боток, в частности, алгоритмов, реали

OPC туннелирования для интеграции

зованных в существующей кодовой ба

со SCADA приложением или поддерж

зе. Алгоритмы эти описаны на опреде

ка маршрутизации OSPF. Перечень не

лённых языках с использованием соот

обходимых технологий обычно являет

ветствующего интерфейса прикладного

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

программирования (Application Pro

ности приложения и указывается в ТЗ;

gramming Interface – API), и перенос их

его можно и нужно сравнивать с техно

на другой язык/API означает потенци

логическими возможностями ОС в

альное внесение ошибок в стабильный

процессе выбора. Описание технологи

отлаженный код. Соответственно, при

ческих возможностей ОС, в свою оче

выборе ОС для проекта нужно чётко

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

понимать, какая ОС способна принять

ющие вопросы:

имеющиеся опыт и наработки с мини

● что входит в дистрибутив (то есть ка

мальной модификацией существующе

кую функциональность ОС предлага

го кода и минимальным обучением

ет «из коробки»);

персонала.

● что доступно через партнёрскую сеть

В разрезе API мир встраиваемых ОС

25

производителя (то есть что разрабо

чётко поделён на два основных лаге

необходимо

пере

нести их во встраи

Процессор

62,7%

ваемую

вычисли

Встраиваемая/мобильная ОС

20%

тельную

систему.

Средства разработки ПО

11,8%

Применительно

к

Нет информации

5,5%

выбору

встраивае

0

20

40

60

80

мой ОС это означа

ет поддержку POSIX Рис. 3. Продукты, выбираемые для проекта в первую очередь

API с Linux специ

(% респондентов, по данным опроса VDC за 2010 год)

фичными расшире

ниями при минимальной ресурсоём

что ОС должна «влезать» в предостав

кости; лучше всего в данном случае

ленные ей объём памяти и вычисли

подходит ОС Wind River Linux.

тельную мощность, так как в условиях

недостатка ресурсов совместимость не

ВЫБОР ОС И ОБОРУДОВАНИЕ

имеет смысла.

В большинстве проектов оборудова

Таким образом, при выборе встраи

ние выбирается

первым, поскольку

ваемой ОС для имеющегося оборудо

именно от его характеристик зависит

вания нужно обращать внимание на

физическая

возможность реализации

следующие её характеристики:

поставленной задачи (это подтвержда

● список поддерживаемых процессор

ется результатами опросов – рис. 3).

ных архитектур;

Таким образом, на момент принятия

● заявленную ресурсоёмкость;

решения о выборе ОС список оборудо

● список

поддерживаемых

перифе

вания обычно уже известен, что позво

рийных устройств и готовых BSP;

ляет сразу оценить, во первых, требуе

● архитектуру и методику разработки

мую ресурсоёмкость ОС, а во вторых,

драйверов и BSP;

объём работ по её адаптации (они мо

● наличие

и

состав

предлагаемых

гут включать в себя разработку драйве

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

ров, BSP, а при необходимости и пор

BSP;

тирование ядра). Совместимость ОС с

● доступность технической поддержки

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

трёх

и сервисов разработки драйверов и

факторов:

BSP на заказ.

● совместимость на уровне архитекту

Первые три пункта описывают сов

ры процессора;

местимость «из

коробки», последние

● совместимость на уровне перифе

три – возможность произвести адапта

рийных устройств;

цию ОС, если совместимость «из ко

● требуемый объём ресурсов (то есть

робки» окажется недостаточной.

необходимая вычислительная мощ

Примеры выбора встраиваемой ОС

ность и объём занимаемой памяти).

под заданное оборудование (табл. 1)

Обеспечение

совместимости

на

Пример 7. Разрабатываемое устрой

уровне процессора

требует глубокой

ство представляет собой беспроводную

переработки ядра ОС, поэтому список

IP камеру видеонаблюдения; выбран

поддерживаемых процессоров обычно

ный процессор – Freescale MCF54455.

заявляется производителем ОС

как

Данный процессор относится к семей

данность и меняется редко. Обеспече

ству ColdFire и поддерживается только

ние поддержки периферийных уст

ОС VxWorks.

ройств сопряжено с гораздо меньшим

Пример 8. Выбранное оборудование

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

позволяет

выделить

программному

пакетом готовых драйверов и пакетом

обеспечению не более единиц Мбайт

поддержки процессорных плат (Board

ОЗУ. Расчёт показал, что из них для ОС

Support Package – BSP), которые вхо

будет доступно порядка 300 кбайт. В та

дят в дистрибутив ОС, производители

ких объёмах ОЗУ способны работать

обычно в том или ином виде предо

только ОС VxWorks или RTOS 32.

ставляют инструментарий для их само

стоятельной

разработки. Разумеется,

ВЫБОР ОС

поскольку у каждой ОС своя архитек

И ЦЕЛЕВОЙ РЫНОК

тура, то и подход к разработке и отлад

Про любое приложение всегда зара

ке драйверов и BSP у каждой ОС будет

нее известно, для какого целевого рын

разным; чем этот подход проще и про

ка оно предназначается; из этого авто

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

матически следует, каким отрасле

вать ОС к требуемой аппаратуре. При

вым стандартам оно (и, возможно, его

этом, естественно, не надо забывать,

компоненты) должно соответствовать.