ГОСТ Р МЭК 61511 -2—2011
ции требований по безопасности следует обращаться к разработчикам ПО (например, по вопросу
влияния порядка выполнения функции безопасности ПСБ в ПО). Другим примером может быть вопрос о
реакции ППО на прекращение питания.
12.2.2.3 Требования к безопасности ППО должны разрабатываться как прослеживаемое соответ
ствие спецификации требований к безопасности функции безопасности ПСБ. Необходимо обратиться к
следующим факторам:
- функциональные и временные требования, необходимыедля выполнения функции безопаснос
ти ПСБ, установленные пользователем:
- интерфейсы программной системы с процессом и персоналом;
- соотношение между опасностями процесса и функциями, выполняемыми ППО;
- ограничения на разрешенное поведение ППО, установленные так, чтобы процесс оставался в
пределах безопасной области (например, неспособность работать при неверных входных значениях):
- допустимые функциисервисного ПО. выполняемые влогическом решающем устройстве (напри
мер, реализация приоритета логики безопасности и коммуникаций ввода’вывода, обработка ошибок и
диагностика системы);
- платформа технических средств и системное ПО. на которых реализуется ППО. а также конфи
гурация технических средств и системного ПО;
- опасности, которые могут появляться в процессе в результате функционирования системы, час
тью которой является ПО (например, неподходящие виды отказов технических средств при отключении
питания);
- ограничения на методы и процедуры, которыми могли бы пользоваться разработчики, вытекаю
щие из инструкции по безопасности при обслуживании логического устройства.
Чтобы избежать трудностей на более поздних стадиях процесса разработки, важно также рас
смотреть стратегию, с помощью которой можно показать, что требования к ППО выполнены.
Если в ПСБ используется ППО. то оценка функциональной безопасности может включать:
- применение способов контроля, показывающих, что функции ППО соответствуют требованиям,
вытекающим из опасностей процесса;
- функциональные испытания, показывающие, что ППО исполняет требуемые функции и. на
сколько это возможно, любые дополнительные функции ПО не приводят к опасным условиям:
- структурные испытания, показывающие, что ППО выполняет требуемые функции за необходи
мое время;
- анализ функциональных отказов и анализ по методу «что, если», позволяющие показать, что
функции ППО не приводят к опасным условиям;
- аудит, показывающий, что процессы разработки и верификации проведены под контролем и что
применена правильная версия ПО.
12.2.2.4 Дополнительные требования не предусмотрены.
12.2.2.5 Дополнительные требования не предусмотрены.
12.2.2.6 Дополнительные требования не предусмотрены.
12.3 Планирование подтверждения соответствия безопасности ППО
Дополнительные указания см. в 14.3.
12.3.1 Цель
12.3.2 Требования
12.3.2.1 Дополнительные требования не предусмотрены.
12.4 Проектирование и разработка ППО
12.4.1 Цели
12.4.1.1 Дополнительные требования не предусмотрены.
12.4.1.2 Дополнительные требования не предусмотрены.
12.4.1.3 Дополнительные требования не предусмотрены.
12.4.1.4 Дополнительные требования не предусмотрены.
12.4.1.5 Дополнительные требования не предусмотрены.
12.4.2 Общие требования
Существует ряд подходов к созданию безопасного ППО ПСБ. Однако независимо от того, какой
подход используется для достижения безопасности ППО, принимается, что стадии жизненного цикла
безопасности, предшествующие разработке прикладных программ (например, оценка опасностей и
31