- необходимость минимального вмешательства человека;
- необходимое вмешательство наиболее простым;
- возможность минимального ущерба от ошибок оператора;
- эргономические требования при проектировании средств вмешательства и индикации;
- простые, имеющие четкую маркировку и удобные для использования средства оператора;
- неперенапряженность оператора даже в экстремальной ситуации;
- адаптированность обучения процедурам и средствам процесса вмешательства к уровню знаний и мотивации обучаемого пользователя.
B.4.3 Удобство общения с обслуживающим персоналом
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.4).
Цель: упрощение процедуры обслуживания систем, связанных с безопасностью, и проектирование необходимых средств для эффективной диагностики и ремонта.
Описание: профилактическое обслуживание и ремонт часто проводятся в сложных условиях давления предельных сроков. Поэтому разработчик систем, связанных с безопасностью, должен предусмотреть чтобы:
- средства, относящиеся к обслуживанию безопасности, требовались как можно реже или вообще не требовались;
- использовались достаточно чувствительные и легко управляемые диагностирующие инструменты для неизбежных ремонтов; эти инструменты должны включать в себя все необходимые интерфейсы;
- было достаточно времени (если отдельные инструменты диагностики необходимо разработать или приобрести).
B.4.4 Сокращение работ на стадии эксплуатации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.4 и В.6).
Цель: снизить эксплуатационные возможности для обычного пользователя. Описание: этот подход снижает эксплуатационные возможности путем:
- ограничения операций в рабочих режимах, например коммутаторами ключей;
- ограничения числа используемых в работе элементов;
- ограничения числа возможных в общем случае рабочих режимов.
Литература:
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.4.5 Эксплуатация только квалифицированным оператором
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.4 и В.6).
Цель: исключение отказов, обусловленных ошибками оператора.
Описание: оператор системы, связанной с безопасностью, обучен до степени, соответствующей сложности и степени безопасности систем, связанных с безопасностью. В обучение входит изучение основ процесса производства и взаимосвязей между системами, связанными с безопасностью и EUC.
Литература:
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.4.6 Защита от ошибок оператора
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.6).
Цель: защита системы от всех видов ошибок оператора.
Описание: ложные входные сообщения (значение, время, и т.д.) обнаруживаются проверками достоверности или контролем EUC. Для того, чтобы объединить эти средства в проекте, необходимо на самом раннем этапе определить, какие из входных сообщений возможны и какие допустимы.
B.4.7 (Не используется)
B.4.8 Защита от модификаций
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица А.18).
Цель: защита системы, связанной с безопасностью, от модификаций аппаратных средств техническими способами.
Описание: модификации или манипуляции обнаруживаются автоматически, например проверками достоверности сигналов датчиков, обнаружением техническим процессом и автоматическим запуском тестирования. При обнаружении модификации выдается аварийный сигнал.
B.4.9 Подтверждение ввода
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы А.18 и А.19).
Цель: обнаружение ошибки во время работы самим оператором до активизации EUC.
Описание: информация, вводимая в EUC через систему, связанную с безопасностью, представляется оператору до передачи в EUC с тем, чтобы оператор имел возможность обнаружить и исправить ошибки. Проектируемая система должна реагировать на неправильные, самопроизвольные действия оператора и учитывать нижние/верхние пределы скорости и направление реакции оператора. Это позволит исключить, например, более быстрое, чем предполагается, нажатие клавиш оператором, и настроить систему воспринимать двойное нажатие клавиши как одинарное или двойное за счет того, что система (изображение на экране) слишком медленно реагирует на разовое нажатие клавиши. Последовательное нажатие одной и той же клавиши при вводе критических данных должно восприниматься системой как одноразовое; нажатие клавиш «ввод» (enter) или «да» (yes) неограниченное число раз не должно приводить к нарушению безопасности системы.
Должны быть предусмотрены процедуры формирования временных пауз с возможностью выбора разных ответов (да/нет и т.п.) с тем, чтобы обеспечить возможность для размышления оператору, а системе - режим ожидания.
Любая перезагрузка PES, связанной с безопасностью, делают систему уязвимой, если программные/аппаратные средства не спроектированы с учетом этой ситуации.
Литература:
DIN V VDE 0801: Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben (Principles for Computers in Safety-Related Systems) Beuth-Verlag, Berlin, 1990.
B.5 Интеграция E/E/PES
Главная цель: исключение отказов системы на стадии интеграции и обнаружение любых отказов во время этой и предыдущей стадий.
В.5.1 Функциональное тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3 и В.5) и в МЭК 61508-3 (таблицы А.5 - А.7).
Цель: обнаружение отказов на стадиях создания спецификации и проектирования. Исключение отказов во время реализации и интеграции программных и аппаратных средств.
Описание: в процессе функционального тестирования определяется, достигнуты ли заданные характеристики системы. В систему поступают входные данные, которые адекватно характеризуют обычное выполнение операций. Наблюдаемые выходные результаты сравниваются с заданными в спецификации. Отклонения от спецификации и указания на неполноту спецификации документируются.
Функциональное тестирование электронных компонентов, предназначенных для многоканальной архитектуры, обычно включает в себя промышленные компоненты, каждый из которых поставщик уже протестировал и предварительно подтвердил соответствие. Помимо этого рекомендуется, чтобы покупные промышленные компоненты были протестированы в сочетании с другими компонентами поставщика из той же партии, чтобы выявить неисправности группового типа, которые в противном случае остались бы невыявленными.
Также о достаточных рабочих возможностях системы см. руководящие материалы (приложение С, подраздел С.5.20).
Литература:
Functional Program Testing and Analysis. W. E. Howden, McGraw-Hill, 1987. The Art of Software Testing. G. J. Myers, Wiley & Sons, New York, 1979.
Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.
B.5.2 Тестирование методом «черного ящика»
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3, В.5 и В.6) и в МЭК 61508-3 (таблицы А.5 - А.7).
Цель: проверка динамического поведения системы в реальных условиях функционирования. Выявление несоответствия функциональной спецификации и оценка ее полезности и устойчивости.
Описание: функции системы или программы выполняются в заданном окружении с заданными данными тестирования, которые систематически формируются из спецификации в соответствии с установленными критериями. Это позволяет поведение системы сравнить с ее спецификацией. При проведении тестирования никакие сведения о внутренней структуре системы не используются. Основная цель состоит в том, чтобы определить, правильно ли выполняет функциональный модуль функции, требуемые спецификацией. Метод формирования эквивалентных классов служит примером критерия тестирования данных методом «черного ящика». Массив входных данных подразделяется на конкретные диапазоны входных значений (эквивалентные классы) на основе спецификации. После этого формируются тестовые примеры из:
- данных из допустимых диапазонов;
- данных из недопустимых диапазонов;
- данных предельных значений диапазонов;
- экстремальных значений и
- комбинаций из перечисленных выше классов.
Могут оказаться эффективными также другие критерии выбора тестовых примеров в различных режимах тестирования (модуля, интеграции и системы). Например, критерий «экстремальные эксплуатационные условия» используется при тестировании системы в процессе подтверждения соответствия.
Литература:
Functional Testing and Analysis. W. E. Howden, McGraw-Hill Book Comppany, New York, 1987.
Software Testing and Validation Techniques. E. Miller, W. E. Howden, IEEE Computer Society, New York, 1978.
The Art of Software Testing. G. J. Myers, Wiley & Sons, New York, 1979.
Methodik systematischen Testens von Software. K. Grimm, 30 (4), 1988.
VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.
B.5.3 Статистическое тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3, В.5 и В.6).
Цель: проверка динамического поведения системы, связанной с безопасностью, и оценка ее полезности и устойчивости.
Описание: при этом подходе тестируется система или программа с входными данными, выбранными в соответствии с предполагаемым статистическим распределением реальных эксплуатационных входных данных - эксплуатационный профиль.
Литература:
Software Testing via Environmental Simulation (CONTESSE Report). Available until December 1998 from: Ray Browne, CIID, DTI, 151 Buckingham Palace Road, London, SW1W 9SS, UK, 1994.
Aspects of Development and Verification of Reliable Process Computer Software. W. Ehrenberger, IFAC-IFIP Conference Proceedings, 35-48, 1980.
Verification and validation of Real-time Software. W. J. Quirk (ed.), Springer Verlag, Berlin, 1985.
VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.
Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN 1-85166-203-0.
Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.
B.5.4 Полевые испытания
Примечания
1 См. также приложение С, подраздел С.2.10 - аналогичные средства, а в приложении D - статистический подход - то и другое в контексте программного обеспечения.
2 Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3 и В.5).
Цель: использование полевых испытаний из различных областей применения в качестве одного из средств исключения сбоев во время интеграции E/E/PES и/или в процессе подтверждения соответствия безопасности E/E/PES.
Описание: использование компонентов или подсистем, которые при их использовании показали путем испытаний отсутствие или наличие только несущественных ошибок и существенно не изменялись в течение достаточно длительного периода времени во многих различных применениях. В частности, для сложных компонентов с множеством функций (например, операционной системы интегральных схем) разработчик должен обратить внимание на функции, которые были фактически протестированы методом полевых испытаний. Например, должны быть рассмотрены подпрограммы самотестирования для обнаружения сбоев: при отсутствии сбоев аппаратных средств в период эксплуатации о подпрограммах нельзя сказать, что они протестированы, поскольку они никогда не выполняли функций обнаружения своих сбоев.
При использовании полевых испытаний должны быть соблюдены следующие требования:
- неизменность спецификации;
- наличие 10 систем в различных применениях;
- длительность работы 105 ч и, по меньшей мере, один год сервисной поддержки.
Полевые испытания документируются поставщиком и/или эксплуатирующей организацией; документация должна, по меньшей мере, содержать:
- точное обозначение системы и ее компонентов, включая управление версиями аппаратных средств;
- сведения о пользователях и времени применения;
- отработанное время в часах;
- процедуры выбора системы и прикладные программы, использованные при испытаниях;
- процедуры обнаружения и регистрации сбоев, а также процедуры устранения их последствий и причин возникновения.
Литература:
DIN V VDE 0801 А1: Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben (Principles for Computers in Safety-Related Systems). Änderung 1 zu DIN V VDE 0801/01.90. Beuth-Verlag, Berlin, 1994.
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.6 Подтверждение безопасности E/E/PES
Главная цель: Подтвердить, что система Е/Е/РЕ, связанная с безопасностью, соответствует спецификации требований безопасности E/E/PES.
В.6.1 Функциональные испытания в условиях окружающей среды
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.5).
Цель: оценка защищенности системы, связанная с безопасностью, от типовых воздействий окружающей среды.
Описание: систему помещают в различные условия окружающей среды (например, в соответствии со стандартами серии МЭК 60068 или серии МЭК 61000) и оценивают способности системы выполнять функции безопасности (на соответствие требованиям стандартов, указанных выше) [1], [5].
Литература:
Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.
B.6.2 Испытания на устойчивость к пиковым выбросам внешних воздействий
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).
Цель: проверка способности систем, связанных с безопасностью, справляться с пиковыми выбросами внешних воздействий.
Описание: в систему загружается типичная прикладная программа и все периферийные линии (цифровые, аналоговые и последовательные интерфейсы, шины, источники питания и т. д.) подвергаются воздействию стандартных шумовых сигналов. Для того, чтобы получить их количественную оценку, целесообразно внимательно подходить к предельным значениям выбросов внешних влияний. Класс помех считается выбранным неверно, если функция системы не выполняется [6].
B.6.3 (Не используется).
B.6.4 Статический анализ
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6) и в МЭК 61508-3 (таблица А.9).
