ГОСТ Р МЭК 61508-3-2012 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению

     

Приложение D
(обязательное)

     
Руководство по безопасности для применяемых изделий. Дополнительные требования к элементам программного обеспечения

D.1 Цель руководства по безопасности

D.1.1 Когда элемент используется вновь или предполагается, что он будет снова использован в одной или более других разрабатываемых системах, необходимо гарантировать, что этот элемент сопровождался достаточно точным и полным описанием (функций, ограничений и доказательств), с тем чтобы обеспечить возможность оценки полноты безопасности, заданной функции безопасности, которая полностью или частично реализуется этим элементом. Такие действия должны выполняться только с использованием руководства по безопасности.

D.1.2 Руководство по безопасности может состоять из документации поставщика элемента, если она соответствует требованиям приложения D МЭК 61508-2 и настоящего приложения. В противном случае такая документация должна быть создана как часть проекта системы, связанной с безопасностью.

D.1.3 Руководство по безопасности должно определять атрибуты элемента, которые могут включать в себя аппаратные и/или программные ограничения, которые интегратор должен знать и учесть в процессе реализации применения. В частности руководство по безопасности является источником информации для интегратора о свойствах элемента и для чего он был разработан, о поведении элемента и его характеристиках.

Примечания

1 Область применения и время поставки руководства по безопасности будет зависеть от того, кто его применяет, от типа интегратора, цели элемента и оттого, кто его поставляет и поддерживает.

2 Физическое лицо или отдел, или организацию, которые интегрируют программное обеспечение, называют "интегратором".

D.2 Содержание руководства по безопасности для элемента программного обеспечения

D.2.1 Руководство по безопасности должно содержать всю информацию, требуемую по приложению D МЭК 61508-2, которая относится к элементу. Например, пункты приложения D МЭК 61508-2, связанные с аппаратными средствами, не относятся непосредственно к элементу программного обеспечения.

D.2.2 Элемент должен быть идентифицирован, и все необходимые указания по его использованию должны быть доступны интегратору.

Примечание - Для программного обеспечения это может быть продемонстрировано с помощью четкого определения элемента и демонстрацией того, что содержание информации об элементе остается неизменным.

D.2.3 Конфигурация элемента:

a) Конфигурация элемента программного обеспечения, среды выполнения программного и аппаратного обеспечения и, в случае необходимости, конфигурации системы компиляции/связей должны быть документально оформлены в руководстве по безопасности.

b) Рекомендуемая конфигурация элемента программного обеспечения должна быть документально оформлена в руководстве по безопасности, и эта конфигурация должна использоваться в применении, связанном с безопасностью.

c) Руководство по безопасности должно включать в себя все сделанные предположения, от которых зависит обоснование использования элемента.

D.2.4 Руководство по безопасности должно содержать:

a) Компетентность. Должен быть определен минимальный уровень знаний, предполагаемый для интегратора элемента, то есть знание конкретных инструментальных средств применения.

b) Степень доверия, отнесенная к элементу. Информация о любой сертификации элемента, прошедшего независимую оценку, значении полноты, которую интегратор может приписать уже существующему элементу. Эта информация должна включать в себя данные о полноте безопасности, для которой элемент разрабатывается, о стандартах, использовавшихся во время процесса проектирования, и о любых ограничениях, которые интегратор должен реализовать для обеспечения требуемой стойкости к систематическим отказам. (В зависимости от функциональности элемента возможно, что некоторые требования могут быть удовлетворены только на стадии интеграции системы. В таких случаях эти требования должны быть идентифицированы для дальнейшего использования интегратором, например время отклика и быстродействие.)

Примечание - В отличие от МЭК 61508-2 настоящий стандарт не требует, чтобы в руководстве по безопасности для применяемых изделий были указаны режимы отказов программного обеспечения или значения интенсивностей отказов, так как причины отказов программного обеспечения существенно отличаются от причин случайных отказов оборудования, см. приложение D МЭК 61508-2.

c) Инструкции по установке. Подробное описание или ссылка на него о том, как установить уже существующий элемент в интегрированную систему.

d) Причина появления релиза элемента. Подробное описание того, что уже существующий элемент стал предметом очередного релиза, чтобы устранить серьезные отклонения или включить дополнительный функционал.

e) Серьезные отклонения. Должно быть приведено подробное описание всех серьезных отклонений с объяснением того, как происходит каждое отклонение, а также механизмы, которые должен использовать интегратор для ослабления отклонения, влияющего на конкретные функции.

f) Совместимость с предыдущими релизами. Подробное описание того, совместим ли элемент с предыдущими релизами подсистемы, а в противном случае - подробное описание процедуры его обновления, которую необходимо выполнить.

g) Совместимость с другими системами. Уже существующий элемент может зависеть от специально разработанной операционной системы. В таких случаях должны быть подробно описаны детали версии специально разработанной операционной системы.

Должен также быть определен стандарт на создание элемента, включающий в себя идентификацию и версию компилятора, инструменты, используемые для создания уже существующего элемента (идентификацию и версию), и используемый тест для уже существующего элемента (идентификацию и версию).

h) Конфигурация элемента. Для уже существующего элемента должны быть даны имя (имена) и описание(я), включая версию элемента/номер элемента/состояние модификации элемента.

i) Управление изменениями. Механизм, с помощью которого интегратор может инициировать запрос на изменение разработчику программного обеспечения.