Примечания
1 См. также таблицы А.7 (приложение А), В.3 и В.5 (приложение В).
2 Данная стадия представлена на рисунке 3 (см. 9.6).
7.7.1 Цели
Цель требований настоящего подраздела - гарантировать соответствие интегрированной системы специфицированным требованиям к безопасности программного обеспечения (см. 7.2) на заданном уровне полноты безопасности.
7.7.2 Требования
7.7.2.1 Если соответствие требованиям к безопасности программного обеспечения уже было установлено для Е/Е/РЕ системы, связанной с безопасностью (МЭК 61508-2, пункт 1.7), проводить повторное подтверждение соответствия не требуется.
7.7.2.2 Операции подтверждения соответствия должны выполняться в соответствии со спецификациями, разработанными при планировании подтверждения соответствия безопасности программного обеспечения (см. 7.3).
7.7.2.3 Результаты подтверждения соответствия безопасности программного обеспечения должны быть документированы.
7.7.2.4 При проведении подтверждения соответствия безопасности программного обеспечения для каждой функции безопасности должны быть документированы следующие результаты:
a) хронологический перечень операций подтверждения соответствия;
b) используемая версия плана подтверждения соответствия безопасности программного обеспечения (см. 7.3);
c) подтверждаемые функции безопасности (с использованием тестирования или анализа), со ссылками на план подтверждения соответствия безопасности программного обеспечения (см. 7.3);
d) использованные инструменты и оборудование, а также данные калибровки;
e) результаты операций подтверждения соответствия;
f) расхождения между ожидаемыми и фактическими результатами.
7.7.2.5 При наличии расхождений между ожидаемыми и фактическими результатами проводится анализ и принимается решение, продолжать ли проверку или подготовить запрос на изменение и вернуться к более ранней стадии жизненного цикла разработки. Это решение должно быть документировано как часть результатов подтверждения соответствия безопасности программного обеспечения.
Примечание - Требования 7.7.2.2 - 7.7.2.5 основываются на общих требованиях МЭК 61508-1 (пункт 7.14).
7.7.2.6 Подтверждение соответствия программного обеспечения, связанного с безопасностью, должно удовлетворять следующим требованиям:
a) основным методом подтверждения соответствия для программного обеспечения должно быть тестирование; анимацию и моделирование допускается использовать как дополнительные методы;
b) прогон программного обеспечения должен выполняться путем имитации:
- входных сигналов в нормальном режиме работы,
- предполагаемых случаев,
- нежелательных условий, требующих вмешательства системы;
c) поставщик и/или разработчик должны предоставить документированные результаты подтверждения соответствия безопасности программного обеспечения и всю имеющую отношение к этой операции документацию в распоряжение разработчика системы для того, чтобы дать ему возможность выполнить требования МЭК 61508-1 и МЭК 61508-2.
7.7.2.7 К качеству программных средств предъявляют следующие требования:
a) все программные средства, используемые при подтверждении соответствия, должны быть квалифицированы в соответствии со спецификациями, разработанными на основе международного стандарта (если таковой имеется) или национального стандарта (если таковой имеется), либо в соответствии с общепринятой процедурой;
b) оборудование, используемое при подтверждении соответствия, должно быть соответствующим образом квалифицировано, должна быть продемонстрирована пригодность для подтверждения соответствия всех используемых программных и аппаратных средств.
Примечание - В настоящем стандарте квалификация представляет собой операцию, которая демонстрирует выполнение конкретной спецификации, в отличие от базовых процедур проверки соответствия, которые могут использоваться по отношению к любой спецификации.
7.7.2.8 К результатам подтверждения соответствия программного обеспечения предъявляются следующие требования:
a) проверки должны показать, что все требования, предъявляемые к безопасности программного обеспечения (см. 7.2), выполняются правильно и что программная система не выполняет непредусмотренных функций;
b) тестовые примеры и их результаты должны быть документированы для последующего анализа и независимой экспертизы в соответствии с требованиями уровня полноты безопасности (МЭК 61508-1, пункт 8.2.12);
c) документированные результаты подтверждения соответствия безопасности программного обеспечения должны содержать утверждение о том, что программа прошла подтверждение соответствия, либо причины, по которым она не прошла его.
Примечания
1 См. также таблицу А.8 (приложение А).
2 Эта стадия представлена на рисунке 3 (см. 9.5).
7.8.1 Цели
Целью требований настоящего подраздела является внесение корректировок, улучшений или изменений в принятое программное обеспечение, гарантирующих сохранение уровня полноты безопасности программного обеспечения.
Примечание - В настоящем стандарте программное обеспечение (в отличие от аппаратного обеспечения) не может поддерживаться, оно всегда модифицируется.
7.8.2 Требования
7.8.2.1 Перед выполнением какой-либо модификации программного обеспечения должны быть подготовлены процедуры модификации (МЭК 61508-1, пункт 7.16).
Примечания
1 Требования 7.8.2.1 - 7.8.2.9 относятся, в первую очередь, к изменениям, выполняемым на этапе работы программного обеспечения. Они могут также применяться во время интеграции программируемой электроники, а также во время общей установки и ввода в эксплуатацию (МЭК 61508-1, пункт 7.13).
2 Пример модели процедуры модификации приведен в МЭК 61508-1 (рисунок 9).
7.8.2.2 Процесс модификации может начинаться только после появления запроса на санкционированную модификацию программного обеспечения в рамках процедур, определенных на этапе планирования безопасности (см. раздел 6), в котором приведена подробная информация:
a) об опасностях, на которые могут повлиять изменения;
b) о предлагаемых изменениях;
c) о причинах изменений.
Примечание - Причины появления запроса на модификацию могут быть, например, связаны с:
- тем, что функциональная безопасность оказалась ниже той, которая была определена в спецификациях;
- систематическими отказами;
- появлением нового или изменением действующего законодательства, относящегося к безопасности;
- модификацией EUC или способа его использования;
- модификацией общих требований к безопасности;
- анализом характеристик работы и обслуживания, который показывает, что эти характеристики имеют значения ниже запланированных;
- текущим аудитом функциональной безопасности.
7.8.2.3 Должен быть выполнен анализ влияния предлагаемых модификаций программного обеспечения на функциональную безопасность Е/Е/РЕ систем, связанных с безопасностью:
a) определить, необходим или нет анализ рисков;
b) определить, какие фазы жизненного цикла модулей безопасности следует повторить.
7.8.2.4 Результаты анализа влияния, полученные в 7.8.2.3, должны быть документированы.
7.8.2.5 Все модификации, оказывающие влияние на функциональную безопасность Е/Е/РЕ систем, связанных с безопасностью, должны приводить к возврату на соответствующую стадию жизненного цикла модулей безопасности. Все последующие стадии должны выполняться в соответствии с процедурами, определенными для отдельных стадий в соответствии с требованиями настоящего стандарта. При планировании безопасности (см. раздел 6) должны быть подробно описаны все последующие процессы.
Примечание - Может потребоваться выполнение полного анализа рисков и опасностей, в результате которого может появиться потребность в иных уровнях полноты безопасности, чем те, которые определены для систем, связанных с безопасностью, и внешних средств уменьшения риска.
7.8.2.6 Планирование безопасности для модификации программного обеспечения, связанного с безопасностью, должно включать в себя следующую информацию:
a) идентификацию персонала и определение требований к его квалификации;
b) подробную спецификацию модификации;
c) планирование верификации;
d) область применения операций повторного подтверждения соответствия и тестирования модификации в той степени, в которой этого требует уровень полноты безопасности.
7.8.2.7 Модификация должна быть выполнена в соответствии с разработанным планом.
7.8.2.8 Все модификации должны быть подробно документированы, включая:
a) запрос на модификацию/корректировку;
b) результаты анализа влияния, которое окажут предлагаемые модификации программного обеспечения на функциональную безопасность, и принятые решения с их обоснованием;
c) сведения об изменениях конфигурации программного обеспечения;
d) отклонения от нормальной работы и нормальных условий работы;
e) все документы, которые затрагиваются процессами модификации.
7.8.2.9 Информация (например, хронологическая) о деталях всех выполненных модификаций должна быть документирована. Документация должна включать в себя данные и результаты повторной верификации и повторного подтверждения соответствия.
Примечание - Требования 7.8.2.1 -7.8.2.9 относятся, в первую очередь, к изменениям, выполняемым на этапе работы программного обеспечения. Они могут также применяться во время интеграции программируемой электроники, а также во время общей установки и ввода в эксплуатацию (МЭК 61508-1, пункт 7.13).
7.8.2.10 Оценка необходимых модификаций или корректировок должна зависеть от результатов анализа влияния модификаций и уровня полноты безопасности программного обеспечения.
Примечание - См. также 8.2, таблицы А.9 (приложение А) и В.8 (приложение В).
7.9.1 Цели
Цель требований настоящего подраздела - подтвердить в соответствии с требуемым уровнем полноты безопасности, что результаты, полученные на заданной стадии жизненного цикла модулей безопасности, являются корректными и соответствуют требованиям и стандартам, использовавшимся в качестве исходной информации для соответствующей стадии.
Примечания
1 Настоящий подраздел учитывает базовые аспекты верификации, которые являются общими для нескольких стадий жизненного цикла модулей безопасности. Настоящий подраздел не предъявляет дополнительных требований к элементам проверки верификации 7.4 (проверка программных модулей), 7.4.8 (интеграция программного обеспечения) и 7.5 (интеграция программируемой электроники), которые сами по себе представляют процессы верификации. Данный подраздел не требует также дополнительной верификации для процессов подтверждения соответствия программного обеспечения (см. 7.7), которое в настоящем стандарте определяется как демонстрация соответствия спецификации требований к безопасности (конечная верификация). Проверка того, является ли корректной сама спецификация, выполняется специалистами по предметным областям.
2 В зависимости от архитектуры программного обеспечения ответственность за проведение верификации программного обеспечения может быть разделена между всеми организациями, вовлеченными в разработку и модификацию программного обеспечения.
7.9.2 Требования
7.9.2.1 Верификация программного обеспечения для каждой стадии жизненного цикла модулей безопасности должна планироваться (см. 7.4) одновременно с разработкой; вся информация, относящаяся к этому вопросу, должна документироваться.
7.9.2.2 Планирование верификации программного обеспечения должно касаться критериев, методов и инструментария, используемого при верификации, в ходе его должны быть рассмотрены:
a) оценка требований полноты безопасности;
b) выбор и документирование стратегии, процессов и методов верификации;
c) выбор и использование инструментов верификации (тестовая программа, специальные программные средства для тестирования, имитаторы ввода/вывода и т.п.);
d) оценка результатов верификации;
e) исправления, которые должны быть сделаны.
7.9.2.3 Верификация программного обеспечения должна быть выполнена в соответствии с планом.
Примечание - Выбор методов и средств, предназначенных для верификации, а также степень независимости процессов верификации определяются рядом факторов и могут быть определены в стандартах для прикладных отраслей. К числу таких факторов относятся, например:
- размер проекта;
- степень сложности;
- степень новизны проекта;
- степень новизны технологии.
7.9.2.4 Должны быть документированы свидетельства того, что верифицируемая стадия завершена удовлетворительно во всех отношениях.
7.9.2.5 Документация, составляемая после каждой верификации, должна включать в себя:
a) перечень пунктов, подлежащих верификации;
b) идентификацию информации, по отношению к которой выполняется верификация;
c) перечень несоответствий.
Примечание - Примерами несоответствий являются программные модули, структуры данных и алгоритмы, которые плохо адаптированы к задаче.
7.9.2.6 Вся существенная информация, относящаяся к стадии N жизненного цикла модулей безопасности, которая необходима для правильного выполнения следующей стадии N + 1, должна быть доступна и верифицирована. К выходной информации стадии N относятся:
а) информация об адекватности спецификации описания проекта либо исходного текста программ, разработанных в ходе стадии N:
- функциональности,
- полноте безопасности, характеристикам и другим требованиям планирования безопасности (см. раздел 6),
- требованию понятности для коллектива разработчиков,
- безопасной модификации, допускающей дальнейшее развитие;
b) информация об адекватности планирования подтверждения соответствия и проверок, определенных для стадии N, определению и описанию проекта стадии N;
