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

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

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


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


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

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

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

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

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

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

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

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

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

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

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


    Теперь введу термин “Операционная система реального времени”. Хотя нет, лучше не буду. Дело в том, что определений данного термина большое количество. Возьмем хотя бы комментарии к изначальной статье:
    В системах реального времени человек вообще лишний и, соответственно, быстродействие системы реального времени должно сравниваться с процессами, которыми она управляет, будь то автономный автомобиль или система управления технологическим процессом на заводе.
    СРВ/ОСРВ — это исключительно ранжирование по предсказуемости реагирования на критические события.
    ОСРВ — это такая ОС, в которой корректность выполнения задачи характеризуется не только логической корректностью, но временем выполнения этой задачи.
    Поставьте критерием время переключения контекста любой задачи в 1 мкс на 100 МГц процессоре с float-point сопроцессором с детерминированностью в 0.1 мкс и все станет на свои места.
    Вы четко увидите где RTOS, а где нет.
    Ну, и, не могу обойти стороной мнение, о котором я рассказал в статье, прозвучавшее на одной из конференций OSDAY:
    Система может считаться системой жесткого реального времени, если в ней нет мест, где при залоченных прерываниях, есть циклы с неизвестным числом итераций.
    Но может это все просто частности, и как предложили в комментарии стоит просто использовать классиков и не придумывать велосипеды. Приведу указанного классика (Эндрю Таненбаума, если кто-то не догадался):
    «Another type of operating system is the real-time system. These systems are characterized by having time as a key parameter. For example, in industrial process control systems, real-time computers have to collect data about the production process and use it to control machines in the factory. Often there are hard deadlines that must be met. For example, if a car is moving down an assembly line, certain actions must take place at certain instants of time. If a welding robot welds too early or too late, the car will be ruined. If the action absolutely must occur at a certain moment (or within a certain range), we have a hard real-time system. Many of these are found in industrial process control, avionics, military, and similar application areas. These systems must provide absolute guarantees that a certain action will occur by a certain time.

    Another kind of real-time system is a soft real-time system, in which missing an occasional deadline, while not desirable, is acceptable and does not cause any permanent damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.

    Since meeting strict deadlines is crucial in real-time systems, sometimes the operating system is simply a library linked in with the application programs, with everything tightly coupled and no protection between parts of the system. An example of this type of real-time system is e-Cos.

    The categories of handhelds, embedded systems, and real-time systems overlap considerably. Nearly all of them have at least some soft real-time aspects. The embedded and real-time systems run only software put in by the system designers; users cannot add their own software, which makes protection easier. The handhelds and embedded systems are intended for consumers, whereas real-time systems are more for industrial usage. Nevertheless, they have a certain amount in common.”
    Но и из этого описания следует только, что системы могут применяться в системах где отсутствие реакции в заданный срок может привести к катастрофическим последствиям. Ну еще в целях достижения ключевого параметра (не превышения времени реакции) ОС могут представлять из себя библиотеку, пример eCos.

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

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


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

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

    Очевидным будет убрать все лишнее из критической системы. Универсальную систему вряд ли получится сделать стабильной. Даже товарищ Таненбаум об этом говорил, я имею в виду, когда он говорил о 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. Во время написания данной статьи ни одна ОСРВ не пострадала.
    Embox
    56,00
    Открытая и свободная ОС для встроенных систем.
    Поделиться публикацией

    Похожие публикации

    Комментарии 71

      +6

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


      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мс, а не позднее, независимо от других заданий.

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

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

          +1

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

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

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

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

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


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

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

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

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

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

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

              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 реализовать требуемую функцию.
                +1

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

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

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

                        Хмм, а я чё-то подумал про Rate Monotonic Scheduling.

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

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

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

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

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

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

                        Ок.

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

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

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

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


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

                          Ну вот опять.

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

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


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


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

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

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

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

                          спасибо!

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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


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

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

                                                Чтобы вы понимали средняя наработка на отказ человека составляет 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. Там джиттер меряют в сотни микросекунд.

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

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


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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое