Справочник инженера по АСУТП Проектирование и разработка 2008. Справочник инженера по асутп Проектирование и разработка Учебнопрактическое пособие ИнфраИнженерия
 Скачать 6.47 Mb.
|
|
Глава Р. Особенности проектирования систем безопасности 551 • Доступа к прикладному программному обеспечению для изменения, тестирования и просмотра; • Контроля эффективности использования системных ресурсов ПАЗ и диагностики; • Изменения уровня секретности системы ПАЗ и досту- па к переменным прикладного программного обеспе- чения. Интерфейсы технического обслуживания, проектирова- ния и разработки должны иметь возможность отображения рабочего состояния и диагностического статуса всех компо- нентов ПАЗ (модулей ввода-вывода, процессоров, и т.п.), включая состояние каналов связи между ними. Интерфейсы технического обслуживания, проектирования и разработки должны иметь средства для копирования прикладных про- грамм на внешний магнитный носитель. Интерфейсы техни- ческого обслуживания, проектирования и разработки должны быть доступны только: • Со специально предназначенной для этих целей стан- ции, • По специальному разрешению, • И только для специально допущенного персонала. 9.15. Диагностика Общие положения. Диагностика - это тестирование, выполняемое периодически для обнаружения скрытых дефек- тов, которые могут помешать системе защиты в осуществле- нии предписанных действий. Скрытый дефект в системе может помешать ПАЗ от- реагировать на требование защиты. Этот отказ может быть единственным отказом в однока- нальной системе, или комбинация дефектов в многоканальной системе. Следовательно, очень важно отслеживать не только критические отказы, но также и потенциально критические дефекты прежде, чем они накопятся. Дефекты могут закончиться двумя типами отказов: • Случайные отказы - спонтанный отказ компонента; • Систематические отказы (или ошибки) - скрытый дефект в конструкции или в реализации проекта. 552 Справочник инженера по А СУТП: Проектирование и разработка Случайные отказы возникают спонтанно. Оборудование, вообще говоря, склонно к случайным отказам, но может также иметь и систематические отказы (неправильная синхрониза- ция, компоненты эксплуатируются за пределами предопреде- ленных условий, и т.п.). В зависимости от частоты проявления дефекта возможны два варианта развития событий: • Постоянные случайные дефекты упорствуют до тех пор, пока их источник не будет выявлен и исправлен; • Динамические случайные дефекты (перекрестные, тер- мические эффекты, и т.п.), происходят при определен- ных обстоятельствах, и на некоторое время исчезают. Программное обеспечение, как правило, не имеет случай- ных отказов, но имеет высокую вероятность систематических ошибок. Как только систематическая ошибка обнаружена, она может быть исправлена - и перестанет существовать. Диагностические тесты. Диагностика может быть вы- полнена с помощью разнообразной комбинации методов, включая: • Автоматические встроенные тесты, предусмотренные в пределах приобретенного оборудования ПАЗ (на- пример, внутренние тесты модулей ввода-вывода); • Автоматический тест, встроенный как часть специфи- ческого проекта (например, контрольное чтение вы- ходных сигналов через входные точки); • Сторожевые таймеры, сравнение сигналов, обнаруже- ние обрывов и т.п.; • Сравнение резервированных сигналов. Диагностический охват. Конкретная диагностическая техника на практике не может достичь 100% эффективности в обнаружении всех возможных отказов. Поэтому оценка эф- фективности использованной диагностики может рассматри- ваться только для определенного набора конкретных отказов, на выявление которых эта диагностика нацелена. Критические и потенциально критические сбои (подобно сбоям CPU / RAM / ROM...) приведут к полному сбою всей обработки данных и, следовательно, вызовут более далеко идущий отказ, чем отказ единственной выходной точки. По- этому требования к обнаружению данного типа отказов долж- ны быть максимально строгими. Глава Р. Особенности проектирования систем безопасности 553 Режимы подобных отказов, которые несут высокую веро- ятность аварийной ситуации на процессе, должны обнаружи- ваться с наибольшей вероятностью. Для каждой диагностиче- ской процедуры необходимо четко определить: • Периодичность испытаний; • Порядок действий при обнаружении дефектов; • Согласованность предпринимаемых действий со Спе- цификацией требований безопасности. В тех случаях, когда специфическая диагностика не встроена в оборудование поставщика на аппаратном уровне, необходимые диагностические процедуры должны быть встроены в системное программное обеспечение. Диагностика не всегда способна обнаружить системати- ческие ошибки (подобные программным дефектам). Тем не менее, соответствующие меры предосторожности для обнару- жения возможных систематических дефектов должны быть предприняты. Общие рекомендации. Цель системы безопасности за- ключается в защите от аварийных ситуаций на процессе, и в предохранении от ложных остановов. Система безопасности в течение длительного времени находится в ждущем режиме, и подвержена функциональным отказам, которые, вообще гово- ря, носят неявный характер. Степень внутреннего диагностического охвата в принципе не может достигнуть ста процентов. Поэтому система защиты нуждается в периодической проверке. При этом должны быть обеспечены следующие условия: • Процедура тестирования должна быть максимально простой и быстрой; • Замена дефектных компонентов должна производиться в реальном времени; • Процедура замены должна быть простой и понятной, чтобы провести ее быстро и безошибочно; • Кроме того, должна быть продумана процедура дебло- кировки полевых устройств с целью поверки, калиб- ровки и обслуживания. Интервал времени между поверочным тестированием имеет очень важное значение, поскольку, с одной стороны, увеличение частоты тестирования снижает вероятность опас- ных отказов, а с другой, - потенциал для совершения челове- 554 Справочник инженера по А СУТП: Проектирование и разработка ческих ошибок во время тестирования очень высок. При вы- боре интервала следует учитывать следующие соображения: 1. Степень резервирования системы и уровень внутрен- ней диагностики; 2. Потенциал человеческих ошибок, обусловленный про- цедурой тестирования и замены; 3. Время, необходимое для выполнения тестирования и замены. Во время автономного тестирования система не в состоя- нии выполнять функции защиты. Поэтому поверочное тести- рование увеличивает и неготовность системы защиты, и веро- ятность человеческих ошибок. С другой стороны, редкое тес- тирование увеличивает риск развития невыявленных ошибок, в особенности для систем с низким уровнем диагностики. Отечественный общепринятый межповерочный интервал составляет 1 год. Текущая проверка сомнительных элементов оборудования осуществляется при необходимости. 9.16. Обслуживание и поверка полевого оборудования системы безопасности (по рекомендациям TUV) В этом разделе описывается процедура обхода блокиров- ки и технического обслуживания отдельных компонентов сис- тем безопасности: сенсоров, контроллеров, исполнительных элементов, рекомендованная TUV. Особое внимание необходимо уделять следующим аспек- там технического обслуживания: 1. Проведение технического обслуживания посредством обычного ПК или инженерной станции РСУ; 2. Соблюдение общих требований к протоколам связи, используемым в системах защиты; 3. Проведение технического обслуживания посредством публичных сетей типа Internet; 4. Обеспечение требуемой готовности; 5. Процедуры изменения системных данных; 6. Процедуры замены сенсоров и исполнительных уст- ройств, и связанные с этим изменения прикладного программного обеспечения. Глава Р. Особенности проектирования систем безопасности 555 Методы проверки периферийного оборудования сис- темы безопасности. В настоящее время существуют несколь- ко методов проверки периферийного оборудования, подклю- ченного к контроллеру системы ПАЗ: 1. Специальные ключи, подключенные как входы в кон- троллер системы ПАЗ. Эти входы используются в ка- честве признака деблокировки сенсоров и исполни- тельных устройств во время технического обслужива- ния. Условия и способы обслуживания встраиваются как часть прикладного программного обеспечения ПАЗ. 2. На время технического обслуживания сами сенсоры и приводы электрически изолируются (отключаются) от контроллера системы ПАЗ, и поверяются вручную в соответствии с методикой. В ряде случаев удобно осуществлять функции обслужи- вания дистанционно, например, через инженерную стан- цию РСУ. 3. Таким образом, появляется третья возможность для проведения технического обслуживания: - Команды деблокировки инициируются отдельными от системы безопасности средствами, и направля- ются в контроллер системы ПАЗ по последователь- ному протоколу; - Связь с контроллерами системы ПАЗ должна обес- печиваться с использованием только разрешенных протоколов. Можно использовать протоколы, кото- рые признаны соответствующими принятому уров- ню безопасности (такие, как Modbus), или рекомен- дуемые протоколы изготовителя оборудования сис- темы; - В общем случае разрешается использовать только те средства, которые разрешены для конкретного применения; - Если коммуникация осуществляется посредством открытых сетей, то в дополнение к требованиям функциональной безопасности должны быть опре- делены дополнительные требования, гарантирую- щие безопасность доступа. 556 Справочник инженера по А СУТП: Проектирование и разработка 4. Наиболее эффективное средство обслуживания поле- вого оборудования - выделенная система обслужива- ния полевого оборудования - Plant Asset Management System - система управления оборудованием произ- водства. Допустимые режимы обслуживания и протоколы связи должны быть частью сертифицированной системы безопасно- сти, чтобы они применялись безопасным образом. Процедуры проведения операций деблокировки и внесе- ния изменений в процессе работы должны быть описаны в руководствах по обслуживанию АСУТП. При этом строго ре- комендуется, чтобы средства программирования и отладки были отделены от средств технического обслуживания. Если потребовалось внести изменения в ППО, то тестиро- вание не должно фокусироваться исключительно на тех частях программного обеспечения, которые подверглись изменению, поскольку это не дает гарантии, что внесенные изменения не оказывают воздействия на неизмененные части. Полнота тестирования системы, подвергнутой изменению, должна соответствовать полноте первоначальных приемо- сдаточных испытаний. И поскольку данная процедура по своим последствиям является дорогостоящей, использование средств, не имеющих специального разрешения фирмы-изготовителя, строго не рекомендуется. Разрешенные средства технического обслуживания в об- щем случае должны отвечать следующим требованиям: • Включать измерения, позволяющие проконтролиро- вать случайные сбои вновь созданной или модифици- рованной программы; • Включать в себя измерения, позволяющие проконтро- лировать случайные ошибки данных по каналу связи с контроллером; • Они должны быть разработаны под конкретную вер- сию программного обеспечения; • Они должны быть разработаны с использованием средств проверки прикладного программного обеспе- чения, и средств контроля изменений. Глава Р. Особенности проектирования систем безопасности 557 Общая стратегия технического обслуживания: 1. Общая стратегия и процедуры технического обслужи- вания должны быть разработаны до, или во время раз- работки прикладного программного обеспечения. 2. Процедуры технического обслуживания в составе при- кладного программного обеспечения системы защиты должны предусматривать возможность деблокировки строго ограниченного набора конкретных сигналов. 3. Команды деблокировки должны контролироваться и осуществляться во взаимодействии с прикладным про- граммным обеспечением РСУ и системы ПАЗ. 4. Схемы и алгоритмы автоматического срабатывания системы противоаварийной защиты должны быть на- строены таким образом, чтобы была обеспечена их не- зависимость от логических цепей, по которым осуще- ствляется выполнение команд инженера по техниче- скому обслуживанию. 5. Команда "Разрешение на деблокировку" с целью тех- нического обслуживания возможна для целой подсис- темы (технологического блока), или контроллера сис- темы ПАЗ в целом, и может быть подана с РСУ, или другим разрешенным способом, например, физиче- ским ключом. 6. Однако "Разрешение на деблокировку" не означает, что собственно команда какой-либо конкретной де- блокировки действительно будет выдана. 7. Деблокировка группы параметров разрешается только в том случае, если только одна деблокировка исполь- зуется в данной группе параметров. Оператор техноло- гического процесса должен подтвердить наступление состояния деблокировки. Непосредственная (т.е. с по- мощью физических зажимов) деблокировка входов и выходов не разрешается. Взаимодействие с технологом-оператором: 1. Технолог-оператор не должен иметь возможности от- менить сигнализацию деблокировки. При любых об- стоятельствах должно быть ясно, что данные входы- выходы находятся в состоянии деблокировки. 2. Контроллер системы ПАЗ извещает оператора РСУ о присутствии условий деблокировки. 558 Справочник инженера по А СУТП: Проектирование и разработка Данное предупреждение действует до момента восста- новления сигнала (снятия деблокировки). 3. Во время деблокировки проводятся необходимые ра- бочие операции и проверки, чтобы удостовериться, что сигнал может быть возвращен в исходное состояние. 4. Программное обеспечение в РСУ должно постоянно проверять соответствие между выданными из РСУ ко- мандами на деблокировку, и откликом, полученным от контроллера системы ПАЗ в РСУ. 5. Использование функций деблокировки должно быть документировано в архиве РСУ или другом, специаль- но выделенном оборудовании. 6. Распечатка протокола операций по деблокированию и техническому обслуживанию должна включать: - Шифр позиции КИП деблокированного сигнала; - Отметки времени начала действия команды дебло- кировки; - Отметки времени окончания действия команды де- блокировки; - Идентификацию конкретного исполнителя проце- дуры деблокировки. 9.17. Секретность Должны быть предусмотрены специальные средства кон- троля над доступом к системе безопасности, включая все главные компоненты системы: • Логические решающие устройства; • Интерфейсы технического обслуживания; • Функции тестирования системы ПАЗ; • Функции деблокировки; • Отключение тревожной сигнализации ПАЗ; • Сенсоры; • Конечные исполнительные элементы. Защита доступа может предусматривать: • Стойки системы - под замок и на физический ключ; • Доступ "только чтение"; • Коды доступа, Пароли; • Административные ограничения и т.п. Глава Р. Особенности проектирования систем безопасности 559 9.18. Документация Состав документации. Состав документации системы безопасности должен включать, как правило, следующее: • Спецификация требований безопасности; • Описание функций ПАЗ; • Схемы измерительных контуров и контуров защиты системы ПАЗ (Loop Diagrams); • Распечатка программ логического управления и защи- ты системы ПАЗ; • База данных сигналов ввода-вывода системы ПАЗ; • База данных параметров обмена с РСУ; • База данных для программы определения первопричи- ны срабатывания системы защиты; • Чертежи компоновки системы в шкафах; • Установочные чертежи; • Схемы и конфигурация модулей ПАЗ; • Схемы распределения питания внутри шкафов; • Схемы заземления; • Кабельный журнал внутрисистемных соединений; • Схемы подключения каналов и внешних источников питания; • Таблицы подключения каналов ввода-вывода к терми- нальным панелям и клеммным сборкам шкафов систе- мы ПАЗ; • Заключение о проведении заводских испытаний обо- рудования ПАЗ на площадке изготовителя; • Инструкции по монтажу и наладке; • Процедура приемосдаточных испытаний; • Инструкции по эксплуатации и техническому обслу- живанию; • Процедура функционального тестирования; • Порядок внесения изменений в документацию. Примечание Строго определенный состав проектной документации приведен в главе "Состав и содержание документации про- екта АСУТП" настоящей работы. 560 Справочник инженера по А СУТП: Проектирование и разработка Резервная копия программного обеспечения. Техника резервного копирования позволяет провести операцию вос- становления системы в кратчайшие сроки. Эти методы защи- ты могут включать следующее: • Копирование на сменные носители: магнитная лента или оптический диск, с которого можно произвести восстановление; • Копирование на сменные носители, которые могут ис- пользоваться как замена для поврежденной системы; • Копия на дублирующий (зеркальный) диск; • Копирование по каналу связи с другой цифровой сис- темой. 9.19. Временной интервал функционального тестирования Частота проведения функциональных тестов должна, как минимум, соответствовать рекомендациям изготовителя, или более часто, если это согласуется с предшествующим опытом работы. Настоятельная рекомендация - создание самостоятельной системы обслуживания полевого оборудования, а именно: внедрение так называемой Plant Asset Management System - системы управления оборудованием производства, позво- ляющей производить оперативное тестирование и диагно- стику оборудования КИПиА. 9.20. Управление и контроль выполнения проекта Примечание Представленные рекомендации относятся к проекту создания собственно системы защиты, однако не отменяют, а дополняют общие рекомендации по порядку выполнения проектных работ для АСУТП в целом - в соответствии с главой "Состав и содержание работ по созданию АСУТП". Организация выполнения проекта. Для каждой из ор- ганизаций, участвующих в процессе выполнения проекта, оп- ределяются лица, ответственные за сроки и качество выполне- ния Проекта в соответствии с Техническим заданием на соз- |