ГОСТ Р МЭК 61511-2—2011
получаемый во время перемещения клапана (например, от полностью открытого до полностью закры
того положения), следует использовать значительные временные задержки. Если клапан в ходе нор
мальной работы периодически меняет свое безопасное состояние (например, в операциях
дозирования), то это сравнение сигнала обратной связи исполнительного элемента с требуемым его
состоянием можно рассматривать только как диагностическую операцию;
2) некоторые клапаны, приводы, соленоиды и/или позиционеры могут обладать способностью к
самодиагностированию;
c) для логических решающих устройств:
- в типовых случаях программируемые электронные логические устройства, подготовленные для
задач безопасности или отвечающие требованиям серии стандартов МЭК 61508. включают в себядиаг
ностические средства, выявляющие различные неисправности. Типы таких средств и их степень диаг-
ностируемости обычно описываются в руководствах по безопасности;
d) для внешних средств диагностики:
- примерами таких средств служат контрольные (сторожевые) таймеры и концевые мониторы.
В связи с примечанием к перечислению с) пункта 11.9.2 МЭК 61511-1, в котором рассмотрена сте
пеньдоверия к данным по надежности, среднее время до отказа Тср обычно определяется путем регис
трации числа отказов п. происшедших на образцах компонентов за накопленное число часов работы Г.
Уровень доверия к результирующему значению Г рможет быть получен по критерию «Хи — квадрат»
[11]. Это означает, что значение Гср, которое должно применяться в расчетах надежности ПСБ, будет,
вообще говоря, ниже, чем Тср, рассчитанное как Т/п. Такое снижение будет тем больше, чем выше тре
буемый уровень доверия и чем меньше число зафиксированных отказов. Однако, как правило, можно
принимать, что при уровне доверительной вероятности 70 % коэффициент снижения незначителен по
сравнению с другими источниками неопределенностей, связанных с моделированием надежности.
12 Требования к прикладному ПО, включая критерии выбора
сервисного ПО
В разделе 12 МЭК61511 -1 неделается различий в методах разработки прикладногопрограммного
обеспечения (ППО) для систем с УПБ 3 и с более низким УПБ. так как опыт показывает, что существует
небольшая разница в методах, используемых для:
- программ, составленных на ФЯП или ЯОИ;
- логических устройств, отвечающих требованиям МЭК 61511-1;
- соответствующих руководств по безопасности.
При разных УПБ могут быть различия в испытаниях и верификации. Дополнительные указания см.
в 12.7.2.3.
12.1 Требования к жизненному циклу безопасности ППО
12.1.1 Цели
12.1.1.1 Дополнительные требования не предусмотрены.
12.1.2 Требования
12.1.2.1 Дополнительные требования не предусмотрены.
12.1.2.2 Кпримечаниям 1и 2 МЭК 61511-1. Еслидля разработки, реализации, верификации и под
тверждения соответствия прикладных программ применяются ЯОИ. такие как язык ступенчатых диаг
рамм или функциональных блок-схем по {12]. то применимы только два уровня стандартной V-модели ПО.
показанные на рисунке 3. В этом случае принимается, что используемые функциональные блоки
соответствуют МЭК 61508-3. и тогда:
- «разработка архитектуры ППО» применяется к ПО каждой функции безопасности ПСБ так. что
бы обеспечить совместимость проекта ПО со структурой аппаратных средств;
- «разработка ППО» интерпретируется как проектирование и реализация логики безопасности,
построенной на ЯОИ в соответствии с МЭК 61508-3 и МЭК 61508-4;
- «проверка ППО» интерпретируется как верификация и испытание прикладных программ, и
- «интеграция ППО с подсистемами ПСБ» трактуется как интеграция и верификация каждой функ
ции безопасности процесса, выполненной на ЯОИ.
Пример жизненного цикла разработки ППО. используемого в П
Л
К с УПБ 3. соответствующий
МЭК 61508. приведен в приложении D.
27