Системой жесткого реального времени называется система, где неспособность обеспечить реакцию на какие-либо события в заданное время является отказом и ведет к невозможности решения поставленной задачи. Время реакции в системах жесткого реального времени должно быть минимальным. Большинство систем жесткого реального времени являются системами контроля и управления. Такие СРВ сложны в реализации, так как к ним предъявляются особые требования в вопросах безопасности.
Точного определения мягкого реального времени не существует, поэтому можно отнести сюда все СРВ, не подпадающие под категорию жестких. Так, система мягкого реального времени может не успевать все делать в заданное время, поэтому возникает проблема определения критериев успешности (нормальности) ее функционирования.
Кроме того, СРВ можно разделить на системы специализированные и универсальные.
o Специализированная СРВ - система, где конкретные временные требования изначально определены. Такая система должна быть специально спроектирована для удовлетворения этих требований.
o Универсальная СРВ должна уметь выполнять произвольные (заранее неопределенные) временные задачи без применения специальной техники. Разработка таких систем является самой сложной задачей, хотя обычно, требования, предъявляемые к таким системам, мягче, чем требования к специализированным системам.
o возможность параллельного выполнения нескольких задач;
o предсказуемость;
o важно максимальное (не среднее) время отклика на событие;
o особые требования в вопросах безопасности;
o возможность безотказной работы в течение длительного времени.
o большие и сложные системы;
o распределенные системы;
o жесткое взаимодействие с аппаратурой;
o выполнение задач зависит от времени;
o сложность тестирования.
СРВ должны реагировать на различные типы внутренних и внешних событий (периодических и непериодических). Необходимо отметить, что принадлежность системы к классу СРВ никак не связана с ее быстродействием. Исходные требования к времени реакции системы и другим временным параметрам определяются или техническим заданием на систему, или просто логикой ее функционирования. Интуитивно понятно, что быстродействие СРВ должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления.
Классическая ОС. Win NT, Linux и Unix.
Классическая ОС с расширением РВ (Win NT - RTX, RT Linux, RT Unix)
Коммерческая ОС. Примером могут служить такие системы как VxWorks, OS9 и т.п. Необходимо отметить, что такие системы очень дорогие. Например, стоимость полного пакета ОС VxWorks (Tornado 1.0) в 2002 году составляла около 15 000 долларов США. Впрочем, с годами такая система значительно дешевеет - сегодня ее стоимость составляет около 10 000 долларов (Tornado версии 2.0 и выше - полная стоимость зависит от выбираемых компонентов).
Для более детального рассмотрения возможностей ОСРВ представлены ориентировочные цифры, дающее представление о порядке времени реакции и подходящих операционных системах. Данная таблица сформирована на основании экспериментальных данных, полученных на базе вычислительных комплексов, построенных на основе процессоров Intel 80486DX. Безусловно, данный процессор на сегодняшний день является устаревшим, но можно сделать выводы об уровне реакции на внешние события различных систем
| РВ.Время реакции | Использованные ОС |
| Менее 10 мкс | Только ОСРВ, но даже они могут быть бессильны |
| 10 - 100 мкс | Операционные системы реального времени |
| 100 мкс - 1 мс | ОСРВ, RTAI, RT- UNIX и LINUX, расширения реального времени для Windows NT, CE |
| 1 мс | Можно пытаться делать что-то с Linux и Windows NT, но не для систем, где опоздания реакции могут привести к тяжелым последствиям |
Из таблицы видно, что временные рамки ОСРВ достаточно жесткие. Среди современных операционных систем есть класс продуктов, разработанных специально для построения систем жесткого реального времени - VxWorks, OS9, QNX, LynxOS, OSE и другие. Эти системы содержат необходимый набор инструментов, и в некоторых случаях являются единственным выбором - на него приходится идти, невзирая на затраты. Однако достаточно часто требования к реальному времени (полная предсказуемость времени реакции) становятся менее жесткими, например, необходимо добиться только нужной средней производительности.
Иногда достаточно жестко контролировать только одно из событий, допуская при этом задержки реакций на остальные. В подобных случаях возможности выбора расширяются, и желаемых результатов можно достичь, используя такие широко распространенные операционные системы как LINUX, Windows NT, Windows CE, дополняя их расширениями реального времени (RTAI, RT LINUX, RTX).
Как указывалось выше, ОСРВ должна быть предсказуемой, что означает максимальное время выполнения того или иного действия, которое должно быть известно заранее и должно соответствовать требованиям приложения.
Первое требование состоит в том, что ОС должна быть многонитевой по принципу абсолютного приоритета (прерываемой). Планировщик должен иметь возможность прервать любую нить и предоставить ресурс той нити, которой он более необходим. ОС (и аппаратура) должны также обеспечивать прерывания на уровне обработки прерываний.
Проблема в том, чтобы определить, какой задаче требуется ресурс. В идеальной ситуации ОСРВ отдает ресурс нити или драйверу с ближайшим крайним сроком (так называемые ОС, управляемые временным ограничением (deadline driven OS)).
Чтобы реализовать это, ОС должна знать время, требуемое каждой из выполняющихся нитей для завершения (до сих пор не существует ОС, построенной по этому принципу, так как он слишком сложен для реализации), поэтому разработчики ОС принимают иную точку зрения: вводится понятие уровня приоритета задачи, и временные ограничения сводят к приоритетам. Так как умозрительные решения чреваты ошибками, показатели СРВ при этом снижаются. Чтобы более эффективно осуществить указанное преобразование ограничений, проектировщик может воспользоваться теорией расписаний или имитационным моделированием, хотя и это может оказаться бесполезным. На сегодняшний день не имеется иного решения, поэтому понятие приоритета нити необходимо.
Задачи разделяют данные (ресурсы) и должны сообщаться друг с другом, следовательно, должны существовать механизмы блокирования и коммуникации.
На самом деле именно этот механизм синхронизации и тот факт, что различные нити используют одно и то же пространство памяти, отличают нити от процессов. Процессы не разделяют одно и то же пространство памяти. Так, например, старые версии UNIX не являлись многонитевыми. Старый UNIX - многозадачная ОС, где задачами являются процессы, которые сообщаются через потоки (pipes) и разделяемую память. Оба эти механизма используют файловую систему, а ее поведение непредсказуемо.
Комбинация приоритета нити и разделение ресурсов между ними приводит к другому явлению: классической проблеме инверсии приоритетов. Это можно проиллюстрировать примером, где есть как минимум три нити. Когда нить низшего приоритета заняла ресурс, разделяемый с нитью высшего приоритета, а сначала выполняется нить среднего приоритета, выполнение нити высшего приоритета будет приостановлено, пока не освободится ресурс и не отработает нить среднего приоритета. В этой ситуации время, необходимое для завершения нити высшего приоритета, зависит от нижних приоритетных уровней - это и есть инверсия приоритетов. Ясно, что в такой ситуации трудно выдержать ограничение на время исполнения.
Чтобы устранить такие инверсии, ОСРВ должна допускать наследование приоритета, т. е. повышение приоритета до уровня вызывающей нити. Наследование означает, что блокирующая ресурс нить наследует приоритет блокируемой нити (справедливо лишь в том случае, если блокируемая нить имеет более высокий приоритет). Иногда утверждают, что в грамотно спроектированной системе такая проблема не возникает. В случае сложных систем с этим нельзя согласиться. Единственный способ решения этой проблемы состоит в увеличении приоритета нити вручную прежде, чем ресурс окажется заблокированным - это возможно в случае, когда две нити разных приоритетов претендуют на один ресурс. В общем случае решения не существует.
Наконец, следует рассмотреть временные ограничения. Время выполнения системных вызовов и временные характеристики поведения системы в различных обстоятельствах должны быть известны разработчику, поэтому производитель ОСРВ должен приводить следующие характеристики: