На написание данной статьи меня побудила длинная ветка комментариев (дискуссией это я назвать, к сожалению, не могу) к моей недавней статье “Многообразный мир embedded systems и место Embox в нем”. Меня в нескольких местах упрекнули в том, что я путаю RTOS и Embedded OS, что я назвал LynxOS, QNX и VxWorks не RTOS, хотя на мой взгляд, я такого, конечно, не делал. Автору данных комментариев я несколько раз предложил написать статью, в которой бы он изложил свое видение понятия “операционная система реального времени”, но он по каким-то причинам отказался. Ну что же, я изложу свое видение данного термина, и давайте обсудим, что же может называться RTOS, а что не может. В конце концов, этот вопрос часто задают применительно к Embox.
Термин ОС РВ (RTOS) относится к области маркетинга!
Я думал начать по-научному, с введения терминов, но решил, что данный провокационный тезис будет как нельзя кстати. Итак, почему же я утверждаю, что термин ОСРВ (операционные системы реального времени) относится к маркетингу, точнее, является маркетинговым (рекламным) слоганом? Все просто. Когда производится какой-то товар, его нужно продавать. Но если вы попробуете продать просто операционную систему, возникнут трудности. Тут приходит на помощь позиционирование на рынке. Например, можно сказать “мы более быстрые, чем они”.
Но за это можно попасть под суд! А там потребуется предоставить доказательства. Но как доказать, что ты более быстрый во всех случаях? Это же не соревнование по бегу. Но конечно, такая не совсем корректная конкурентная борьба слегка выбивается из нормального позиционирования на рынке.
Нормальное позиционирование подразумевает формирование портрета потребителя выявление свойств продукта, которые у него более востребованы, и фокусировка на этих свойствах. Ну или формируешь у пользователя эти потребности. Например, наш процессор имеет такую-то частоту, смартфон имеет аж N-ядерный процессор, и так далее.
Поскольку классики жанра уже сформулировали, что операционные системы нужны не только для пользовательских систем, но и для управления различными технологическими процессами в автоматическом режиме и даже ввели понятие операционная система реального времени, то тут, сами понимаете, грех не воспользоваться. Вводя понятие систем реального времени классики говорили о некоем критическом пороге времени. То есть в отличает от обычных систем, где если пользователь чего-то ждет, то может и подождать, система жесткого реального времени, например управляющая турбиной, подождать не может, а то можно докрутиться до чего-нибудь нехорошего.
Таким образом можно сказать пользователю, что ему в отличие от обычных операционных систем предоставят систему, которая гарантирует время реакции системы. Естественно чем оно меньше, тем большим числом различных технологических процессов система может управлять. И появляется множество таблиц, где в качестве ключевого параметра приводятся различные временные параметры RTOS.
Как они получены? Этот процесс честно описан! Вот берем такую-то модельную задачу, такую-то аппаратную платформу и так-то подаем воздействие. Ну маркетинг, естественно, может упростить и просто выдать, время реакции 1 мкc. Но мы это не принимаем в расчет, считаем, что все честно описано.
Но простите, а если будет другая задача? 10 задач, 100 задач? А если пьяный программист залочит прерывания? А если в системе программист не правильно расставил приоритеты задач?
Был случай когда Embox проходил испытания на реал-таймовость. Мы сидели и думали как доказать, что это операционная система реального времени. Есть лаборатория, есть заказчик, который хочет чтобы это было так. Выясняем, что для заказчика реал-таймовость означает время реакции системы 1 мкс. Спрашиваю, а будет ли являться доказательством следующий эксперимент:
- Берем некую аппаратную платформу
- Подать на один из входов GPIO сигнал
- Программно ловим событие
- На выходе GPIO программно подаем сигнал
- Измерения проводим с помощью осциллографа, время реакции будет разница между входным и выходным фронтами.
Заказчик подтверждает, что именно это и нужно. Я задаю уточняющий вопрос, а модельную систему проектируем мы и можем не запускать (не нагружать) ее другими задачами. То есть, нормально, что система будет делать только настолько простую тестовую задачу. Заказчик сказал, для этого и нужны тестовые задачи. Наверное сами понимаете, что испытания система прошла! Естественно с подтверждением характеристик, то есть воздействие было многократным.
Данный раздел написан ни в коем случае не для того, чтобы принизить какие-то ОС или каких-то разработчиков. А исключительно, чтобы показать всю неполноту картины. Я не утверждал, что характеристики каких-то ОС не позволяют их относить к ОСРВ, а только что данный термин используется маркетологами. Я видел и другие испытания, когда заказывали выбор операционной системы независимой лаборатории исходя из требований задачи. Там был сложный набор модельных задач, рассматривались и сетевое взаимодействие, и как меняются параметры, если система загружена, и поведения в различных нештатных ситуациях.
Определение термина “Операционная система реального времени”
Теперь введу термин “Операционная система реального времени”. Хотя нет, лучше не буду. Дело в том, что определений данного термина большое количество. Возьмем хотя бы комментарии к изначальной статье:
СРВ/ОСРВ — это исключительно ранжирование по предсказуемости реагирования на критические события.
Ну, и, не могу обойти стороной мнение, о котором я рассказал в статье, прозвучавшее на одной из конференций OSDAY:
Система может считаться системой жесткого реального времени, если в ней нет мест, где при залоченных прерываниях, есть циклы с неизвестным числом итераций.
Но может это все просто частности, и как предложили в комментарии стоит просто использовать классиков и не придумывать велосипеды. Приведу указанного классика (Эндрю Таненбаума, если кто-то не догадался):
«Another type of operating system is the real-time system. These systems are characterized by having time as a key parameter. For example, in industrial process control systems, real-time computers have to collect data about the production process and use it to control machines in the factory. Often there are hard deadlines that must be met. For example, if a car is moving down an assembly line, certain actions must take place at certain instants of time. If a welding robot welds too early or too late, the car will be ruined. If the action absolutely must occur at a certain moment (or within a certain range), we have a hard real-time system. Many of these are found in industrial process control, avionics, military, and similar application areas. These systems must provide absolute guarantees that a certain action will occur by a certain time.
Another kind of real-time system is a soft real-time system, in which missing an occasional deadline, while not desirable, is acceptable and does not cause any permanent damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.
Since meeting strict deadlines is crucial in real-time systems, sometimes the operating system is simply a library linked in with the application programs, with everything tightly coupled and no protection between parts of the system. An example of this type of real-time system is e-Cos.
The categories of handhelds, embedded systems, and real-time systems overlap considerably. Nearly all of them have at least some soft real-time aspects. The embedded and real-time systems run only software put in by the system designers; users cannot add their own software, which makes protection easier. The handhelds and embedded systems are intended for consumers, whereas real-time systems are more for industrial usage. Nevertheless, they have a certain amount in common.”
Но и из этого описания следует только, что системы могут применяться в системах где отсутствие реакции в заданный срок может привести к катастрофическим последствиям. Ну еще в целях достижения ключевого параметра (не превышения времени реакции) ОС могут представлять из себя библиотеку, пример eCos.
Как же добиться характеристик реального времени
Строгого определения у меня дать не получилось (если кто-то готов дать, пишите в комментариях). Но во всех вышеперечисленных определениях видно пару свойств (это время и предсказуемость). Если перевести время в опцию предсказуемости (вес дуги при переходе из одного состояния в другое), то остается только предсказуемость!
Давайте подумаем, как этого добиться.
Очевидным будет убрать все лишнее из критической системы. Универсальную систему вряд ли получится сделать стабильной. Даже товарищ Таненбаум об этом говорил, я имею в виду, когда он говорил о eCos.
Еще одним подходом, увеличивающим предсказуемость системы, опять же, предложенный Таненбаумом, является использование специальных (простых) алгоритмов для планирования ресурсов, в первую очередь процессорного времени, то есть специальных планировщиков задач. Он предложил несколько подходов к планированию, но я бы хотел в первую очередь остановиться на статической таблице планирования (Static table-driven).
Разработчик должен гарантировать, что все задачи успевают выполниться в свой квант времени. Для этого предлагается статически проанализировать критическую задачу и определить ее пороговые значения. Именно этот подход заложен в стандарт ARINC-653. Стандарт для бортовых систем, и сами понимаете, если у самолёта что-то вдруг не успеет отработать, то может случиться катастрофа.
Следующим подходом является статическое расписание, но на основе приоритетов. То есть разработчик должен опять же проанализировать все ситуации и, присвоив всем задачам в системе приоритеты, обеспечить выполнение критически важных задач в заданное время.
Продолжать не хочется, ведь есть оригинал! Написан он, конечно, лучше, чем это могу сделать я, ну и к тому же, опять могут обвинить в искажении фактов. Привел я именно эти подходы для того, чтобы показать, что в любом случае на разработчика конечной системы ложится ответственность за обеспечение характеристик системы. А операционная система должна только предоставить соответствующие возможности.
Продолжая рассуждения о методах повышения предсказуемости, хочу привести еще один комментарий
“На малинке можно добиться реального времени, но не с RTOS, а с маленькой стэйт машиной влезающей в его кэш.”
Здесь хочу обратить внимание на следующие моменты:
- повышение предсказуемости (свойств реального времени) за счет исключения из системы вообще какой либо RTOS
- представление программы машиной состояний
- ну и на зависимость систем реального времени не только от свойств программного обеспечения, но и аппаратного.
С уменьшением количества непредсказуемости в случае уменьшения количества строчек кода думаю все согласны. Хотя я как всегда не согласен, но об этом чуть позже.
Что есть влияние аппаратной части тоже скорее всего не вызывает сомнений. В частности, когда говорилось об отсутствии циклов с произвольным количеством итераций в состоянии залоченных прерываний, звучало, что на каком-то cortex-m в описываемой RTOS вообще нет отключения прерываний. Это немного лукавство, ведь там контроллер прерываний отключает прерывания с равным или более низким приоритетом, самостоятельно, но факт влияния налицо. Ну и конечно, наличие cache, трансляции адресов (точнее промахов по страницам), вносит свою лепту неопределенности. Особенно, я хотел обратить внимание еще на тот факт, что вообще-то на сто процентов гарантировать правильную работоспособность аппаратуры никто не может. Ну вот отвалился у вас проводок, как наличие ОСРВ позволит избежать катастрофического исхода событий?
Представление программы как машины состояний, хотел бы предложить рассмотреть с неочевидной стороны. А именно, что программа для повышения предсказуемости может анализироваться. А поскольку речь идет о всех состояниях, то она должна анализироваться, причем статически, на все возможные ситуации. Ну а поскольку статическому анализу гораздо лучше поддаются функциональные языки программирования, то возможно разрабатывать программу следует и на некоем специальном языке, или добавлять использование специальных языков программирования. Первый подход используется, например, в верифицированным ядре seL4. Примером второго подхода, является все тот же стандарт ARINC-653, с его обязательным формированием требований на языке XML.
Существуют и другие методы, повышающие предсказуемость или, если хотите, факторы влияющие на предсказуемость системы. Я делал доклад по данной теме на одной из конференций OSDay. В частности, кроме уже перечисленных, я выделил еще архитектурный подход. Ведь общеизвестно, что, например, микроядерная архитектура может увеличивать предсказуемость системы. Но еще в том же докладе был выделен несколько неочевидный, организационный подход. Здесь речь как раз о том моменте, где я не согласился, что отсутствие RTOS ведет к увеличению предсказуемости. Если задуматься, то вообще понятие операционной системы позволило существенно сократить количество ошибок за счет переиспользования кода. То есть, если у вас не код, который реально влезает в один switch/case, то лучше использовать готовые модули. Ведь параметр „количество ошибок на 1000 строк кода“ никто не отменял, и каким бы отлаженным ни был ваш новый код, там есть ошибки.
ОСРВ вообще существуют?
Остановившись на в предыдущем разделе, на утверждении, что в любом коде есть ошибки, хочу высказать еще один провокационный тезис. ОСРВ вообще существуют?
Давайте разберемся. Дискутируя со знакомым по поводу систем реального времени, договорились до того, что операционная система реального времени (мы говорим о системах жесткого реального времени), вряд ли может существовать. Он предложил представить всю систему как машину состояний или граф с описанием максимального времени перехода из одного состояния в другое. При этом система может считаться стабильной, если доказано что при всех входных и внутренних состояниях, существует дуга, ведущая в заданное состояние с ограничением по времени. Ну а сами понимаете, такое возможно только для очень маленькой системы, как раз той самой машины состояний, упомянутой в комментарии, но в современном мире подобная система мало кому нужна.
Но мы же не сомневаемся, что системы реального времени существуют. Ну и конечно, ОСРВ тоже. Если бы это было не так, то первый залетевший дятел разрушил бы цивилизацию, то не было бы авионики, космонавтики, робототехники, АСУ-ТП да и многого другого.
Как выходят из ситуации. Очень просто, хотя в общем задача, скорее всего не решаемая, но для конкретной задачи, можно ввести ограничения, которые делают ее разрешимой, с какой то осмысленной вероятностью ошибки.
Например, вводятся стандарты: realtime POSIX, ARINC-653, ITRON. Данные стандарты, по сути дела, выделяют класс задач, которые могут быть решены, если придерживаться данного стандарта. Или проводятся исследования независимыми лабораториями, которые изучают подходят ли свойства конкретной ОС, для решения целевой задачи.
Так Embox RTOS или не RTOS?
На мой взгляд, ответить на подобный вопрос, как для Embox так и для любой другой ОС, можно только вопросом: “Что Вы имеете в виду?”. Точнее: “А что Вы подразумеваете под понятием реального времени?”. То есть, если интересует время обработки прерывания, и можно ли вызвать обработчик прерывания напрямую, — это одно, если нужно повысить надежность работы, пусть медленно, но зато точно гораздо меньше вероятность сбоя, — это другое, соответствие какому либо стандарту — это третье, возможность верификации — это четвертое. Не случайно великий классик Андрю Таненбаум, хоть и предложил методы повышения предсказуемости, и использовал само понятие система реального времени, но воздержался от каких-то строгих определений.
P.S. Во время написания данной статьи ни одна ОСРВ не пострадала.
Автор: Антон Бондарев
