Можно потратить много денег на сверхнадежную аппаратную платформу и получить неработоспособную систему из-за неправильно работающего ПО. Вообще существует постулат о том, что любая программа содержит хотя бы одну ошибку, независимо от квалификации программистов и других факторов.
Просто для каждой программы существует своя ненулевая вероятность ее проявления. Выявление ошибок в микрокоде Pentium и в ПО марсохода NASA, а также и многие другие примеры это подтверждают.
Почему же мы можем говорить о том, что одна программа или совокупность программ является более надежной, а другая менее ?
Что бы попытаться разобраться в этом, давайте рассмотрим два произвольных фрагмента кода без разницы кем написанные и на каком языке программирования. Какие же вопросы можно задать, что бы сложить представление об их надежности ?
Наверное самый простой и первый вопрос – это «Какова длина кода ?». Все очень просто – чем больше код, тем больше вероятность присутствия в нем ошибки. Второй вопрос –«А когда он был написан и сколько тестировался ?». Действительно, более старый код, который долго тестировался, а потом проверялся практикой, является более надежным. И третий вопрос – «А уязвим ли этот код со стороны ?» В самом деле, сам код может быть идеально написан и отлажен, но неправильная адресация со стороны другого кода может его разрушить.
Вооружившись этими нехитрыми умозаключениями, рассмотрим архитектуру ОС общего назначения (GPOS):
Рис.1. Архитектура ОС общего назначения
Критическим компонентом ОС является ядро, от работоспособности которого зависит работоспособность всей остальной системы. В ОС общего назначения ядро имеет достаточно большой размер и, следовательно, большую вероятность ошибки. Кроме того, в режиме ядра работают отдельные компоненты, драйверы, разработанные разными производителями. Учитывая скорость появления на свет новых устройств, такие драйверы разрабатываются достаточно быстро и тестируются так тщательно, как это только возможно за имеющееся время. Более того, любой небрежно написанный драйвер, неправильно инициализированный указатель, может разрушить любой другой компонент ядра, так как защита между компонентами ядра отсутствует. Такое нарушение приводит, как правило, к «синему экрану смерти» ,если речь идет о Windows.
Если же взять несколько десятков килобайт кода, который тестировался на протяжении многих лет и поместить его в ядро, а все остальные драйверы и приложения вынести в отдельные процессы, защитив адресное пространство каждого аппаратными средствами защиты процессора, мы получим ОС повышенной надежности с микроядерной архитектурой (рис 2) :
Рис 2. Архитектура ОС QNX.
Одной из самых первых и известных реализаций системы с микроядерной архитектурой является ОС РВ QNX, которая использовалась для создания самых разнообразных mission-critical приложений, от систем управления вооружениями, до автоматизации ядерных реакторов (например проект CANDU в Канаде).
ОС РВ QNX широко используется системными интеграторами, работающими и в ТЭК Украины. Кроме микроядерности и защиты, QNX обладает еще одним важным свойством – это очень простой масштабируемостью.
Если объединить несколько компьютеров с QNX локальной сетью (можно дублированной), эти компьютеры превратятся в одну виртуальную машину, в которой можно гибко перераспределять нагрузку по узлам сети, перенося процессы с узла на узел, не переписывая код.
На одном из узлов такого кластера или виртуальной машины возможна организация программного сторожевого таймера, который будет осуществлять мониторинг состояния всех процессов , и, в случае обнаружения аномалий, может попытаться перезапустить отказавший процесс и/или сформировать диагностическое сообщение.
Ну и конечно, нельзя не отметить тот факт, что QNX является ОС жесткого реального времени, обладающей гарантированным временем реакции на внешние события, лежащим в субмикросекундной области. Так, высокоприоритетный процесс управления, вытеснит в гарантированные 7-8 сотен наносекунд любой другой, более низкоприоритетный процесс, например СУБД, выдаст управляющее воздействие и вернет управление прерванным процессам. Другой особенностью QNX являются черезвычайно низкие накладные расходы, по сравнению с другими ОС, что позволяет обрабатывать в 4-5 раз больше тегов при равной вычислительной мощности.
Сетвые коммуникации в QNX могут быть дублированы, причем в разных сетях.
Например связь на UTP/STP Ethernet может быть продублирована резервным каналом RS-232/RS-485.
Технологии перераспределения нагрузки в реальном времени (Load Balancing) между каналами оптимально перераспределяет нагрузку между каналами и мгновенно реагирует на изменение пропускной способности, что позволяет "на лету" отрабатывать поврежение и восстановление связи.
Файловая система QNX устойчива к сбоям и не разрушается при нажатии на Reset или пропадания питания, что позволяет использовать аппаратный сторожевой таймер, перезапускающий систему при аномальном превышении времени цикла (зависании системы).
Все это делает QNX идеальной платформой для Softlogic.
Большинство вышеприведенных идей нашли свое отражение в S3, которая использует QNX в качестве платформы реального времени для реализации задач управления, а так же , при необходимости, отображения (HMI) и хранения критических данных в СУБД.
Широкое распространение QNX в АСУ ТП сдерживают (1) необходимость покупать достаточно дорогие средства разработки и (2) высокие требования к квалификации разработчика.
Благодаря SCADA/Softlogic S3 теперь об этом можно не беспокоиться. Во первых QNX со всеми своими ньюансами диспетчеризации и тонкой настройки теперь скрыта в "черном ящике" контроллера , PC совместимого компьютера, RISC модуля (смотрите полный, постоянно пополняемый список драйверов , и платформ). С таким контроллером можно работать точно так же , как и с любым другим, удаленно загружая и отлаживая проект, не выходя из единой IDE S3.
Во вторых, благодаря оригинальным технологиям S3, Вам больше не требуется компилятор и дорогие библиотеки, входящие в комплект разработчика, а цена полностью легального QNX Runtime входит в стоимость продукта, которая очень конкурентоспособна.
Вытесняющая многозадачность с гаранитрованными и очень малыми временами задержки, одна из лучших в мире реализация диспетчеризации процессов, позволяют безболезненно на одном процессоре совмещать задачи регулирования, аварийных защит, коммуникаций , интерфейса оператора, и, даже, СУБД. Другой особенностью QNX является черезвычайно низкие накладные расходы, по сравнению с другими ОС, что позволяет обрабатывать в 4-5 раз больше тегов при равной вычислительной мощности.
В итоге стоимость системы на S3 может быть в несколько раз ниже, чем при "классическом" контроллерном подходе, не уступая, а часто и превосходя классику в удобстве разработки и сопровождения.
Высокую надежность конечного приложения, получаемого с помощью S3, дополняет оригинальная концепция встроенной системы безопасности, предотвращающая изменение конкретных переменных, для групп пользователей, не имеющих достаточных прав, независимо от того, с помощью каких элементов интерфейса и с каких узлов сети эти переменные могут изменяться.
S3 всегда может ответить на вопрос, кто виноват в той или иной нестандартной ситуации, поскольку протоколирует все действия и оператора и системы.
S3 периодически сохраняет снимок всех переменных в энергонезависимой памяти (Flash диске ) которые могут быть восстановлены согласно заданной политике в случае аварийной перезагрузки.
