1. Аксиомы проектирования и внедрения систем автоматизации

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

Аксиома 1. Разработка системы управления (включая ее комплектацию и внедрение) заказывается одной организации — генеральному разработчику (или генеральному подрядчику). Предпочтение отдается организации, которая имеет опыт подобных проектов, главное — найти ответственные организации-соисполнители и правильно организовать с ними работу. При длительной разработке, комплектации, наладке и сдаче системы управления желательно иметь свое отделение на объекте.

Аксиома 2. С заказчиком надо сразу находить взаимопонимание — фактор доверительности должен присутствовать на всех уровнях руководителей и специалистов.

Аксиома 3. При проектировании системы необходимо предусмотреть:

— аппаратный резерв (по количеству входных сигналов и каналов управления 10-15 % в зависимости от масштабности и сложности объекта) для возможности расширения системы;

— запасные части и приспособления (ЗИП) при составлении заказных спецификаций на КИПиА (особенно отечественного производства) и компьютерного оборудования.

Аксиома 4. Сдача системы управления должна проходить в один этап: неважно, как он будет называться — опытно-промышленная или промышленная эксплуатация (все остальные подэтапы: сдача системы в информационном режиме, в управляющем, в опытную эксплуатацию – это только затягивание сроков.

2. Б а з о в ы е а р х и т е к т у р ы п о с т р о е н и я п о д с и с т е м

Архитектуру каждой подсистемы образуют один или несколько модулей:

Рисунок 3 – Подсистема состоящая из двух модулей CPU

Архитектура 1oo1 – предполагает использование одного канала, и любой возникающий в ней опасный отказ приводит к нарушению функции безопасности при обращении к ней. Структурная схема и схема расчета надежности архитектуры 1oo1представлены на рисунках 4 и 5.

На рисунке 5 показано, что канал можно рассматривать как состоящий из двух компонентов, одного с интенсивностью опасных отказов λDU, а другого с интенсивностью опасных отказов λDD. Эквивалентное среднее время простоя канала tCE можно рассчитать, суммируя времена простоя для двух компонентов, tC1 и tC2, прямо пропорционально вкладу каждого компонента в вероятность отказа канала:

λDU=λ·(1-DC)/2; (8)

λDD=λ·DC/2; (9)

PFDG,1oo1=(λDD + λDU)·tCE; (10)

PFDG,1oo1= λDU . (11)

Архитектура 1oo2 – представляет собой два канала, соединенных параллельно, так что любой из каналов в состоянии самостоятельно и независимо обеспечить выполнение функции безопасности. Следовательно, для нарушения функции безопасности опасные отказы должны возникнуть в обоих каналах. Предполагается, что любое диагностическое тестирование только сообщает о найденных сбоях и не может изменить ни выходные состояния каналов, ни результат голосования.

Структурная схема и схема расчета надежности архитектуры 1oo2 6 и 7:

Эквивалентное время простоя системы:

PFDG,1oo2=2·((1-βD)· λDD+·(1-β)· λDU)2 ·tCE· tGE++βD· λDD·MTTR+ +β·λDU·(T1/2+MTTR); (13)

PFDG,1oo2=2·((1-βD)· λDD+·(1-β)· λDU)2 ·tCE++βD· λDD+ +β·λDU (14)

Архитектура 1oo2D – представляет собой два канала соединенных параллельно. При нормальной работе для выполнения функции безопасности необходимы два канала. Кроме того, если диагностическое тестирование обнаруживает отказ в любом канале, то результаты анализа устанавливаются так, чтобы общее выходное состояние совпадало с результатом, выдаваемым другим каналом. Если диагностическое тестирование обнаруживает отказы в обоих каналах или несоответствие между ними, причина которого не может быть идентифицирована, то выходной сигнал переводит систему в безопасное состояние. Для обнаружения несоответствия между каналами каждый

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

Структурная схема и схема расчета надежности архитектуры 8 и 9:

Для каждого канала λSD определяется как: λSD=λ·DC/2 ; (15)

Значения эквивалентного среднего времени простоя tCE’ и tGE’ определяются как:

PFDG,1oo2D=2·((1-β)· λDU·((1-β)· λDU+(1-βD)· λDD + λSD) ·tCE’· tGE’+βD· λDD·MTTR+ +β·λDU·(T1/2+MTTR); (18)

PFHG,1oo2D=2·((1-β)· λDU·((1-β)· λDU+(1-βD)· λDD + λSD) ·tCE’+

+βD· λDD·MTTR+ +β·λDU·(T1/2+MTTR). (19)

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

Структурная схема и схема расчета надежности архитектуры 2oo2 10 и 11:

PFDG,2oo2 =2·λD· tCE ; (20)

PFDG,2oo2 =2·λDU . (21)

Архитектура 2oo3 - состоит из трёх каналов, соединенных параллельно с мажорированием выходных сигналов так, что выходное состояние не меняется, если результат, выдаваемый одним из каналов, отличается от результата, выдаваемого двумя другими каналами. Структурная схема и схема расчета надежности архитектуры 2oo3 12 и 13:

1 . О с о б е н н о с т и и с х о д н ы х д а н н ы х , п р о ц е с с а п р о е к т и р о в а н и я и о ц е н к и р и с к а п р о е к т а

Основными отличиями стадий проектирования АСУП от стадий проектирования технических систем являются:

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

2. АСУП создают в одном экземпляре и проведение натурных экспериментов практически исключено. Это повышает роль математических методов.

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

4. Ввод системы в эксплуатацию проводят постепенно, очередями.

5. Учитывают взаимодействие «человек-машина» в процессе эксплуатации системы.

6. Основная тяжесть разработки ложится на информационное и программное обеспечение в силу стандартности комплекса технических средств.

Особенности исходных данных:

 большое число действий, подлежащих реализации (многофункциональность);

 значительный объем и сложность ограничений на взаимосвязи проектируемой системы с окружением и трудности их формального описания;

 распределенный и асинхронный режимы обработки данных;

 многообразие используемых информационных объектов и их свойств;

 нечеткость требований, их субъективный характер;

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

Особенности процесса проектирования:

 предположения о конечном результате проектирования делают-

ся до того, как исследованы средства его достижения;

 при исследовании событий в обратном порядке (от конечного

результата) обнаруживаются непредвиденные трудности или

открываются новые (благоприятные) возможности;

 поиск решения возможен путем изменения формулировки зада-

чи —самая интересная и самая сложная часть разработки.

Особенности оценки риска проекта. Процесс проектирования АСУ требует больших затрат (временных, трудовых и материальных). Ошибки приводят к значительным экономическим потерям, поэтому важна оценка риска проекта в трех аспектах:

 заказчика;

 исполнителя;

 проекта.

Характеристики заказчика, влияющие на оценку риска проекта:

 стабильность организационной структуры и удовлетворенность заказчика организационной структурой;

 уровень формализации процессов обработки данных в существующей технологии;

 существующий уровень автоматизации процессов сбора и обработки данных;

 уровень подготовки кадров в области автоматизированной технологии обработки данных.

Характеристики исполнителя, влияющие на оценку риска проекта:

 опыт разработки и работы с прикладным программным обеспечение (ПО) и с техническими средствами;

 предполагаемая смена технической и программной среды;

 наличие в группе специалистов данной предметной области.

Показатели проекта, влияющие на оценку риска проекта:

 уровень охвата автоматизацией процессов обработки данных;

 объем обрабатываемых данных и характер обработки данных (сбор, поиск, представление, оптимизация).

 требования к достоверности данных;

 наличие прототипов;

 требования к времени ответа;

 требования к надежности;

 наличие территориально разнесенных подразделений;

Требования к обслуживающему персоналу.

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

Отказ - это событие, заключающееся в нарушении работоспособного состояния системы.

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

Система – совокупность элементов объединенных конструкционно и/или функционально для выполнения некоторых требуемых функций.

Вид отказа – совокупность возможных или наблюдаемых отказов элемента и/или системы, объединенных в некоторую классификационную группу по общности одного или нескольких признаков (причины, механизмы возникновения, внешние проявления). При анализе видов отказов их делят на опасные и безопасные.

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

Безопасный отказ - система защиты может совершить ложный немотивированный аварийный останов процесса, в то время как в действительности ничего опасного на процессе не произошло.

В свою очередь безопасные (опасные) отказы делятся на:

• безопасные (опасные) обнаруживаемые;

• безопасные (опасные) необнаруживаемые.

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

SIL (Safety Integrity Level) - интегральный уровень безопасности уровень безопасности всей системы. Чем выше SIL безопасной системы, тем ниже вероятность неспособности системы выполнить задачу обеспечения безопасности.

PFD (Probability of Failure on Demand) - средняя вероятность отказа в выполнении заданной функции безопасности (низкий уровень требований по исполнению функции безопасности, один – два раза в год).

PFH (Probability of Failure per Hour) - средняя вероятность опасного отказа в течении одного часа в режиме непрерывной работы (высокий уровень требований по исполнению функции безопасности, чаще двух раз в год).

Уровни SIL при соответствующих средних вероятностях PFD и PFH приведены в таблице 1.

Таблица 1 - SIL с низким и высоким уровнем требований к системе Уровень интегральной безопасности (SIL) PFD PFH

4 ≥ 10-5 - < 10-4 ≥ 10-9 - < 10-8

3 ≥ 10-4 - < 10-3 ≥ 10-8 - < 10-7

2 ≥ 10-3 - < 10-2 ≥ 10-7 - < 10-6

1 ≥ 10-2 - < 10-1 ≥ 10-6 - < 10-5

Интенсивность отказов – в общем случае определяется как изменение количества отказов в единицу времени на единицу работающего оборудования, 1/час.

Интенсивность отказа отдельного контура рассчитывается как сумма интенсивностей λi всех элементов в контуре:

Существуют следующие типы интенсивностей отказов:

λS - интенсивность безопасного отказа;

λSD - интенсивность безопасного обнаруживаемого отказа;

λSU - интенсивность безопасного не обнаруживаемого отказа;

λS = λSD + λSU ; (2)

λD - интенсивность опасного отказа;

λDD - интенсивность опасного обнаруживаемого отказа;

λDU - интенсивность опасного не обнаруживаемого отказа;

λD = λDD + λDU . (3)

MTTF (Mean Time To Failure) - среднее время наработки до отказа в часах

MTTF=1/λ . (4)

MTTR (Mean Time to Repair) - среднее время на восстановление - время в часах, требуемое на восстановление исходной конфигурации системы после возникновения отказа. В расчетах чаще всего принимают значение MTTR = 8 часам (если величина MTTR специально не оговаривается производителем оборудования).

T1 – интервал времени между процедурами тестирования, в часах.

Стандартом МЭК 61508 предусмотрен следующий диапазон времени тестирования:

 один месяц (730 ч) – только для PFH;

 три месяца (2190 ч) – только для PFH;

 шесть месяцев (4380 ч);

 один год (8760 ч);

 два года (17520 ч) – только для PFD;

 десять лет (87600 ч) – только для PFD.

β - коэффициент, учитывающий долю опасных необнаруживаемых отказов, имеющих общую причину возникновения. Стандартом МЭК 61508 предусмотрен следующий диапазон β: 2%, 10%, 20%.

βD - коэффициент, учитывающий долю опасных обнаруживаемых отказов, имеющих общую причину возникновения. Стандартом МЭК 61508 предусмотрен следующий диапазон βD: 1%, 5%, 10%.

DC – уровень диагностического охвата, %. Возможные диапазоны диагностического охвата представлены в таблице 2.

tCE и tGE - эквивалентное среднее время простоя канала и системы соответственно, в часах.