Действительно ли вам нужна ОС реального времени?

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

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

Мой взгляд на эту тему в основном приведен в статье, ссылка на которую есть в начале этого треда. Если коротко, то все системы АСУ ТП являются системами реального времени. Поэтому в этом контексте термин «реальное время» ничего не добавляет и не убавляет, а значит не имеет большого смысла. Тем не менее термины «жесткое реальное время» и «мягкое реальное время» имеют  по моему право на существование.

Можно конечно критиковать термин «hard realtime» или его устоявшийся перевод на русский язык, однако в любом случае существует большая группа систем, где своевременность выполнения тех или иных действий является критической. То есть несвоевременность выполнения каких то действий приводит к разрушению системы или к невыполнению целевой функции системы, для исполнения которой она и создавалась. Другими словами в результате несвоевременности выполнения каких то действий происходят неприемлимые для системы последствия. Что такое «неприемлимые последствия» зависит от конкретной системы и обычно указывается в ТЗ на создание системы. Некоторые неприемлимые последствия очевидны исходя из здравого смысла или действующих стандартов и могут в ТЗ не указываться (например, что котел не должен взорваться, что не должна подвергаться риску жизнь обслуживающего персонала и т.п.).

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

Несколько условных примеров: Скажем если в котле я при повышении давления вовремя не прекращу подачу реагентов, то котел может взорваться (в случае если ПАЗ не сработает). Если я не открою клапан сразу после того как очередная бутылка на конвейере остановится под наливным краном, у меня эта бутылка не заполняется и идет в брак, а загрязнение конвейера жидкостью может привести к необходимости его остановки на профилактику (это все недопутимые последствия – экономические убытки) . Если же в овощной теплице я при понижении окружающей температуры вовремя не включу нагреватели, то у меня может померзнуть сколько то процентов овощей (например допустимо до 30%) . Последний пример иллюстрирует что в одной и той же системе могут быть мягкие временные ограничения, несоблюдение которых приводит к негативным, но приемлимым последстиям и жесткие ограничения, несоблюдение которых приводит к неприемлимым последствиям.

Опять же ни «жесткое» ни «мягкое» реальное время никак не связаны со скоростью управляемого процесса. Например в теплице «жесткое» временное ограничение,  когда АСУ ТП должна среагировать на изменение температуры, что бы не померзло более 30% овощей, может измеряться часами.  За это время можно десять раз по вотчдогу перезагрузить операционную систему (какой нибудь windows) после стольких же зависаний ПО, и система в целом все равно будет работать как система «жесткого реального времени», то есть укладываться в заданные временнЫе ограничения. То есть в медленных системах «жесткого реального времени» могут работать практически любые вычислительные средства с любым системным ПО (операционными системами). Другое дело когда система управления и ее вычислительное устройство должны БЫСТРО работать в рамках «жесткого реального времени». Собственно словосочетание «операционная система реального времени» обозначает операционную систему ЗАТОЧЕННУЮ для работы в составе «БЫСТРЫХ систем жесткого реального времени». По моему не более того. Эти ОС по своей архитектуре отличаются от «обычных» ОС и заслуживают какой то выделющей их из общей массы приставки. ОС РВ вполне приемлимое обозначение этой группы ОС.

Можно ли без операционной системы создавать ПО для быстрых систем жесткого реального времени? Как я уже говорил – можно. У Владимира насколько я понял такая система и работает. Скорее всего – это некий самодельный планировщик в стиле round-robin, который позволяет обходиться без вытеснения (прерывания текущей задачи) и связанных с этим проблем приоритетов, разделяемых ресурсов, синхронизации, реентерабельности и т.п. Такой подход наиболее «честный» так как обычно позволяет уже на этапе проектирования оценить наихудший случай и выбрать аппаратуру такого быстродействия, что бы даже при наихудшем случае все временнЫе ограничения выполнялись. И конечно лучше переплатить за избыточные «в среднем» вычислительные ресурсы, но быть при этом уверенным в предсказуемости и детерминированности поведения системы.

Проблемы с таким подходом начинаются когда нужно несколько вычислительных устройств объединть в сеть, критическое  приложение распределено по узлам, необходимо использовать ПО написанное сторонними организациями и т.п.. Здесь как раз не обойтись без ОС РВ, которые предлагают разработчику специализированные сервисы, о которых говорил Olej,  но которые имеют и некоторый букет связанных с нимим возможных проблем (инверсия приоритетов, скложность просчета наихудшего случая и т.п.).

С Уважением,

Сергей Сорокин