На написание данной статьи меня побудила длинная ветка комментариев (дискуссией это я назвать, к сожалению, не могу) к моей недавней статье “Многообразный мир embedded systems и место Embox в нем”. Меня в нескольких местах упрекнули в том, что я путаю RTOS и Embedded OS, что я назвал LynxOS, QNX и VxWorks не RTOS, хотя на мой взгляд, я такого, конечно, не делал. Автору данных комментариев я несколько раз предложил написать статью, в которой бы он изложил свое видение понятия “операционная система реального времени”, но он по каким-то причинам отказался. Ну что же, я изложу свое видение данного термина, и давайте обсудим, что же может называться RTOS, а что не может. В конце концов, этот вопрос часто задают применительно к Embox. Термин ОС РВ (RTOS) относится к области маркетинга!
Я думал начать по-научному, с введения терминов, но решил, что данный провокационный тезис будет как нельзя кстати. Итак, почему же я утверждаю, что термин ОСРВ (операционные системы реального времени) относится к маркетингу, точнее, является маркетинговым (рекламным) слоганом? Все просто. Когда производится какой-то товар, его нужно продавать. Но если вы попробуете продать просто операционную систему, возникнут трудности. Тут приходит на помощь позиционирование на рынке. Например, можно сказать “мы более быстрые, чем они”.
Но за это можно попасть под суд! А там потребуется предоставить доказательства. Но как доказать, что ты более быстрый во всех случаях? Это же не соревнование по бегу. Но конечно, такая не совсем корректная конкурентная борьба слегка выбивается из нормального позиционирования на рынке.
Нормальное позиционирование подразумевает формирование портрета потребителя выявление свойств продукта, которые у него более востребованы, и фокусировка на этих свойствах. Ну или формируешь у пользователя эти потребности. Например, наш процессор имеет такую-то частоту, смартфон имеет аж N-ядерный процессор, и так далее.
Поскольку классики жанра уже сформулировали, что операционные системы нужны не только для пользовательских систем, но и для управления различными технологическими процессами в автоматическом режиме и даже ввели понятие операционная система реального времени, то тут, сами понимаете, грех не воспользоваться. Вводя понятие систем реального времени классики говорили о некоем критическом пороге времени. То есть в отличает от обычных систем, где если пользователь чего-то ждет, то может и подождать, система жесткого реального времени, например управляющая турбиной, подождать не может, а то можно докрутиться до чего-нибудь нехорошего.
Таким образом можно сказать пользователю, что ему в отличие от обычных операционных систем предоставят систему, которая гарантирует время реакции системы. Естественно чем оно меньше, тем большим числом различных технологических процессов система может управлять. И появляется множество таблиц, где в качестве ключевого параметра приводятся различные временные параметры RTOS.
Как они получены? Этот процесс честно описан! Вот берем такую-то модельную задачу, такую-то аппаратную платформу и так-то подаем воздействие. Ну маркетинг, естественно, может упростить и просто выдать, время реакции 1 мкc. Но мы это не принимаем в расчет, считаем, что все честно описано.
Но простите, а если будет другая задача? 10 задач, 100 задач? А если пьяный программист залочит прерывания? А если в системе программист не правильно расставил приоритеты задач?
Был случай когда Embox проходил испытания на реал-таймовость. Мы сидели и думали как доказать, что это операционная система реального времени. Есть лаборатория, есть заказчик, который хочет чтобы это было так. Выясняем, что для заказчика реал-таймовость означает время реакции системы 1 мкс. Спрашиваю, а будет ли являться доказательством следующий эксперимент:
- Берем некую аппаратную платформу
- Подать на один из входов GPIO сигнал
- Программно ловим событие
- На выходе GPIO программно подаем сигнал
- Измерения проводим с помощью осциллографа, время реакции будет разница между входным и выходным фронтами.
Заказчик подтверждает, что именно это и нужно. Я задаю уточняющий вопрос, а модельную систему проектируем мы и можем не запускать (не нагружать) ее другими задачами. То есть, нормально, что система будет делать только настолько простую тестовую задачу. Заказчик сказал, для этого и нужны тестовые задачи. Наверное сами понимаете, что испытания система прошла! Естественно с подтверждением характеристик, то есть воздействие было многократным.
Данный раздел написан ни в коем случае не для того, чтобы принизить какие-то ОС или каких-то разработчиков. А исключительно, чтобы показать всю неполноту картины. Я не утверждал, что характеристики каких-то ОС не позволяют их относить к ОСРВ, а только что данный термин используется маркетологами. Я видел и другие испытания, когда заказывали выбор операционной системы независимой лаборатории исходя из требований задачи. Там был сложный набор модельных задач, рассматривались и сетевое взаимодействие, и как меняются параметры, если система загружена, и поведения в различных нештатных ситуациях.
Определение термина “Операционная система реального времени”
Теперь введу термин “Операционная система реального времени”. Хотя нет, лучше не буду. Дело в том, что определений данного термина большое количество. Возьмем хотя бы комментарии к изначальной статье:
В системах реального времени человек вообще лишний и, соответственно, быстродействие системы реального времени должно сравниваться с процессами, которыми она управляет, будь то автономный автомобиль или система управления технологическим процессом на заводе.
СРВ/ОСРВ — это исключительно ранжирование по предсказуемости реагирования на критические события.
ОСРВ — это такая ОС, в которой корректность выполнения задачи характеризуется не только логической корректностью, но временем выполнения этой задачи.
Поставьте критерием время переключения контекста любой задачи в 1 мкс на 100 МГц процессоре с float-point сопроцессором с детерминированностью в 0.1 мкс и все станет на свои места.Ну, и, не могу обойти стороной мнение, о котором я рассказал в статье, прозвучавшее на одной из конференций OSDAY:
Вы четко увидите где RTOS, а где нет.
Система может считаться системой жесткого реального времени, если в ней нет мест, где при залоченных прерываниях, есть циклы с неизвестным числом итераций.Но может это все просто частности, и как предложили в комментарии стоит просто использовать классиков и не придумывать велосипеды. Приведу указанного классика (Эндрю Таненбаума, если кто-то не догадался):
«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.Но и из этого описания следует только, что системы могут применяться в системах где отсутствие реакции в заданный срок может привести к катастрофическим последствиям. Ну еще в целях достижения ключевого параметра (не превышения времени реакции) ОС могут представлять из себя библиотеку, пример eCos.
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.
Еще одним подходом, увеличивающим предсказуемость системы, опять же, предложенный Таненбаумом, является использование специальных (простых) алгоритмов для планирования ресурсов, в первую очередь процессорного времени, то есть специальных планировщиков задач. Он предложил несколько подходов к планированию, но я бы хотел в первую очередь остановиться на статической таблице планирования (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. Во время написания данной статьи ни одна ОСРВ не пострадала.
Комментарии (52)
anger32
22.02.2019 18:29+1Как выходят из ситуации. Очень просто, хотя в общем задача, скорее всего не решаемая, но для конкретной задачи, можно ввести ограничения, которые делают ее разрешимой, с какой то осмысленной вероятностью ошибки.
Как я уже написал в комментарии выше, наличие лейбла RTOS не является серебряной пулей. Оно позволяет гарантировать, что для решаемой задачи в пределах установленных границ любое внешнее событие не приведет к потере отказоустойчивости.
Это не маркетинг, это отдельная научная дисциплина. Хотя и маркетологи, как животные всеядные, этой терминологией не пренебрегают.
Был случай когда Embox проходил испытания на реал-таймовость. Мы сидели и думали как доказать, что это операционная система реального времени. Есть лаборатория, есть заказчик, который хочет чтобы это было так. Выясняем, что для заказчика реал-таймовость означает время реакции системы 1 мкс. Спрашиваю, а будет ли являться доказательством следующий эксперимент:
А вот если бы вы в методологическую базу своего эксперимента включили такие положения, как:
— любое сочетание внешних событий в оговоренных фиксированных границах (дополнительные внешние источники прерываний);
— любое сочетание внутренних событий в оговоренных фиксированных границах (aka имитация вычислительной и операционной нагрузки);
— четко очерченный диапазон реалтаймовых задач и задач общего назначения (при четко заданных диапазонах случайных параметров);
— производили замеры как в контексте ISR, так и в контексте не привилегированного кода;
— производили статистическую обработку худших, средних и лучших замеров посредством внешних измерительных приборов;
Можно было бы говорить о том, что результаты у вас хоть на что-то претендуют кроме маркетинга. И в данном случае пенять на компетенцию некоего сферического заказчика совсем не дело. Заказчик совершенно не обязан быть специалистом в этом вопросе. Практика показывает, что как раз он обычно таковым не является.
abondarev Автор
22.02.2019 18:44Про испытания Embox я сознательно утрировал!
Приведенный эксперимерт проводился в условиях сетевой активности, загружался некими вычислительными задачами, хоть и более низкого приоритета чем исследуемая, статистику собирали внешним осцилографом, в условиях разных воздействий. Но сути дела это не меняет. Но вот приведенных в первом комментарии 100% или must и absolute конечно не было. И я честно говорил заказчику, ну и здесь. Что нужно более честко формулировать критерии термина real-time.anger32
22.02.2019 18:51+1Про испытания Embox я сознательно утрировал!
Ок.
Но вот приведенных в первом комментарии 100% или must и absolute конечно не было.
Но вы ведь не будете спорить с тем, что доказательство принадлежности ОС к ОСРВ не есть обязанность потребителя. Поиск доказательной базы в данном аспекте задача весьма нетривиальная. Настолько, что некоторые вендоры реально ее не решали и апеллируют к статистическому критерию вида «наработка на отказ в режиме РВ в объеме стольки-то машино-веков».abondarev Автор
22.02.2019 19:27Но вы ведь не будете спорить с тем, что доказательство принадлежности ОС к ОСРВ не есть обязанность потребителя.
Не всегда. Хорошо если есть критерии для задач потребителя. Например, авионика с ARINC-653, но если нет, а задача серьезная, то решать ее нужно. Приведенный в статье анализ лаборатории, был для АЭС. И прежде чем разрабатывать ПО им нужно было выбрать платформу. В данном случае, Embox не участвовал в исследовании, если что.
Поиск доказательной базы в данном аспекте задача весьма нетривиальная. Настолько, что некоторые вендоры реально ее не решали и апеллируют к статистическому критерию вида «наработка на отказ в режиме РВ в объеме стольки-то машино-веков»
Вот тут абсолютно согласен. и более того считаю что это правильно, с поправкой на решаемую задачу конечно. Нужно же дать потребителю, какие нибудь намеки на правильное решение, а то поставят обычную систему с косынкой на какую нибудь турбину, а потом удивляются, что вроде работала работала, и вот опять!
arcman
23.02.2019 11:47В заметке много обиды, субъективизма и воды. Если все это убрать вполне может получиться хорошая статья про ОСРВ.
cattheblack
23.02.2019 13:57Добавлю, что в комментариях весьма странная дискуссия, не очень профессиональный взгляд показан. Как можно смешивать понятия софта и харда в одном флаконе? ОС, именно ОС РВ никак не обязана следить за тем, что систему бесперебойно питают, не бьют молниями и не топят в море. ОСРВ гарантирует, что написанный по конкретным формализованным требованиям код в конкретных формализованных условиях исполняется за заранее известное время на протяжении своего жизненного цикла. И что никаких подлян от менеджеров памяти, свопов и оптимизаторов внезапно не возникнет. Если оборвали провода или студент наваял софт, который отожрал всю память за сутки, причём здесь ОСРВ?
abondarev Автор
23.02.2019 14:58очень профессиональный взгляд показан
Ну вот опять.
Профессионал — это человек получающий деньги за свою работу?
Или определение из википедии
Профессиона?л — человек, сделавший определённое занятие (дело) своей профессией; человек, ставший в какой-либо области деятельности высококлассным специалистом; хорошо подготовленный для работы в определённой сфере специалист, имеющий навыки, квалификацию, а при необходимости и допуск к выполнению обязанностей по своей специальности.
А вот это определение Вы считаете профессиональным?
И что никаких подлян от менеджеров памяти, свопов и оптимизаторов внезапно не возникнет.
Смешивал я софт и хард, исключительно для того чтобы показать, что в реальной жизни все сложнее, и допустимы различные трактования термина, важно чтобы эти трактовки не расходились между собой. опять отправлю к коментарию:
Понимание того, что есть система реального времени может различаться у исследователя и практика. Потому что им в их работе удобно другое чуть-чуть другое понимание этого термина. Хотя говорят они об одном и тоже объективном явлении.
cattheblack
23.02.2019 16:38+1Для меня профессиональная дискуссия — это когда используется точный, аргументированный и логически последовательный обмен мнениями с уточнением позиций дискутирующих, без использования всех этих психологических штук, наподобие подмены понятий или раздувания частного случая до закрывания им изначального предмета обсуждения.
Как пример, я считаю, что здесь произошла подмена понятия ОСРВ на СРВ, где СРВ сочетает в себе и ОС и ПО и железо и человеческий фактор. И я считаю, что ставить в вину ОС то, что существуют остальные факторы и аспекты законченной рабочей программно-аппаратной системы, функционирующей в реальном мире, неправомерно.
Если разделить эти понятия и говорить о системе в целом, а не об ОС, это, на мой взгляд, будет более профессионально.
И приношу извинения за то, что столь просторечно упомянул некоторые моменты, препятствующие детерминизму в ОС.abondarev Автор
23.02.2019 16:55Как пример, я считаю, что здесь произошла подмена понятия ОСРВ на СРВ, где СРВ сочетает в себе и ОС и ПО и железо и человеческий фактор. И я считаю, что ставить в вину ОС то, что существуют остальные факторы и аспекты законченной рабочей программно-аппаратной системы, функционирующей в реальном мире, неправомерно.
Скажем так, подмены не произошло, а была попытка показать, что в системе реального времени, все взаимосвязано.
Взять например приведенную цитату Таненбаума
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.
В ней говориться об операционных системах, потом о системах, потом о компьютерах (вычислителях).
И я задал вопрос, а где грань между этими терминами. И кто отвечает за конечный результат? Операционная система? Но Вы же сказали, что она не может отвечать. Как же тогда определить, что она реального времени? Я имею в виду как раз тот факт, что во всех случаях можно достичь детерменизма? Пьяных студентов не берем в расчет, это действительно было преувеличение!cattheblack
23.02.2019 17:08+1Я считаю, что ОС не может отвечать за всю систему, а только за свою «зону ответственности». За надёжность железа, например, отвечает не ОС, а разработчик железа, вооружённый соответствующими теориями, а надёжность системы в целом проистекает из всех этих факторов. Если позволите, народная аналогия: сломанная нога не даёт ходить, но за ходьбу отвечает куча систем, от мозга до ЖКТ (без сил не побегать). Так что ОСРВ можно считать необходимым но недостаточным условием СРВ.
abondarev Автор
23.02.2019 14:45хорошая статья про ОСРВ.
спасибо!
В заметке много обиды, субъективизма и воды
- Обиды? А где она собственно говоря? Я вроде не считаю себя обиженным!
- Воды? Что Вы под этим подразумеваете? Стиль изложения, ну давайте считать его пятничным обсуждением. Естетсвенно, когда публикую статью в каком то строго научном издании, стиль изложения другой.
- Субъективизма? Но я попытался давать везде ссылки и приводить разные мнения. То есть, естественно у меня есть субъективное мнение! Но я это понимаю, и по возможности стараюсь приводить объективные факты. А вот факт того, что тут есть обида, я бы сказал, является субъективным :)
no404error
23.02.2019 14:16Простите, но я не понимаю зачем вы вводите внешние непрогнозируемые факторы как неотъемлемую характеристику определяющую суть понятия. Таким образом можно нивелировать что угодно. Тавтология: «Оно существует так как задумано и делает то что задумано при заданных условиях.» Не вижу вины создателя или порочности системы, если косорукое чудовище выльет ведро воды в систему.
abondarev Автор
23.02.2019 14:20Ну, я ввожу факторы, пытаясь проанализировать определения, например, в первом комментарии указали, что должно быть must и absolute. Но если мы погружаем нашу систему в реальный мир, и это не сферический конь в вакууме, то нужно рассматривать и внешние факторы. Или я не прав?
cattheblack
23.02.2019 16:49Но эти слова относятся к ОС, а не к реальному миру. Пока все внешние факторы позволяют ОС функционировать, она их исполняет, но если в серверной пожар или ЭМИ от ядерного удара пролетел, это не показатель того, что «программа плохая, из-за неё всё не работает», как мне кажется.
abondarev Автор
23.02.2019 17:06это не показатель того, что «программа плохая, из-за неё всё не работает», как мне кажется.
Конечно нет, я такого и не говорил. Вообще не говорил, что какая то программа плохая!cattheblack
23.02.2019 17:13Прошу прощения, это фольклор из взаимодействия с пользователяями, не принимайте на свой счёт, пожалуйста!
sim31r
23.02.2019 22:42ОСРВ — это такая ОС, в которой корректность выполнения задачи характеризуется не только логической корректностью, но временем выполнения этой задачи.
Если временные рамки расширить до 16 мс, то ОСРВ вполне и Windows может стать по этому определению. Запустил тест, на чистой системе процесс со средним приоритетом из 10^6 раз получал управление всегда от ядра ОС. Только если браузер запускать, управление не возвращается периодически. Для сбора телеметрии, диспетчеризации и SCADA хватает с запасом.
Про требование в 1 микросекунду почитал с интересом. Мне кажется там конвейеры и кэш будет мешать, архитектура стандартных систем сама по себе не оптимизирована под такое время реакции. Зато оптимизированы микроконтроллеры, по прерыванию входят в подпрограмму за ~6 тактов процессора с аппаратными сохранением состояния в стек.besitzeruf
24.02.2019 03:35нет, не станет… бывало хоть раз, что вся система зависла? То есть винда не может выполнить условие лимита даже в 16мс (и больше)…
sim31r
24.02.2019 18:07Без причины система не зависала.
Только если запущен тяжелый посторонний код, браузер со множеством вкладок, где крутится мультимедийные приложения. В этом случае да, даже без зависания, ядро ОС может не возвращать управление 1-2 и даже более тиков системного таймера 64 Гц (15.6 мс). Вероятно потому, что мультимедийные драйверы имеют более высокий приоритет.
Но, конечно, так делать не нужно, это чисто исследовательский эксперимент. Если требуется быстродействие, лишние программы и процессы отключаются.
Вот здесь интересная статья
habr.com/ru/company/intel/blog/186998
Можно попробовать уменьшить интервал таймера до 0.5 мс, ценой увеличения энергопотребления и снижения быстродействия. В этом замечен SQL сервер и Chrome.arcman
24.02.2019 18:16Ну поэтому венда и десктопная ОС, а не ОСРВ.
У ОСРВ не должно быть причин для зависания.sim31r
25.02.2019 00:49Заряженная частица высокой энергии прилетит и будет повод для зависания. В датацентрах есть подробная статистика по ошибкам модулей памяти, например
habr.com/ru/post/171407
habr.com/ru/post/328370
Другое дело, если речь о превышении времени реакции системы, тут, конечно, требуется ОСРВ.
abondarev Автор
24.02.2019 18:29Можно попробовать уменьшить интервал таймера до 0.5 мс, ценой увеличения энергопотребления и снижения быстродействия.
Опять же, проблема с том какие задачи ставятся. Если Вам достаточно уменьшить интервал таймера, то может быть это и выход, но где гарантии, что SQL сервер не сделает такого же?sim31r
25.02.2019 00:51Гарантия только в отсутствии программ подобного рода и тестировании системы…
abondarev Автор
25.02.2019 10:52+1> Гарантия только в отсутствии программ подобного рода и тестировании системы…
Так я же говорю, в универсальной системе, да еще и закрытой, вы не можете гарантровать отсуствие программ, то есть вы не контроллируете все части. ОСРВ подразумевает подобный контроль. Даже если квант времени будет гораздо больше.
abondarev Автор
24.02.2019 18:25+1Не уверен, что Windows может считаться ОСРВ, хотя если посмотрите изначальную статью, в ней как раз приводится мнение, что для определенного класса задач, Windows вполне может подойти.
Но Windows может считаться ОСРВ, потому что конечно, речь идет об протяженности на все время работы, а то что у Вас не возникнет синий экран через пару лет, Вам очень трудно обеспечить. Ведь Вы по сути дела не контроллируете всю систему, в универсальной ситеме есть различные сервисы и нет гарантии, что вот сейчас этот сервис не решит что то сделать. Даннуу проблему, насколько я знаю, решали в WinCE и наследниках, но и там это далеко не полностью можно было контроллировать.
Кроме того, для того чтобы достичь характеристик реального времени, конечно нужны еще свойства, например, планировщик. Кто то упоминал про распределение памяти… и так далее.
Но в чем с Вами согласен, так это для различнох классов задач, требования могут меняться. В приведенном Вами классе задач ( SCADA), идут другим путем. Добавляют графические языки, которые, упрощая разработку, сильно уменьшают риск ошибки. Конечно для таких задач, время переключения может быть даже не 16мс, а больше. Все зависит от задачи!sim31r
25.02.2019 01:29то что у Вас не возникнет синий экран через пару лет, Вам очень трудно обеспечить
Ну тут уже вопрос о надежности. Изначально был вопрос о быстродействии и времени реакции. Второй вопрос о надежности. Есть, например, серверные ОС, которые обязаны работать годами без перезагрузки, высочайшая надежность без требований реального времени. У ОСРВ, по умолчанию, требование к высокой надежности и требование к быстрой реакции, так как второе без первого ни кому не нужно. Надежность в обоих случаях достигается в том числе длительным тестированием.
Обычная, десктопная ОС, конечно, может зависнуть, но у этого всегда будут какие-то причины. От аппаратных сбоев, до сетевых атак. Если отключить обновления, защитить сетевые интерфейсы, вероятность сбоев я бы оценил как 0.5% в год, при тестировании системы несколько месяцев предварительном. Возможно, для ОСРВ этой надежности мало. Наблюдал работу, например, на серверах видеонаблюдения, работают с 2005 года на обычных «офисных» конфигурациях, ОС самая дешевая из семейства Windows XP. Причина выхода из строя износ жестких дисков, разряд батарейки BIOS, остановка вентиляторов, аппаратные проблемы. Если аппаратных ошибок нет, утечки памяти нет в конфигурации рабочих программ, сеть защищена, ошибки не сыпятся в журнал, аптайм годами накручивается. Нет ни какой причины тому, чтобы какому-то процессу вызвать halt всей системы. Но опять же это не исключено, всё дело в вероятности, в любой системе есть вероятность зависания.
Синий экран при ошибках кстати включается опционально, в моих случаях удобней автоматическая перезагрузка, например, если сервер настолько старый, что электролиты потеряли емкость и начинаются аппаратные проблемы в работе какого-то второстепенного сервера на рабочем месте диспетчера.
Мне в данном случае как-раз и интересны предельные возможности применения стандартных ОС, на сколько они применимы и по надежности и при ограничении на время реакции.abondarev Автор
25.02.2019 10:55Изначально был вопрос о быстродействии и времени реакции.
Нет, Вы невнимательно читали статью. В статье о быстродействии сказано мало. Я это как раз и хотел показать, что вопрос ОСРВ не сводиться к быстродействию. А сводиться к предсказуемости! На одной из конференций OSDay, даже было сказано, что ОСРВ это не значит быстро, это значит медленно, но надежно. В прошлом маркетологи любили таблички со всякого рода быстродействием, но сейчас даже они как то поутихли!
abondarev Автор
25.02.2019 10:58Если отключить обновления, защитить сетевые интерфейсы, вероятность сбоев я бы оценил как 0.5% в год, при тестировании системы несколько месяцев предварительном.
Посмотрите изначальную статью, в ней про это написано
lingvo
24.02.2019 19:08Если временные рамки расширить до 16 мс, то ОСРВ вполне и Windows может стать по этому определению.
Ну в принципе да, но отдадите ли вы такой ОСРВ управление автомобилем, как, например, здесь?
Отключаем все лишние процесы и задачи, засовываем в IPC и поехали. Или не поехали?
Как вариант, можно взять что-то попроще — не автомобиль, а, например, защиту какого-нибудь мотора или технологического процесса.
sim31r
25.02.2019 00:29После сбора статистики, тестирования, можно отдать и управление автомобилем. Если система пройдет все тесты, наработку без сбоев в 10 000 часов, в чем может быть сложность? В любом случае требуется тестирование. Возможно, надежность будет выше, чем у человека. Люди тоже зависают, при инсульте, эпилепсии, например, вероятность есть всегда. И человек имеет достаточно высокую задержку, более 100 мс, сложные ситуации может и 1000 мс осмысливать, что далеко за нашим контекстом реального времени.
Зависают любые платформы, ни один код не исключает ошибки. Вот пример миллиардных убытков, подвело не железо, а ошибка в программе.
От полного зависания защищает сторожевой таймер, во многих случаях пользователи и не замечают перезагрузки устройства, если это микроконтроллер, он перезагружается микро и миллисекунды и «подхватывает» управление.
Вот примеры зависания бортовых компьютеров самолетов
тут зависание и действие пилотов привело к катастрофе (дополнительно перезагрузил по ошибке системы, которые трогать нельзя было)
www.scmp.com/news/asia/article/1693965/airasia-crash-investigators-focus-possible-computer-glitch-may-have-led
тут просто перезагрузка бортового компьютера в воздухе и продолжение полета
pikabu.ru/story/pilot_samoleta_aviakompanii_yamal_perezagruzil_kompyuter_pryamo_v_polete_5892115
Защита мотора делается на ПЛИС или микроконтроллере, слишком простая задача, не требующая вычислений сложных.
Лучший пример это все же автопилот на автомобиле, так как есть задача распознавания образов и тут явно необходима ОС и многоядерный процессор при требовании управления в реальном времени.
Даже с самолетами более спорные примеры, так как частично обездвиженный самолет может планировать некоторое время (120 км в примере планирование), а вот автомобиль не может такого себе позволить, но может экстренно остановится во многих случаях.
Сумбурно расписал, но тема интересная. И примеры применения ОСРВ и пределы применимости обычных ОС, Linux, Windows, MacOs для управления процессами в реальном времени, программные хаки (типа разгона таймера и частоты прерываний, отключения служб и оптимизация процессов), статистика и ограничения ОС, ядра. Мне такие материалы не попадались.abondarev Автор
25.02.2019 11:04Вы путаете системы реального времени, и быстродействие. ОСРВ не значит, быстрее (во многих случаях, как раз, медленнее, из за особенностей планирования), а значит предсказуемее!
sim31r
25.02.2019 11:59А количественные оценки есть предсказуемости? Ни разу не сталкивался с точной оценкой характеристик ОС, только на словах абстрактно.
abondarev Автор
25.02.2019 12:24точной оценкой характеристик ОС
так об этом и статья! Нет точных формулировок, что такое ОСРВ и быть не может. Для каждого случая есть свои требования, а в общем можно сказать, что ОСРВ предназначается для управления процессами сбой в которых может привести к серьезным (порой катастрофическим) последствиям и следовательно должна гарантировать некое предельное время.
Для разных задачь требования разные, например, для авионики, одни, а для управления моторами, другие.
Поэтому я предложил выделить одну вроде неоспоримую часть, в этих системах, у разработчика, должна быть возможность все контролировать, и именно он несет отвественность, за конечный результат.
lingvo
Я не могу считать себя экспертом по ОСРВ, но считаю экспертом по системам реального времени. И что мне сразу бросилось в статье в глаза — многовато поверхностной воды, без объяснения, что такое система, работающая в реальном времени. А ведь в определении ОСРВ от Таненбаума есть сама суть:
Обратите внимание на выделенные слова. Это в английском техническом языке требований определяет требование, которое никогда нельзя нарушать. Нет. Ни в 0.001% случаев, ни раз в 100 лет, ни при какой нагрузке — просто нельзя. При этом нас не интересует ни минимальное время, ни среднеарифметическое, а именно by a certain time — т.е. должно быть выполнено к такому-то времени и все, хоть весь мир упадет.
С этой точки зрения удивляют понятие "предсказуемость" — это свойство из статистики, но я же написал выше — у системы реального времени нет статистики. Вас не интересует среднее время отклика или еще что-то. Вас интересует только один параметр — максимально допустимое время реакции. Все.
Ну и удивляет дискутируя со знакомым по поводу систем реального времени. Так ведь в этом и суть ОСРВ — там есть планировщик, который имеет простой и доказательный автомат состояний, вызываемый опять же простой машиной состояний прерываний от таймера. Т.е. вы можете быть уверены, что ваше задание, которое должно выполняться каждые 10мс в следующий раз выполнится именно через 10мс, а не позднее, независимо от других заданий.
abondarev Автор
Спасибо. Совершенно согласен. Но как добиться в реальном мире чтобы вот на сто процентов, даже если мир рухнет?
Ну и куда девать людей которые считают, что система реального времени это время переключения 1мск?
Приведу цитату из комментария
Duduka
RTOS — система операций, которая отвечает за конечное и определенное время, выполнила она "эту операцию" или нет, если программа сделавшая запрос "кончилась" или кончился "мир", то RTOS не обязанна отвечать.
Так достаточно просто, или еще больше упростить?
abondarev Автор
лучше конечно еще упростить. Но можете прийти к моим тезисам: Это маркетинговый сленг, или ОСРВ вообще не существует :)
Ну как же так, ведь как раз обязана сказать, что то не так, может быть вызвать обработчик данной ситуации. А то у Вас получается, что синий экран смерти, это означает что система реального времени, ну она же не обязана отвечать!abondarev Автор
Еще хочу спросить, почему Вас удивляет дискусия?
Вот я привел отвалившийся провод, то есть сбой аппаратурыю Вот объясните как вы можете это гарантировать на 100 %. Попробую пояснить. Я занимался разработкой надежных систем, в том числе и на базе троирования. Используются в космосе, ну и других специфичных сферах. Вопрос, зачем этим заниматься, если можно гарантировать 100% время реакции? Нет, конечно, как и в любой реальной задаче, есть вероятность с которой у вас будет работать, наработка на отказ если хотите.
Поэтому система реального времени с приведенными Вами выделенными словами не может существовать (в реальном мире конечно). А приведенный Вами подход с использованием, статического планирования, только увеличивает данную вероятность!
lingvo
Скажем так, надеюсь вы меня поймете.
Давайте расценивать эту гарантию, как критерий работоспособности системы реального времени. Т.е. если система гарантирует время реакции — она работоспособна. Как только эта гарантия по каким-либо причинам не выполняется — например в результате сбоя железа или софта — система считается неработоспособной и должна быть отключена или переведена в безопасное состояние. Так пойдет?
Сразу отвечу на предыдущий вопрос — как добиться в реальном мире чтобы вот на сто процентов, даже если мир рухнет? Еще раз — никто не запрещает ОСРВ стать неисправной — вот так взять и поломаться, как ломается обычная электробритва. Критерий этой неисправности простой — время. Поэтому что делать в этом случае? Да очень просто — выходить в безопасный режим, переключаться на резервную систему — как хотите, вы неисправны.
А после этого, если у вас используется настоящая ОСРВ, бейте программиста палкой, пока не пофиксит баг, приведший к этому. Виноват тут чисто он, потому что ОСРВ дала ему возможность сделать все правильно, а он накосячил.
abondarev Автор
конечно, я Вас понимаю.
Согласитесь, что хоть и много поверхностного, но противоречий между статьей и вашим комментарием нет. Я привел цитату на которую Вы сослались. Но как раз хотел отметить, вот Вы говорите
Согласен, это описано в стандарте ARINC-653, должен быть монитор работоспособности и у разработчика должна быть возможность устанавливать обработчик всех возможных критичных ситуаций (а не просто перейти в безопасное состояние). Но это же Вы сказали категоричное, чего тут думать написано же must и absolute. И объясните тогда где здесь must а где absolute?
Arcuen
Можно сказать, что в RTOS есть гарантия исполнения определённого кода за определённое время. Причём особенно важно не столько время, за которое будет выполнен код, сколько само наличие этой жёсткой временной привязки.
abondarev Автор
Думаю ваша формулировка вполне допустима.
ведь когда идет речь о реальном времени, то мы говорим о времени, и действительно не о привязке. Точнее привязка должна быть к процессам которыми мы (система) управляем.
ssmac
(хочется высказаться в поддержку вашего конкретно этого ответа);
говоря о времени для нашей современной вычислительной техники, можно говорить о тактах, и даже лучше говорить о них, потому что наше время для самой системы — фактор абстрактный и внешний, и вообще переменный, её реальный константный квант времени — такт исполняющего её процессора (каким бы этот процессор ни был, механическим, биологическим, электронным, ...); значит надо гарантированно переключаться на какую-либо отдельную задачу за 1ктакт (или 1Мтакт, или 1Гтакт, и т.д.); задач по определению >1 (иначе нет нужды в этой системе, а в реальности задач обычно >>1), значит, кроме того, что надо выполнение какой-то задачи обязательно-регулярно подключать, надо её же выполнение и обязательно-регулярно прерывать, чтобы дать такты другим задачам (рассматриваем «идеальный» стартовый случай, в котором все задачи равноважны, равнообязанны и следовательно равноправны); из этого следует, что выполнение любой задачи придётся и надо прерывать даже в том случае, если сейчас ей не хватило даже одного последнего такта на выполнение критически важной функции «спасение_мира»; из этого уже надо выставлять требования и к самим задачам-процессам, если они хотят и должны быть завершёнными — то они сами должны укладывать свои кванты работы в выделяемые им кванты времени, система следить ещё и за этим не может; ос рв — это «светофор» для задач-потоков, и задачи не должны иметь возможности игнорировать этот «светофор», а систему не должно интересовать, что там каждая задача везёт и с какой скоростью движется («едет/бежит/идёт/ползёт»);
и исходя из этого маленького комплекса условий, мне видится как-то так, что система и задачи-процессы в ос рв должны проектироваться друг под друга, значит они становятся единым целым; значит (как изначально совершенно ясно и однозначно указал автор статьи), ос рв не может быть универсальной; ос рв может приблизиться к своему определению, только будучи спроектированной под конечный набор совершенно конкретных процессов-задач, при этом и система (как регуляторная надстройка), и любой процесс не имеют права мешать друг другу, иначе её реалтаймовость исчезнет как условность; ос рв едина со своими работающими во внешний мир прикладными задачами;
abondarev Автор
Да, приблизительно это я и имел в виду, но позволю заметить, что вот это я не утверждал
Я имел в виду скорее, что разработчик делает систему используя возможности ОСРВ. И от него зависит будет ли это система отвечать требованиям или нет. Хотя Ваш тезис тоже корректен, ведь действительно если делать для какого то набора задач, то упрощаются возможности для достижения поставленных целей. Например, если будет понятен алгоритм как действовать в данный случаях, и он будет зафиксирован в интерфейсе, то все будут знать правильный шаблон для решения задачи.
anger32
Позволю себе с Вами не немного согласиться.
Дело в том, что термин «абсолютно гарантирует» в контексте RTOS носит статистический характер. Западная наука (у нас в стране специалистов не более пары десятков) имеет классическое направление изучения RTOS — Response Time Analysis. В рамках этой дисциплины, как и ее предшественников, рассматривается совокупность критериев обеспечения отказоустойчивости ОСРВ при решении задач. Объектом исследования является RTOS и Networks (существенно реже Queue networks), предметом является анализ способности системы обеспечивать предсказуемую отказоустойчивость в контексте соблюдения deadline-ов всех задач.
В данном аспекте, рассматривая совокупность исполняющихся в ОСРВ задач реального времени (отделяя их от задач общего назначения, чьи deadline исходя из основных функций системы ничтожны), можно считать их параметры случайными. Таким образом, «абсолютно гарантировать» hard real-time любая отдельно взятая RTOS на конкретно взятом железе может лишь для определенного класса решаемых задач. Для отдельных классов процедур планирования известны теоретические пределы максимальной нагрузки, порождаемой совокупностью задач реального времени, в рамках которых ОС действительно является RTOS. В противном случае, можно утверждать, что на данном железе данная RTOS не может реализовать ожидаемый функционал и требуется либо пересмотр аппаратной части, либо внесение значимых изменений в конфигурацию системы.
lingvo
Сорри мало чего понял. Может объясните более простыми словами, что вы имели ввиду?
anger32
Если в 2-х словах, то практически то же самое, что вы написали в комментарии от 18:37, но со ссылкой на мат. аппарат.
Arcuen
Собирают данные по работе ОС, смотрят использование стека, тайминги вызовов, длительность выполнения функций и прочее. Некоторые заказчики сразу устанавливают границы с погрешностью, в пределах которой допустимы вариации. Если ограничения не соблюдены, то проводится анализ причин, попытки оптимизировать всё на программном уровне или использовать другой контроллер, например.
abondarev Автор
Тут нужно немного скоректировать. Есть механизмы которые позволяют провести
мы такие специально разрабатывали, но требуются внешние инструменты, с помощью которого измеряются параметры.
И еще очень важно, это только один вид исследований, динамические. Существует еще более строгий, статический метод. Когда проводиться верификация программы, ее статический анализ всех возможных состояний и так далее.
lingvo
Хмм, а я чё-то подумал про Rate Monotonic Scheduling.
abondarev Автор
Это только один из возможных подходов.
Постараюсь, привести пример где это не работает.
Например, вам нужно очень точно реагировать на событие. Сама реакция на событие занимает мало времени, но происходит в любой момент времени, соответсвенно статическое расписание разделов (по времени) невозможно составить, приходиться например использовать статические приоритеты. То есть данная задача имеет наивысший приоритет, он быстро выполняется и не мешает другим.
Думаю эту ситуацию Вы не предусмотрели изначально.
anger32
Все верно подумали, только RMA/RMS это совсем классическая классика, простейшая.