вень отказов снова увеличился. С этими ограничениями z(t) можно принять за константу, т. е. 2(f)= X. Тогда решением уравнения (12.1) будет

К(0 = е- (12.2)

Основной интерес для пользователя или производителя системных компонентов представляет собой время, в течение которого компонент может функционировать в нормальных условиях до появления неисправности. Мерой этого является среднее время наработки на отказ (Mean Time to Failure - MTTF), т. е. математическое ожидание экспоненциального распределения

UTIY = \R(t)dt-

(12.3)

Мера готовности системы получается на основе среднего значения промежутка времени, в течение которого система функционирует правильно. Это значение называется средним временем между отказами (Mean Time Between Failures - MTBF). Аналогично, мера времени, в течение которого система не функционирует, называется средним временем восстановления (Mean Time То Repair - MTTR) и представляет собой время от появления неисправности до восстановления работоспособности системы.

Коэффициент готовности А элемента или подсистемы можно определить выражением

MTBF

MTBF + MTTR

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

12.3.3. Надежность систем управления процессами

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

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

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

В системах управления процессами суммарная надежность зависит от структуры системы. При прямом цифровом управлении единственная центральная ЭВМ, на которой установлено разнородное программное обеспечение, решает все задачи сбора данных, управления и регулирования. Как следствие, ее отказ вызывает полную остановку выполнения всех функций. При распределенном прямом цифровом управлении (раздел 12.4.3) функции управления и регулирования выполняются локальными устройствами, расположенными в непосредственной близости от технологических процессов. ЭВМ более высоких уровней иерархии (см. рис. 9.24) передают нижестоящим устройствам вместо управляющих сигналов только опорные значения. Поломка локальной или даже центральной ЭВМ влияет только на часть функций, потому что системные компоненты независимы. Разница в надежности между этими двумя подходами явно проявилась уже при первых применениях управляющих ЭВМ - в те времена среднее время между отказами измерялось не годами, а часами.

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

Отказоустойчивое (fault-tolerant) решение должно гарантировать, что система как целое будет продолжать функционировать даже при наличии неисправностей. Это означает не только применение высоконадежных элементов, а скорее проектирование системы таким образом, чтобы отдельные неисправности не влияли на работу в целом. Более того, автоматизированная система состоит не только из аппаратной части, а включает также программное обеспечение, которое может содержать ошибки, либо реагировать непредсказуемым образом на непредусмотренную входную информацию, несогласованные протоколы обмена данными, внешние коммуникации и т. д,

В простейшем случае отказоустойчивая технология основывается на некоторой из быточности (redundancy). Если какая-то часть, аппаратная либо программная, не рабо- тает, то ее заменяет другой компонент. Существуют разные типы избыточности:

- физическая избыточность;

- информационная избыточность;

- избыточность по времени.

Физическая избыточность (physicalredundancy) обычно достигается дублирова Нием некоторых элементов. Когда элемент перестает работать должным образом, еп Заменяет другой. Если стоимость играет решающую роль, то дублируются тольк! Наиболее важные или более всего подверженные отказам компоненты. Этот принци! Использован, например, в сети FDD1 (раздел 9.5.7), в которой два канала данных пс строены таким образом, чтобы минимизировать влияние неисправностей, будь т Пробой кабеля, отказ узла или его FDD1 интерфейса. Общепринятый принцип прс ектирования в системах реального времени - это физическое дублирование главнс го сервера и локальной f™; чсимости от специфики системы обе ЛВС могу работать с половинной загру о б постоянно находится в работ а другая немедленно активизируется в случае сбоя первой

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

Информационная избыточность {information redundancy) используется, например, в коммуникационных протоколах в виде служебной информации, добавляемой к пакету для того, чтобы обеспечить восстановление искаженных сообщений. Резервирование данных на внешних (съемных) носителях или теневое хранение переменных (переменная храниться одновременно на двух различных дисковых устройствах) - это другие примеры информационной избыточности.

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

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

Если избыточность необходима для создания отказоустойчивой системы, то должны учитываться все составные элементы, а не только самые очевидные. Например, две ЭВМ должны быть подсоединены к двум независимым источникам питания, в противном случае выход из строя источника питания, то есть однократный сбой, приведет к выходу из строя обеих ЭВМ и, таким образом, перерастет в аварию общесистемного масштаба.

12.3.4. Надежность программного обеспечения

Ошибки в программах часто могут вводить в заблуждение, и их труднее найти, чем неисправности аппаратной части. И они далеко не безобидны. В разделе 2.3 было упомянуто, как одна программная ошибка привела к серьезной аварии в американской телефонной сети.

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

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

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

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

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

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

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

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

12.4. Функции автоматизированных систем управления

Система управления процессом обычно выполняет много различных функций которые можно разделить на три большие группы (рис. 12.3):

- сбор и оценка данных технического процесса - мониторинг;

- управление некоторыми параметрами технического процесса;

- связь входных и выходных данных - обратная связь, автоматическое управление.

физический/ технический процесс

анализ

и отображение информации

оператор

удаленное управление

Рис. 12.3. Основные функции системы управления

12.4.1. Мониторинг

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

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

Когда функции системы управления процессом ограничены сбором и отображ нием данных, все решения об управляющих действиях принимаются оператором-Этот вид управления, называемый супервизорным или дистанционным управлением {supervisory control), был очень распространен в первых системах компьютерное управления процессами. Он до сих пор применяется, особенно для очень сложных относительно медленных процессов, где важно вмешательство человека. Примере являются биологические процессы, где определенную часть наблюдений нельзя вЫ полнить с помощью автоматики.

При поступлении новых данных их значение оценивается относительно допустимых границ. В более развитой системе контроля несколько результатов могут ком

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

12.4.2. Управление

Управление - это функция, обратная мониторингу. В прямом смысле управление означает, что команды ЭВМ поступают к исполнительным механизмам для во.здей-ствия на физический процесс. Во многих случаях на параметры процесса можно воздействовать только опосредованно через другие параметры управления (раздел 3.5.1).

12.4.3. Автоматическое управление

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

Существуют два основных подхода к реализации обратной связи в вычислительных системах. При традиционном прямом цифровом управлении (ПЦУ, Direct Digital Control - DDC) центральная ЭВМ рассчитывает управляющие сигналы для исполнительных устройств. Все данные наблюдения передаются в полном объеме от датчиков к центру управления, а управляющие сигналы - обратно к исполнительным устройствам.

В системах распределенного прямого цифрового управления {Distributed Direct Digital Control - DDDC) вычислительная система имеет распределенную архитектуру, а цифровые регуляторы реализованы на основе локальных процессоров, т. е. расположены вблизи технического процесса (раздел 9.6.1). ЭВМ верхних уровней управления рассчитывают опорные значения, а локальные процессоры ответственны главным образом за непосредственное управление техническим процессом, т. е. выработку управляющих сигналов для исполнительных механизмов на основе данных Локального мониторинга. Эти локальные ЭВМ включают в себя цифровые контуры Управления.

С точки зрения структурирования уровней управления и обработки различие чежду прямым цифровым управлением и распределенным прямым цифровым управлением заключается в том, что в первом случае, даже при наличии нескольких ВМ, они занимаются только передачей информации и не принимают решений (кроме центрального) об управляющих действиях. Напротив, в распределенной структуре ЭВМ на уровнях процесса, участка и общего управления могут действовать более или менее автономно и не зависят от центральной ЭВМ. Как уже указывалось, это различие влияет и на надежность сложной системы. При отказе централь-Ной ЭВМ управляющая система типа ПЦУ останавливается, а распределенная

система, даже при о-" нескольких элементов, хотя и утратит часть

Функций, но будет продолжать работу.