Хабрахабр

RTOS или не RTOS вот в чем вопрос

image На написание данной статьи меня побудила длинная ветка комментариев (дискуссией это я назвать, к сожалению, не могу) к моей недавней статье “Многообразный мир embedded systems и место Embox в нем”. Меня в нескольких местах упрекнули в том, что я путаю RTOS и Embedded OS, что я назвал LynxOS, QNX и VxWorks не RTOS, хотя на мой взгляд, я такого, конечно, не делал. Автору данных комментариев я несколько раз предложил написать статью, в которой бы он изложил свое видение понятия “операционная система реального времени”, но он по каким-то причинам отказался. Ну что же, я изложу свое видение данного термина, и давайте обсудим, что же может называться RTOS, а что не может. В конце концов, этот вопрос часто задают применительно к Embox.

Термин ОС РВ (RTOS) относится к области маркетинга!

Я думал начать по-научному, с введения терминов, но решил, что данный провокационный тезис будет как нельзя кстати. Итак, почему же я утверждаю, что термин ОСРВ (операционные системы реального времени) относится к маркетингу, точнее, является маркетинговым (рекламным) слоганом? Все просто. Когда производится какой-то товар, его нужно продавать. Но если вы попробуете продать просто операционную систему, возникнут трудности. Тут приходит на помощь позиционирование на рынке. Например, можно сказать “мы более быстрые, чем они”.
Но за это можно попасть под суд! А там потребуется предоставить доказательства. Но как доказать, что ты более быстрый во всех случаях? Это же не соревнование по бегу. Но конечно, такая не совсем корректная конкурентная борьба слегка выбивается из нормального позиционирования на рынке.

Ну или формируешь у пользователя эти потребности. Нормальное позиционирование подразумевает формирование портрета потребителя выявление свойств продукта, которые у него более востребованы, и фокусировка на этих свойствах. Например, наш процессор имеет такую-то частоту, смартфон имеет аж N-ядерный процессор, и так далее.

Вводя понятие систем реального времени классики говорили о некоем критическом пороге времени. Поскольку классики жанра уже сформулировали, что операционные системы нужны не только для пользовательских систем, но и для управления различными технологическими процессами в автоматическом режиме и даже ввели понятие операционная система реального времени, то тут, сами понимаете, грех не воспользоваться. То есть в отличает от обычных систем, где если пользователь чего-то ждет, то может и подождать, система жесткого реального времени, например управляющая турбиной, подождать не может, а то можно докрутиться до чего-нибудь нехорошего.

Естественно чем оно меньше, тем большим числом различных технологических процессов система может управлять. Таким образом можно сказать пользователю, что ему в отличие от обычных операционных систем предоставят систему, которая гарантирует время реакции системы. И появляется множество таблиц, где в качестве ключевого параметра приводятся различные временные параметры RTOS.

Этот процесс честно описан! Как они получены? Ну маркетинг, естественно, может упростить и просто выдать, время реакции 1 мкc. Вот берем такую-то модельную задачу, такую-то аппаратную платформу и так-то подаем воздействие. Но мы это не принимаем в расчет, считаем, что все честно описано.

10 задач, 100 задач? Но простите, а если будет другая задача? А если в системе программист не правильно расставил приоритеты задач? А если пьяный программист залочит прерывания?

Мы сидели и думали как доказать, что это операционная система реального времени. Был случай когда Embox проходил испытания на реал-таймовость. Выясняем, что для заказчика реал-таймовость означает время реакции системы 1 мкс. Есть лаборатория, есть заказчик, который хочет чтобы это было так. Спрашиваю, а будет ли являться доказательством следующий эксперимент:

  • Берем некую аппаратную платформу
  • Подать на один из входов GPIO сигнал
  • Программно ловим событие
  • На выходе GPIO программно подаем сигнал
  • Измерения проводим с помощью осциллографа, время реакции будет разница между входным и выходным фронтами.

Заказчик подтверждает, что именно это и нужно. Я задаю уточняющий вопрос, а модельную систему проектируем мы и можем не запускать (не нагружать) ее другими задачами. То есть, нормально, что система будет делать только настолько простую тестовую задачу. Заказчик сказал, для этого и нужны тестовые задачи. Наверное сами понимаете, что испытания система прошла! Естественно с подтверждением характеристик, то есть воздействие было многократным.

А исключительно, чтобы показать всю неполноту картины. Данный раздел написан ни в коем случае не для того, чтобы принизить какие-то ОС или каких-то разработчиков. Я видел и другие испытания, когда заказывали выбор операционной системы независимой лаборатории исходя из требований задачи. Я не утверждал, что характеристики каких-то ОС не позволяют их относить к ОСРВ, а только что данный термин используется маркетологами. Там был сложный набор модельных задач, рассматривались и сетевое взаимодействие, и как меняются параметры, если система загружена, и поведения в различных нештатных ситуациях.

Определение термина “Операционная система реального времени”

Теперь введу термин “Операционная система реального времени”. Хотя нет, лучше не буду. Дело в том, что определений данного термина большое количество. Возьмем хотя бы комментарии к изначальной статье:

В системах реального времени человек вообще лишний и, соответственно, быстродействие системы реального времени должно сравниваться с процессами, которыми она управляет, будь то автономный автомобиль или система управления технологическим процессом на заводе.

СРВ/ОСРВ — это исключительно ранжирование по предсказуемости реагирования на критические события.

ОСРВ — это такая ОС, в которой корректность выполнения задачи характеризуется не только логической корректностью, но временем выполнения этой задачи.

1 мкс и все станет на свои места.
Вы четко увидите где RTOS, а где нет. Поставьте критерием время переключения контекста любой задачи в 1 мкс на 100 МГц процессоре с float-point сопроцессором с детерминированностью в 0.

Ну, и, не могу обойти стороной мнение, о котором я рассказал в статье, прозвучавшее на одной из конференций OSDAY:

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

Но может это все просто частности, и как предложили в комментарии стоит просто использовать классиков и не придумывать велосипеды. Приведу указанного классика (Эндрю Таненбаума, если кто-то не догадался):

These systems are characterized by having time as a key parameter. «Another type of operating system is the real-time system. Often there are hard deadlines that must be met. 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. If a welding robot welds too early or too late, the car will be ruined. For example, if a car is moving down an assembly line, certain actions must take place at certain instants of time. Many of these are found in industrial process control, avionics, military, and similar application areas. If the action absolutely must occur at a certain moment (or within a certain range), we have a hard real-time system. These systems must provide absolute guarantees that a certain action will occur by a certain time.

Digital audio or multimedia systems fall in this category. 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 telephones are also soft real-time systems.

An example of this type of real-time system is e-Cos. 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.

Nearly all of them have at least some soft real-time aspects. The categories of handhelds, embedded systems, and real-time systems overlap considerably. The handhelds and embedded systems are intended for consumers, whereas real-time systems are more for industrial usage. 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. Nevertheless, they have a certain amount in common.”

Но и из этого описания следует только, что системы могут применяться в системах где отсутствие реакции в заданный срок может привести к катастрофическим последствиям. Ну еще в целях достижения ключевого параметра (не превышения времени реакции) ОС могут представлять из себя библиотеку, пример eCos.

Про soft и hard real-time

И я понимаю, что тут речь шла скорее о всяких DSP, то есть обработке сигналов. Я сознательно не стал замечать деление на soft и hard, поскольку системой мягкого реального времени, наверное может считаться любая современная универсальная ОС, ну например windows прекрасно проигрывает мультимедийные файлы. В общем, здесь и далее имеются в виду только системы, где нарушать предельное время нельзя, то есть hard real-time.
Но если еще и эту часть рассматривать, то вообще никогда не закончим.

Как же добиться характеристик реального времени

Строгого определения у меня дать не получилось (если кто-то готов дать, пишите в комментариях). Но во всех вышеперечисленных определениях видно пару свойств (это время и предсказуемость). Если перевести время в опцию предсказуемости (вес дуги при переходе из одного состояния в другое), то остается только предсказуемость!

Давайте подумаем, как этого добиться.

Универсальную систему вряд ли получится сделать стабильной. Очевидным будет убрать все лишнее из критической системы. Даже товарищ Таненбаум об этом говорил, я имею в виду, когда он говорил о eCos.

Он предложил несколько подходов к планированию, но я бы хотел в первую очередь остановиться на статической таблице планирования (Static table-driven). Еще одним подходом, увеличивающим предсказуемость системы, опять же, предложенный Таненбаумом, является использование специальных (простых) алгоритмов для планирования ресурсов, в первую очередь процессорного времени, то есть специальных планировщиков задач.

Для этого предлагается статически проанализировать критическую задачу и определить ее пороговые значения. Разработчик должен гарантировать, что все задачи успевают выполниться в свой квант времени. Стандарт для бортовых систем, и сами понимаете, если у самолёта что-то вдруг не успеет отработать, то может случиться катастрофа. Именно этот подход заложен в стандарт ARINC-653.

То есть разработчик должен опять же проанализировать все ситуации и, присвоив всем задачам в системе приоритеты, обеспечить выполнение критически важных задач в заданное время. Следующим подходом является статическое расписание, но на основе приоритетов.

Написан он, конечно, лучше, чем это могу сделать я, ну и к тому же, опять могут обвинить в искажении фактов. Продолжать не хочется, ведь есть оригинал! А операционная система должна только предоставить соответствующие возможности. Привел я именно эти подходы для того, чтобы показать, что в любом случае на разработчика конечной системы ложится ответственность за обеспечение характеристик системы.

Продолжая рассуждения о методах повышения предсказуемости, хочу привести еще один комментарий

“На малинке можно добиться реального времени, но не с RTOS, а с маленькой стэйт машиной влезающей в его кэш.”

Здесь хочу обратить внимание на следующие моменты:

  • повышение предсказуемости (свойств реального времени) за счет исключения из системы вообще какой либо RTOS
  • представление программы машиной состояний
  • ну и на зависимость систем реального времени не только от свойств программного обеспечения, но и аппаратного.

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

В частности, когда говорилось об отсутствии циклов с произвольным количеством итераций в состоянии залоченных прерываний, звучало, что на каком-то cortex-m в описываемой RTOS вообще нет отключения прерываний. Что есть влияние аппаратной части тоже скорее всего не вызывает сомнений. Ну и конечно, наличие cache, трансляции адресов (точнее промахов по страницам), вносит свою лепту неопределенности. Это немного лукавство, ведь там контроллер прерываний отключает прерывания с равным или более низким приоритетом, самостоятельно, но факт влияния налицо. Ну вот отвалился у вас проводок, как наличие ОСРВ позволит избежать катастрофического исхода событий? Особенно, я хотел обратить внимание еще на тот факт, что вообще-то на сто процентов гарантировать правильную работоспособность аппаратуры никто не может.

А именно, что программа для повышения предсказуемости может анализироваться. Представление программы как машины состояний, хотел бы предложить рассмотреть с неочевидной стороны. Ну а поскольку статическому анализу гораздо лучше поддаются функциональные языки программирования, то возможно разрабатывать программу следует и на некоем специальном языке, или добавлять использование специальных языков программирования. А поскольку речь идет о всех состояниях, то она должна анализироваться, причем статически, на все возможные ситуации. Примером второго подхода, является все тот же стандарт ARINC-653, с его обязательным формированием требований на языке XML. Первый подход используется, например, в верифицированным ядре seL4.

Я делал доклад по данной теме на одной из конференций OSDay. Существуют и другие методы, повышающие предсказуемость или, если хотите, факторы влияющие на предсказуемость системы. Ведь общеизвестно, что, например, микроядерная архитектура может увеличивать предсказуемость системы. В частности, кроме уже перечисленных, я выделил еще архитектурный подход. Здесь речь как раз о том моменте, где я не согласился, что отсутствие RTOS ведет к увеличению предсказуемости. Но еще в том же докладе был выделен несколько неочевидный, организационный подход. То есть, если у вас не код, который реально влезает в один switch/case, то лучше использовать готовые модули. Если задуматься, то вообще понятие операционной системы позволило существенно сократить количество ошибок за счет переиспользования кода. Ведь параметр „количество ошибок на 1000 строк кода“ никто не отменял, и каким бы отлаженным ни был ваш новый код, там есть ошибки.

ОСРВ вообще существуют?

Остановившись на в предыдущем разделе, на утверждении, что в любом коде есть ошибки, хочу высказать еще один провокационный тезис. ОСРВ вообще существуют?

Дискутируя со знакомым по поводу систем реального времени, договорились до того, что операционная система реального времени (мы говорим о системах жесткого реального времени), вряд ли может существовать. Давайте разберемся. При этом система может считаться стабильной, если доказано что при всех входных и внутренних состояниях, существует дуга, ведущая в заданное состояние с ограничением по времени. Он предложил представить всю систему как машину состояний или граф с описанием максимального времени перехода из одного состояния в другое. Ну а сами понимаете, такое возможно только для очень маленькой системы, как раз той самой машины состояний, упомянутой в комментарии, но в современном мире подобная система мало кому нужна.

Ну и конечно, ОСРВ тоже. Но мы же не сомневаемся, что системы реального времени существуют. Если бы это было не так, то первый залетевший дятел разрушил бы цивилизацию, то не было бы авионики, космонавтики, робототехники, АСУ-ТП да и многого другого.

Очень просто, хотя в общем задача, скорее всего не решаемая, но для конкретной задачи, можно ввести ограничения, которые делают ее разрешимой, с какой то осмысленной вероятностью ошибки. Как выходят из ситуации.

Данные стандарты, по сути дела, выделяют класс задач, которые могут быть решены, если придерживаться данного стандарта. Например, вводятся стандарты: realtime POSIX, ARINC-653, ITRON. Или проводятся исследования независимыми лабораториями, которые изучают подходят ли свойства конкретной ОС, для решения целевой задачи.

Так Embox RTOS или не RTOS?

На мой взгляд, ответить на подобный вопрос, как для Embox так и для любой другой ОС, можно только вопросом: “Что Вы имеете в виду?”. Точнее: “А что Вы подразумеваете под понятием реального времени?”. То есть, если интересует время обработки прерывания, и можно ли вызвать обработчик прерывания напрямую, — это одно, если нужно повысить надежность работы, пусть медленно, но зато точно гораздо меньше вероятность сбоя, — это другое, соответствие какому либо стандарту — это третье, возможность верификации — это четвертое. Не случайно великий классик Андрю Таненбаум, хоть и предложил методы повышения предсказуемости, и использовал само понятие система реального времени, но воздержался от каких-то строгих определений.

S. P. Во время написания данной статьи ни одна ОСРВ не пострадала.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть