Одна из причин успеха цифровых систем управления - их высокая надежность, которая в целом не зависит от того, каким образом и как долго эти системы используются. Например, для контроллера, построенного только на полупроводниковых элементах без подвижных частей, время его жизни не зависит от числа операций переключения его активных элементов.
В системах управления процессами суммарная надежность зависит от структуры системы. При прямом цифровом управлении единственная ЭВМ на которой установлено разнообразное программное обеспечение, решает все задачи – сбора данных, управления и регулирования. Как следствие, ее отказ вызывает полную остановку выполнения всех функций. При распределенном прямом цифровом управлении функции управления и регулирования выполняются локальными устройствами, расположенными в непосредственной близости от технологических процессов. ЭВМ более высоких уровней иерархии передают нижестоящим устройствам вместо управляющих сигналов только опорные значения или директивы. Поломка локальной или даже центральной ЭВМ влияет только на часть выполняемых функций, потому что системные компоненты независимы. Разница в надежности между этими двумя подходами явно проявилась уже при первых применениях управляющих ЭВМ.
Отказы вызываются либо неправильным функционированием отдельных элементов, либо - в сложных системах - нарушением взаимодействия между элементами системы. В больших системах со множеством элементов вероятность того, что некоторые : откажут, высока и, если это влияет на работу системы как целого, ее надежность снижается.
Отказоустойчивое (fault-tolerant) решение должно гарантировать, что система целое будет продолжать функционировать даже при наличии неисправностей. Это означает не только применение высоконадежных элементов, а скорее проектирование системы таким образом, чтобы отдельные неисправности не влияли на работу в целом. Более того, автоматизированная система состоит не только из аппаратной части, но включает также программное обеспечение, которое может содержать ошибки, реагировать непредсказуемым образом на непредусмотренную входную информацию, несогласованные протоколы обмена данными, внешние коммуникации. В простейшем случае отказоустойчивая технология основывается на некоторой избыточности - (redundancy). Если какая-то часть, аппаратная либо программная, не работает ее заменяет другой компонент. Существуют разные типы избыточности:
· физическая избыточность;
· информационная избыточность;
· избыточность по времени.
Физическая избыточность (physical redundancy) обычно достигается дублированием некоторых элементов. Когда элемент перестает работать должным образом, его заменяет другой. Если стоимость играет решающую роль, то дублируются только те компоненты, которые более всего подверженные отказам. Общепринятый принцип проектирования в системах реального времени – это физическое дублирование главного сервера и локальной сети.
Важными особенностями механизма физической избыточности является интерфейс между дублирующими друг друга компонентами. Это новый элемент системы, который может выйти из строя. Главными проблемами являются: во-первых, как однозначно определить, что компонент или подсистема не исправны, и, во-вторых, как переключиться на дублера.
Информационная избыточность (information redundancy) используется, например, в коммуникационных протоколах в виде служебной информации, добавляемой к пакету для того, чтобы обеспечить восстановление искаженных сообщений. Резервирование данных на внешних носителях или теневое хранение переменных (переменная храниться одновременно на двух различных дисковых устройствах) - это другие примеры информационной избыточности.
Избыточность по времени (time redundancy) заключается в том, что сначала выполняется действие, а затем оценивается его результат. Если результат неудачен, то действие выполняется заново. Таймауты и ограничения максимального количества повторений помогают избежать бесконечных циклов.
Отказоустойчивость в коммуникационных протоколах распределенных систем управления достигается комбинацией информационной и временной избыточности. Контрольные суммы в пакетах данных обеспечивают информационную избыточность, а процедуры подтверждения приема сообщения и, при необходимости, запросы на новую передачу, являются примерами избыточности по времени.
Если избыточность необходима для создания отказоустойчивой системы, то должны учитываться все составные элементы, а не только самые очевидные. Например, две ЭВМ должны быть подсоединены к двум независимым источникам питания. В противном случае выход из строя источника питания, то есть однократный сбой, приведет к выходу из строя обеих ЭВМ и, таким образом, перерастет в аварию системного масштаба.
Надежность программного обеспечения
Ошибки в программах часто могут вводить в заблуждение, и их труднее обнаружить, чем неисправности аппаратной части, и они далеко не безобидны. Проблемы с программными ошибками зависят от сложности системы. Ошибки сделанные в процессе разработки программы, могут многократно воспроизвестись и остаться незамеченными в конечном продукте. Программные ошибки являются обычным делом в сложных проектах, в частности в автоматизированных системах, причем сообщается о них только в некоторых очень громких случаях.
В отличие от аппаратной части, программное обеспечение не изнашивается. Дефекты программы возникают на стадии разработки, так что, по крайней мере теоретически, все ошибки можно устранить с самого начала. Проблема в том, как их обнаружить. Математические и логические методы помогают разрабатывать не содержащие ошибок программы. На практике, однако, несмотря на интенсивные и обстоятельные тесты, большая часть программ все-таки содержит ошибки на начальном этапе их эксплуатации. В случае непредусмотренных входных данных и сигналов прерывания программа может повести себя не так, как планировалось при разработке и тестировании.
Достаточно часто требования к программе меняются в процессе разработки, после того, как ее функции становятся яснее и понятнее. Позднейшие изменения могут оказать значительное влияние на всю работу программы. Полностью готовая и тестированная программа может быть, в свою очередь, использована иначе, чем планировалось разработчиками, что, естественно, увеличивает вероятность ошибок.
Если идеальная программа - это иллюзия, то, как выяснить, что программа достаточно надежна? Во-первых, необходимо определить требования к безопасности для конкретной задачи. Система управления полетами является хорошим примером чрезвычайно жестких требований к безопасности. Например, система управления всем североамериканским воздушным пространством может быть неисправна в среднем только три секунды в году.
Надежность программы в соответствии с функциональными требованиями должна быть определена, например, с помощью тестов. Программа проходит опытную эксплуатацию в течение определенного времени под наблюдением разработчиков. Все обнаруженные ошибки необходимо проанализировать и исправить. Однако этот метод применим, только если требований не являются очень строгими (порядка нескольких ошибок в год). С другой стороны, в таких сложных системах, как самолет гражданской авиации, специфика требует надежности, выражаемой цифрой порядка 10-9 серьезных ошибок в час. Для проверки и демонстрации выполнения таких требований число прогонов должно быть кратно 109 часов, т.е. порядка 100 тысяч лет, что, естественно, является неразрешимой задачей. Другая глобальная проблема во время тестирования возникает благодаря действию закона "уменьшения отдачи". Если программа испытывалась в течение очень длительного времени, серьезность ошибок убывает настолько, что их нахождение и исправление оказывает весьма незначительный эффект на общую надежность программы.
Лучших результатов можно достигнуть, если при разработке программы применяются специальные методы повышения надежности. Эти методы основаны на формальной математической теории и работают только в случаях, когда требования к программе также описаны математически формальным образом. Это означает, требования должны быть сформулированы, что не всегда просто.
Метод, который применяется для повышения показателей надежности в технике управления авиационным и железнодорожным движением, - это использование избыточных систем. Несколько одинаковых систем создаются параллельно разными рабочими группами. Основное допущение заключается в том, что ошибки, которые делают разные группы, не могут быть одинаковыми. Результат - это комбинация нескольких решений. Например, на бортовой ЭВМ полностью управляемого электроникой аэробуса А-320 установлено пять разных систем, которые были разработаны на основе одинаковых требований пятью независимыми рабочими группами на пяти разных языках программирования. Эти системы работают параллельно и независимо друг от друга. Окончательные управляющие воздействия, задающие положение управляющих аэродинамических поверхностей, выбираются из выходных сигналов нескольких систем с помощью электромеханического селектора.