Pull to refresh

Comments 71

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


These systems must provide absolute guarantees that a certain action will occur by a certain time.

Обратите внимание на выделенные слова. Это в английском техническом языке требований определяет требование, которое никогда нельзя нарушать. Нет. Ни в 0.001% случаев, ни раз в 100 лет, ни при какой нагрузке — просто нельзя. При этом нас не интересует ни минимальное время, ни среднеарифметическое, а именно by a certain time — т.е. должно быть выполнено к такому-то времени и все, хоть весь мир упадет.


С этой точки зрения удивляют понятие "предсказуемость" — это свойство из статистики, но я же написал выше — у системы реального времени нет статистики. Вас не интересует среднее время отклика или еще что-то. Вас интересует только один параметр — максимально допустимое время реакции. Все.


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

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

Приведу цитату из комментария
Понимание того, что есть система реального времени может различаться у исследователя и практика. Потому что им в их работе удобно другое чуть-чуть другое понимание этого термина. Хотя говорят они об одном и тоже объективном явлении.

RTOS — система операций, которая отвечает за конечное и определенное время, выполнила она "эту операцию" или нет, если программа сделавшая запрос "кончилась" или кончился "мир", то RTOS не обязанна отвечать.
Так достаточно просто, или еще больше упростить?

лучше конечно еще упростить. Но можете прийти к моим тезисам: Это маркетинговый сленг, или ОСРВ вообще не существует :)

если программа сделавшая запрос «кончилась» или кончился «мир», то RTOS не обязанна отвечать.
Ну как же так, ведь как раз обязана сказать, что то не так, может быть вызвать обработчик данной ситуации. А то у Вас получается, что синий экран смерти, это означает что система реального времени, ну она же не обязана отвечать!
Еще хочу спросить, почему Вас удивляет дискусия?
Вот я привел отвалившийся провод, то есть сбой аппаратурыю Вот объясните как вы можете это гарантировать на 100 %. Попробую пояснить. Я занимался разработкой надежных систем, в том числе и на базе троирования. Используются в космосе, ну и других специфичных сферах. Вопрос, зачем этим заниматься, если можно гарантировать 100% время реакции? Нет, конечно, как и в любой реальной задаче, есть вероятность с которой у вас будет работать, наработка на отказ если хотите.

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

Скажем так, надеюсь вы меня поймете.
Давайте расценивать эту гарантию, как критерий работоспособности системы реального времени. Т.е. если система гарантирует время реакции — она работоспособна. Как только эта гарантия по каким-либо причинам не выполняется — например в результате сбоя железа или софта — система считается неработоспособной и должна быть отключена или переведена в безопасное состояние. Так пойдет?


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

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

Согласен, это описано в стандарте ARINC-653, должен быть монитор работоспособности и у разработчика должна быть возможность устанавливать обработчик всех возможных критичных ситуаций (а не просто перейти в безопасное состояние). Но это же Вы сказали категоричное, чего тут думать написано же must и absolute. И объясните тогда где здесь must а где absolute?
Можно сказать, что в RTOS есть гарантия исполнения определённого кода за определённое время. Причём особенно важно не столько время, за которое будет выполнен код, сколько само наличие этой жёсткой временной привязки.
Думаю ваша формулировка вполне допустима.
ведь когда идет речь о реальном времени, то мы говорим о времени, и действительно не о привязке. Точнее привязка должна быть к процессам которыми мы (система) управляем.
(хочется высказаться в поддержку вашего конкретно этого ответа);

говоря о времени для нашей современной вычислительной техники, можно говорить о тактах, и даже лучше говорить о них, потому что наше время для самой системы — фактор абстрактный и внешний, и вообще переменный, её реальный константный квант времени — такт исполняющего её процессора (каким бы этот процессор ни был, механическим, биологическим, электронным, ...); значит надо гарантированно переключаться на какую-либо отдельную задачу за 1ктакт (или 1Мтакт, или 1Гтакт, и т.д.); задач по определению >1 (иначе нет нужды в этой системе, а в реальности задач обычно >>1), значит, кроме того, что надо выполнение какой-то задачи обязательно-регулярно подключать, надо её же выполнение и обязательно-регулярно прерывать, чтобы дать такты другим задачам (рассматриваем «идеальный» стартовый случай, в котором все задачи равноважны, равнообязанны и следовательно равноправны); из этого следует, что выполнение любой задачи придётся и надо прерывать даже в том случае, если сейчас ей не хватило даже одного последнего такта на выполнение критически важной функции «спасение_мира»; из этого уже надо выставлять требования и к самим задачам-процессам, если они хотят и должны быть завершёнными — то они сами должны укладывать свои кванты работы в выделяемые им кванты времени, система следить ещё и за этим не может; ос рв — это «светофор» для задач-потоков, и задачи не должны иметь возможности игнорировать этот «светофор», а систему не должно интересовать, что там каждая задача везёт и с какой скоростью движется («едет/бежит/идёт/ползёт»);

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

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

These systems must provide absolute guarantees that a certain action will occur by a certain time.

Дело в том, что термин «абсолютно гарантирует» в контексте RTOS носит статистический характер. Западная наука (у нас в стране специалистов не более пары десятков) имеет классическое направление изучения RTOS — Response Time Analysis. В рамках этой дисциплины, как и ее предшественников, рассматривается совокупность критериев обеспечения отказоустойчивости ОСРВ при решении задач. Объектом исследования обычно являются RTOS и Networks (существенно реже Queue networks), предметом является анализ способности системы обеспечивать предсказуемую отказоустойчивость в контексте соблюдения deadline-ов всех задач реального времени.

В данном аспекте, рассматривая совокупность исполняющихся в ОСРВ задач реального времени (отделяя их от задач общего назначения, чьи deadline исходя из основных функций системы ничтожны), можно считать их параметры случайными. Таким образом, «абсолютно гарантировать» hard real-time любая отдельно взятая RTOS на конкретно взятом железе может лишь для определенного класса заложенных при проектировании функций. Для отдельных классов процедур планирования известны теоретические пределы максимальной нагрузки, порождаемой совокупностью задач реального времени, в рамках которых ОС действительно является RTOS. В противном случае, можно утверждать, что на данном железе данная RTOS не может реализовать ожидаемый функционал и требуется либо пересмотр аппаратной части, либо внесение значимых изменений в конфигурацию системы. Альтернативно делается вывод о неспособности данной RTOS реализовать требуемую функцию.

Сорри мало чего понял. Может объясните более простыми словами, что вы имели ввиду?

Если в 2-х словах, то практически то же самое, что вы написали в комментарии от 18:37, но со ссылкой на мат. аппарат.
Собирают данные по работе ОС, смотрят использование стека, тайминги вызовов, длительность выполнения функций и прочее. Некоторые заказчики сразу устанавливают границы с погрешностью, в пределах которой допустимы вариации. Если ограничения не соблюдены, то проводится анализ причин, попытки оптимизировать всё на программном уровне или использовать другой контроллер, например.
Тут нужно немного скоректировать. Есть механизмы которые позволяют провести
использование стека, тайминги вызовов, длительность выполнения функций и прочее

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

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

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

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

А вот если бы вы в методологическую базу своего эксперимента включили такие положения, как:
— любое сочетание внешних событий в оговоренных фиксированных границах (дополнительные внешние источники прерываний);
— любое сочетание внутренних событий в оговоренных фиксированных границах (aka имитация вычислительной и операционной нагрузки);
— четко очерченный диапазон реалтаймовых задач и задач общего назначения (при четко заданных диапазонах случайных параметров);
— производили замеры как в контексте ISR, так и в контексте не привилегированного кода;
— производили статистическую обработку худших, средних и лучших замеров посредством внешних измерительных приборов;

Можно было бы говорить о том, что результаты у вас хоть на что-то претендуют кроме маркетинга. И в данном случае пенять на компетенцию некоего сферического заказчика совсем не дело. Заказчик совершенно не обязан быть специалистом в этом вопросе. Практика показывает, что как раз он обычно таковым не является.
Про испытания Embox я сознательно утрировал!
Приведенный эксперимерт проводился в условиях сетевой активности, загружался некими вычислительными задачами, хоть и более низкого приоритета чем исследуемая, статистику собирали внешним осцилографом, в условиях разных воздействий. Но сути дела это не меняет. Но вот приведенных в первом комментарии 100% или must и absolute конечно не было. И я честно говорил заказчику, ну и здесь. Что нужно более честко формулировать критерии термина real-time.
Про испытания Embox я сознательно утрировал!

Ок.

Но вот приведенных в первом комментарии 100% или must и absolute конечно не было.

Но вы ведь не будете спорить с тем, что доказательство принадлежности ОС к ОСРВ не есть обязанность потребителя. Поиск доказательной базы в данном аспекте задача весьма нетривиальная. Настолько, что некоторые вендоры реально ее не решали и апеллируют к статистическому критерию вида «наработка на отказ в режиме РВ в объеме стольки-то машино-веков».
Но вы ведь не будете спорить с тем, что доказательство принадлежности ОС к ОСРВ не есть обязанность потребителя.

Не всегда. Хорошо если есть критерии для задач потребителя. Например, авионика с ARINC-653, но если нет, а задача серьезная, то решать ее нужно. Приведенный в статье анализ лаборатории, был для АЭС. И прежде чем разрабатывать ПО им нужно было выбрать платформу. В данном случае, Embox не участвовал в исследовании, если что.

Поиск доказательной базы в данном аспекте задача весьма нетривиальная. Настолько, что некоторые вендоры реально ее не решали и апеллируют к статистическому критерию вида «наработка на отказ в режиме РВ в объеме стольки-то машино-веков»


Вот тут абсолютно согласен. и более того считаю что это правильно, с поправкой на решаемую задачу конечно. Нужно же дать потребителю, какие нибудь намеки на правильное решение, а то поставят обычную систему с косынкой на какую нибудь турбину, а потом удивляются, что вроде работала работала, и вот опять!
В заметке много обиды, субъективизма и воды. Если все это убрать вполне может получиться хорошая статья про ОСРВ.
Добавлю, что в комментариях весьма странная дискуссия, не очень профессиональный взгляд показан. Как можно смешивать понятия софта и харда в одном флаконе? ОС, именно ОС РВ никак не обязана следить за тем, что систему бесперебойно питают, не бьют молниями и не топят в море. ОСРВ гарантирует, что написанный по конкретным формализованным требованиям код в конкретных формализованных условиях исполняется за заранее известное время на протяжении своего жизненного цикла. И что никаких подлян от менеджеров памяти, свопов и оптимизаторов внезапно не возникнет. Если оборвали провода или студент наваял софт, который отожрал всю память за сутки, причём здесь ОСРВ?
очень профессиональный взгляд показан

Ну вот опять.

Профессионал — это человек получающий деньги за свою работу?

Или определение из википедии
Профессиона́л — человек, сделавший определённое занятие (дело) своей профессией; человек, ставший в какой-либо области деятельности высококлассным специалистом; хорошо подготовленный для работы в определённой сфере специалист, имеющий навыки, квалификацию, а при необходимости и допуск к выполнению обязанностей по своей специальности.


А вот это определение Вы считаете профессиональным?
И что никаких подлян от менеджеров памяти, свопов и оптимизаторов внезапно не возникнет.


Смешивал я софт и хард, исключительно для того чтобы показать, что в реальной жизни все сложнее, и допустимы различные трактования термина, важно чтобы эти трактовки не расходились между собой. опять отправлю к коментарию:
Понимание того, что есть система реального времени может различаться у исследователя и практика. Потому что им в их работе удобно другое чуть-чуть другое понимание этого термина. Хотя говорят они об одном и тоже объективном явлении.
Для меня профессиональная дискуссия — это когда используется точный, аргументированный и логически последовательный обмен мнениями с уточнением позиций дискутирующих, без использования всех этих психологических штук, наподобие подмены понятий или раздувания частного случая до закрывания им изначального предмета обсуждения.
Как пример, я считаю, что здесь произошла подмена понятия ОСРВ на СРВ, где СРВ сочетает в себе и ОС и ПО и железо и человеческий фактор. И я считаю, что ставить в вину ОС то, что существуют остальные факторы и аспекты законченной рабочей программно-аппаратной системы, функционирующей в реальном мире, неправомерно.
Если разделить эти понятия и говорить о системе в целом, а не об ОС, это, на мой взгляд, будет более профессионально.
И приношу извинения за то, что столь просторечно упомянул некоторые моменты, препятствующие детерминизму в ОС.
Как пример, я считаю, что здесь произошла подмена понятия ОСРВ на СРВ, где СРВ сочетает в себе и ОС и ПО и железо и человеческий фактор. И я считаю, что ставить в вину ОС то, что существуют остальные факторы и аспекты законченной рабочей программно-аппаратной системы, функционирующей в реальном мире, неправомерно.

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

Взять например приведенную цитату Таненбаума
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.

В ней говориться об операционных системах, потом о системах, потом о компьютерах (вычислителях).
И я задал вопрос, а где грань между этими терминами. И кто отвечает за конечный результат? Операционная система? Но Вы же сказали, что она не может отвечать. Как же тогда определить, что она реального времени? Я имею в виду как раз тот факт, что во всех случаях можно достичь детерменизма? Пьяных студентов не берем в расчет, это действительно было преувеличение!
Я считаю, что ОС не может отвечать за всю систему, а только за свою «зону ответственности». За надёжность железа, например, отвечает не ОС, а разработчик железа, вооружённый соответствующими теориями, а надёжность системы в целом проистекает из всех этих факторов. Если позволите, народная аналогия: сломанная нога не даёт ходить, но за ходьбу отвечает куча систем, от мозга до ЖКТ (без сил не побегать). Так что ОСРВ можно считать необходимым но недостаточным условием СРВ.
хорошая статья про ОСРВ.

спасибо!

В заметке много обиды, субъективизма и воды

  • Обиды? А где она собственно говоря? Я вроде не считаю себя обиженным!
  • Воды? Что Вы под этим подразумеваете? Стиль изложения, ну давайте считать его пятничным обсуждением. Естетсвенно, когда публикую статью в каком то строго научном издании, стиль изложения другой.
  • Субъективизма? Но я попытался давать везде ссылки и приводить разные мнения. То есть, естественно у меня есть субъективное мнение! Но я это понимаю, и по возможности стараюсь приводить объективные факты. А вот факт того, что тут есть обида, я бы сказал, является субъективным :)
Простите, но я не понимаю зачем вы вводите внешние непрогнозируемые факторы как неотъемлемую характеристику определяющую суть понятия. Таким образом можно нивелировать что угодно. Тавтология: «Оно существует так как задумано и делает то что задумано при заданных условиях.» Не вижу вины создателя или порочности системы, если косорукое чудовище выльет ведро воды в систему.
Ну, я ввожу факторы, пытаясь проанализировать определения, например, в первом комментарии указали, что должно быть must и absolute. Но если мы погружаем нашу систему в реальный мир, и это не сферический конь в вакууме, то нужно рассматривать и внешние факторы. Или я не прав?
Но эти слова относятся к ОС, а не к реальному миру. Пока все внешние факторы позволяют ОС функционировать, она их исполняет, но если в серверной пожар или ЭМИ от ядерного удара пролетел, это не показатель того, что «программа плохая, из-за неё всё не работает», как мне кажется.
это не показатель того, что «программа плохая, из-за неё всё не работает», как мне кажется.

Конечно нет, я такого и не говорил. Вообще не говорил, что какая то программа плохая!
Прошу прощения, это фольклор из взаимодействия с пользователяями, не принимайте на свой счёт, пожалуйста!
ОСРВ — это такая ОС, в которой корректность выполнения задачи характеризуется не только логической корректностью, но временем выполнения этой задачи.

Если временные рамки расширить до 16 мс, то ОСРВ вполне и Windows может стать по этому определению. Запустил тест, на чистой системе процесс со средним приоритетом из 10^6 раз получал управление всегда от ядра ОС. Только если браузер запускать, управление не возвращается периодически. Для сбора телеметрии, диспетчеризации и SCADA хватает с запасом.
Про требование в 1 микросекунду почитал с интересом. Мне кажется там конвейеры и кэш будет мешать, архитектура стандартных систем сама по себе не оптимизирована под такое время реакции. Зато оптимизированы микроконтроллеры, по прерыванию входят в подпрограмму за ~6 тактов процессора с аппаратными сохранением состояния в стек.
нет, не станет… бывало хоть раз, что вся система зависла? То есть винда не может выполнить условие лимита даже в 16мс (и больше)…
Без причины система не зависала.
Только если запущен тяжелый посторонний код, браузер со множеством вкладок, где крутится мультимедийные приложения. В этом случае да, даже без зависания, ядро ОС может не возвращать управление 1-2 и даже более тиков системного таймера 64 Гц (15.6 мс). Вероятно потому, что мультимедийные драйверы имеют более высокий приоритет.
Но, конечно, так делать не нужно, это чисто исследовательский эксперимент. Если требуется быстродействие, лишние программы и процессы отключаются.
Вот здесь интересная статья
habr.com/ru/company/intel/blog/186998
Можно попробовать уменьшить интервал таймера до 0.5 мс, ценой увеличения энергопотребления и снижения быстродействия. В этом замечен SQL сервер и Chrome.
Ну поэтому венда и десктопная ОС, а не ОСРВ.
У ОСРВ не должно быть причин для зависания.
Заряженная частица высокой энергии прилетит и будет повод для зависания. В датацентрах есть подробная статистика по ошибкам модулей памяти, например
habr.com/ru/post/171407
habr.com/ru/post/328370
Другое дело, если речь о превышении времени реакции системы, тут, конечно, требуется ОСРВ.
а венда видимо зависает только поймав заряженную частицу, да?
это уже аппаратный отказ, отказоустойчивая ОС может попытаться его детектировать и исправить, но не факт что это будет возможно.
Можно попробовать уменьшить интервал таймера до 0.5 мс, ценой увеличения энергопотребления и снижения быстродействия.

Опять же, проблема с том какие задачи ставятся. Если Вам достаточно уменьшить интервал таймера, то может быть это и выход, но где гарантии, что SQL сервер не сделает такого же?
Гарантия только в отсутствии программ подобного рода и тестировании системы…
> Гарантия только в отсутствии программ подобного рода и тестировании системы…
Так я же говорю, в универсальной системе, да еще и закрытой, вы не можете гарантровать отсуствие программ, то есть вы не контроллируете все части. ОСРВ подразумевает подобный контроль. Даже если квант времени будет гораздо больше.
спасибо!
ps ещё с ходу пара засранцев под виндой:
AIMP Player
Telegram Desktop

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

Но Windows может считаться ОСРВ, потому что конечно, речь идет об протяженности на все время работы, а то что у Вас не возникнет синий экран через пару лет, Вам очень трудно обеспечить. Ведь Вы по сути дела не контроллируете всю систему, в универсальной ситеме есть различные сервисы и нет гарантии, что вот сейчас этот сервис не решит что то сделать. Даннуу проблему, насколько я знаю, решали в WinCE и наследниках, но и там это далеко не полностью можно было контроллировать.
Кроме того, для того чтобы достичь характеристик реального времени, конечно нужны еще свойства, например, планировщик. Кто то упоминал про распределение памяти… и так далее.

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

Ну тут уже вопрос о надежности. Изначально был вопрос о быстродействии и времени реакции. Второй вопрос о надежности. Есть, например, серверные ОС, которые обязаны работать годами без перезагрузки, высочайшая надежность без требований реального времени. У ОСРВ, по умолчанию, требование к высокой надежности и требование к быстрой реакции, так как второе без первого ни кому не нужно. Надежность в обоих случаях достигается в том числе длительным тестированием.
Обычная, десктопная ОС, конечно, может зависнуть, но у этого всегда будут какие-то причины. От аппаратных сбоев, до сетевых атак. Если отключить обновления, защитить сетевые интерфейсы, вероятность сбоев я бы оценил как 0.5% в год, при тестировании системы несколько месяцев предварительном. Возможно, для ОСРВ этой надежности мало. Наблюдал работу, например, на серверах видеонаблюдения, работают с 2005 года на обычных «офисных» конфигурациях, ОС самая дешевая из семейства Windows XP. Причина выхода из строя износ жестких дисков, разряд батарейки BIOS, остановка вентиляторов, аппаратные проблемы. Если аппаратных ошибок нет, утечки памяти нет в конфигурации рабочих программ, сеть защищена, ошибки не сыпятся в журнал, аптайм годами накручивается. Нет ни какой причины тому, чтобы какому-то процессу вызвать halt всей системы. Но опять же это не исключено, всё дело в вероятности, в любой системе есть вероятность зависания.
Синий экран при ошибках кстати включается опционально, в моих случаях удобней автоматическая перезагрузка, например, если сервер настолько старый, что электролиты потеряли емкость и начинаются аппаратные проблемы в работе какого-то второстепенного сервера на рабочем месте диспетчера.
Мне в данном случае как-раз и интересны предельные возможности применения стандартных ОС, на сколько они применимы и по надежности и при ограничении на время реакции.
Изначально был вопрос о быстродействии и времени реакции.

Нет, Вы невнимательно читали статью. В статье о быстродействии сказано мало. Я это как раз и хотел показать, что вопрос ОСРВ не сводиться к быстродействию. А сводиться к предсказуемости! На одной из конференций OSDay, даже было сказано, что ОСРВ это не значит быстро, это значит медленно, но надежно. В прошлом маркетологи любили таблички со всякого рода быстродействием, но сейчас даже они как то поутихли!
Если отключить обновления, защитить сетевые интерфейсы, вероятность сбоев я бы оценил как 0.5% в год, при тестировании системы несколько месяцев предварительном.

Посмотрите изначальную статью, в ней про это написано
Если временные рамки расширить до 16 мс, то ОСРВ вполне и Windows может стать по этому определению.

Ну в принципе да, но отдадите ли вы такой ОСРВ управление автомобилем, как, например, здесь?


Отключаем все лишние процесы и задачи, засовываем в IPC и поехали. Или не поехали?


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

После сбора статистики, тестирования, можно отдать и управление автомобилем. Если система пройдет все тесты, наработку без сбоев в 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 для управления процессами в реальном времени, программные хаки (типа разгона таймера и частоты прерываний, отключения служб и оптимизация процессов), статистика и ограничения ОС, ядра. Мне такие материалы не попадались.
Вы путаете системы реального времени, и быстродействие. ОСРВ не значит, быстрее (во многих случаях, как раз, медленнее, из за особенностей планирования), а значит предсказуемее!
А количественные оценки есть предсказуемости? Ни разу не сталкивался с точной оценкой характеристик ОС, только на словах абстрактно.
точной оценкой характеристик ОС

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

Конечно. Как пример:
http://www.yodaiken.com/papers/VxWorks_RTLinux_PerfomanceData.pdf


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

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

Чтобы вы понимали средняя наработка на отказ человека составляет 1 миллион часов. Процессорной системе для такой наработки требуется аппаратное дублирование, как минимум.


Вот примеры зависания бортовых компьютеров самолетов
тут зависание и действие пилотов привело к катастрофе (дополнительно перезагрузил по ошибке системы, которые трогать нельзя было)
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

И это заметьте встроенные системы под управление ОСРВ. Представьте, если бы там был Windows.


Сумбурно расписал, но тема интересная. И примеры применения ОСРВ и пределы применимости обычных ОС, Linux, Windows, MacOs для управления процессами в реальном времени, программные хаки (типа разгона таймера и частоты прерываний, отключения служб и оптимизация процессов), статистика и ограничения ОС, ядра. Мне такие материалы не попадались

Можете глянуть на попытки запустить Codesys на Linux на Raspberry Pi с расширениями RT Linux. Там джиттер меряют в сотни микросекунд.

Чтобы вы понимали средняя наработка на отказ человека составляет 1 миллион часов. Процессорной системе для такой наработки требуется аппаратное дублирование, как минимум.

114 лет? Нет такого. Непрерывная нагруженная работа от 60 минут до 8 часов, в зависимости от нагрузки, далее аналог технического обслуживания с «перезагрузкой». Экипаж самолета тоже дублирован и троирован, один человек не надежен.
Вероятность инсульта/инфаркта 0.5% в год, часто в самое неподходящее время (значительный процент ДТП из-за этого, когда машина без причин уходит на встречку и делает фарш на дороге). После 60 лет вероятность уже 10% в год, речи о надежности нет вообще.
Для людей есть термин «человеческий фактор» на который списывается вообще всё, так же надежность не велика. Поэтому, в самолетах, например, по 2-3 члена экипажа, и то это не спасает на 100%, вот примеры, причем это всё с учетом высочайших требований и самого жесткого отбора персонала, один на тысячу такой отбор проходит, остальные еще менее «стабильные».
И пример с оборудованием, какой-нибудь сервер работающий с 2006 года по наши дни (даже может быть без серверной ОС). Надежность, производительность не сопоставима. Даже дублирование не обязательно, надежность устраивает и та что есть.
И это заметьте встроенные системы под управление ОСРВ. Представьте, если бы там был Windows.

Представлять не нужно, он используется и на более важных объектах:
xakep.ru/2004/10/27/24468
Трафальгар — атомная подводная лодка если что. И таких объектов много.

Можете глянуть на попытки запустить Codesys на Linux на Raspberry Pi с расширениями RT Linux. Там джиттер меряют в сотни микросекунд.


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

С Линуксом, конечно, будут проблемы, и надежность такого решения может быть даже ниже:
  • Приложения реального времени выполняются в пространстве ядра, следовательно, они могут переписать часть памяти ядра и сломать систему
  • Взаимодействие между RT-подсистемой и Linux не может быть реального времени
  • Ядро Linux выполняется в бэкграунде, следовательно, задачи Linux могут испытывать большие задержки
  • Невозможно использовать драйверы Linux в задачах реального времени, следовательно, разработчики приложений реального времени вынуждены переписывать драйверы устройств поверх RT-подсистемы
Представлять не нужно, он используется и на более важных объектах:
xakep.ru/2004/10/27/24468
Трафальгар — атомная подводная лодка если что. И таких объектов много.

В ПО бортовых компьютеров, аналогичных самолетным, как вы написали до этого?


Джиттер это еще более высокое требование.

Это не требование, это просто один из способов измерить реалтаймовость ОС косвенным путем. Меньший джиттер между вызовами одного таска позволяет полагать, что планировщик более или менее все делает за одно и то же время и следовательно с большей вероятностью там не вызываются всякие уборщики мусора или динамическое выделение памяти. В выше приведенном примере с Windows и 16мс — ОС-то может быть и вызвала таск 225 тысяч раз за час, но сколько времени проходило между вызовами — неизвестно и тоже влияет на реалтаймовость.

В ПО бортовых компьютеров, аналогичных самолетным, как вы написали до этого?

А тут интересно. Что вообще делает компьютер в самолетах, крейсерах и АПЛ? Управляет исполнительными органами напрямую, или помогает задавать параметры для специализированного оборудования нижнего уровня?
Возможно пилот может выключить экран и перейти на ручное управление по старинке. Везде же по разному. В одном из примеров перезагрузили бортовой компьютер и дальше полетели, ничего не произошло.
Вот у нас пример, SCADA управляет системой теплоснабжения города. Помогает диспетчеру управлять удаленно всем, без бегания по котельным и прочим объектам. Если SCADA выходит из строя, ПЛК на объектах продолжают работать с ранее выбранными режимами, поддерживать ранее установленные температуры. Просто пропадает аварийная сигнализация и возможность корректировать режимы работы. Несколько часов система проработает без присмотра диспетчера гарантированно. Локально замкнутый контур управления через ПИД регулятор, если выбрана уставка на определенную температуру, регулятор будет её поддерживать вечно, там достаточно умная автоматика.
В итоге на ОСРВ можно возложить множество задач, от сбора телеметрических данных, до полного управления всем, исполнительными механизмами. Что сделано в каждом случае мы не знаем.
один из способов измерить реалтаймовость ОС

Надо попробовать, слать байт данных на микроконтроллер через Ethernet или COM порт и смотреть время приема. Интересно будет на разных ОС посмотреть и на разных процессорах.

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


Вообще это есть один из критериев применимости ОСРВ: если связь с внешним миром — датчиками, актуаторами и т.д. сделана на основе реал-таймовых интерфейсов — полевых шин, которые гарантируют латентность, например EtherCAT, то ОСРВ сможет выполнить свою задачу.
Но если изначально внешние интерфейсы уже сделаны без использования детерминированных интерфейсов,(т.е. например используется Ethernet, TCP/IP и прочее), то применение ОСРВ теряет смысл — вы не сделаете лучше, чем самый худший из ваших интерфейсов.


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

то даже если он будет задавать курс подлодки в градусах, на нем нет смысла использовать ОСРВ, а может быть достаточно и Windows

теперь реально страшно :)
теперь реально страшно :)

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

Реально там должно быть несколько рабочих станций с каждой из которых можно задавать курс.

Ну а как узнать, что какая то рабочая станция сошла с ума и задает совсем неверный курс?

В приведенной Вами ссылке, на мой взгляд, содержиться намек, на то что отвественные системы не должны быть перегруженны, а должны быть минимально простыми.
Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать. © Антуан де Сент-Экзюпери
А в Windows убрать можно ух как много :)
Ну а как узнать, что какая то рабочая станция сошла с ума и задает совсем неверный курс?

Ну в данном контексте не могу сказать, но ОСРВ тут точно не поможет.

Ну в данном контексте не могу сказать, но ОСРВ тут точно не поможет.

Если считать что это обеспечивает быстрое время реакции, то согласен, не поможет. А если говорить о предсказуемости, то…
ОСРВ тоже не предел минимализма. Кому нужна 100% предсказуемость, берут микроконтроллер типа STM32F7 и полностью с нуля делают под себя систему. Своя материнская плата, своя программа без ОС, рисуют кнопочки на сенсорном экране программно на С++, даже сторонние библиотеки по минимуму используют. Микроконтроллер же и есть по сути аппаратная ОС, со множеством прерываний, у каждого прерывания свой приоритет, очень быстрый переход между прерываниями, аппаратная поддержка DMA и много чего еще. Одноядерные в основном все, но есть и многоядерная экзотика.
Вот пример такого подхода, основательность подхода автора впечатляет, ему нужно чтобы станок-конвейер работал предсказуемо, поэтому пишут всё сам
www.youtube.com/watch?v=vLYIKcPjGwg
Кому нужна 100% предсказуемость, берут микроконтроллер типа STM32F7 и полностью с нуля делают под себя систему.

… и тратят на разработку три года и несколько человеко-лет. Особенно «выгодно», если при этом надо выпустить всего десяток изделий.
А умные люди для предсказуемости придумали ПЛК.

Не всегда ПЛК подходят, есть ограничения по функциям, быстродействию, интерфейсам. Если что-то простое, управление насосами, лифтами, тут да, ПЛК нормально подходят, а ограничения программные дают стабильность алгоритму.
Вот пример, когда несколько рабочих станций диспетчера были точкой входа для хакеров, что уничтожили всё что можно было уничтожить программно. Тип ОС тут, конечно, не при чем, только права доступа актуальны.
Ну и авиакатастрофа под Казанью похожа на то, что с кораблями было. Очень странное управление пилотами, необъяснимые ошибки пилотов. Думали что автопилот включен?

Я бы предложил такую формулировку — ОСРВ существуют, есть существенная теория и практика их применения, однако во многих случаях их необходимость переоценивается заказчиком и тема оказывается популярной, вследствие чего существует также и обывательская дискуссия. Эта дискуссия идёт также и на технических форумах (и на Хабре в том числе), в ней участвуют многие сочувствующие, и спекуляциям несть числа. Ответ же на поставленный вами вопрос знаете только вы и ваши аудиторы.

ОСРВ существуют

С этим трудно не согласиться.

Ответ же на поставленный вами вопрос знаете только вы и ваши аудиторы.

Вопрос из названия статьи ставился в общем, а не только для Embox. И если кто то знает ответ, то почему этим знанием не поделяться с миром. В статье я попытался показать, что может быть разные трактовки данного термина для разного типа задач. И соотвественно нужно уточнять терминалогию, чтобы говорить на одном языке.
Sign up to leave a comment.