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

Примечание - В США и Канаде до тех пор, пока там не будет опубликована в качестве международного стандарта предлагаемая реализация МЭК 61508 для обрабатывающих отраслей (т.е. МЭК 61511), вместо МЭК 61508 в обрабатывающих отраслях допускается использовать национальный стандарт, базирующийся на МЭК 61508 (т.е. ANSI/ISA S 84.01-1996).

1.3 На рисунке 1 показана общая структура МЭК 61508-1 - МЭК 61508-7 и указана роль МЭК 61508-3 в достижении функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью.

В МЭК 61508-6 (приложение А) описано применение МЭК 61508-2 и МЭК 61508-3.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

МЭК 61508-1:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования

МЭК 61508-2:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам электрическим/электронным/программируемым электронным, связанным с безопасностью

МЭК 61508-4:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения

МЭК 61508-5:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 5. Примеры методов определения уровней полноты защиты

МЭК 61508-6:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 6. Руководство по применению МЭК 61508-2:2000 и МЭК 61508-3:1998

МЭК 61508-7:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Анализ методов и средств

ИСО/МЭК Руководство 51:1999 Руководство по включению в стандарты аспектов, связанных с безопасностью

МЭК Руководство 104:1997 Подготовка публикаций по безопасности и использование основополагающих публикаций и групповых публикаций по безопасности

Рисунок 1 - Общая структура настоящего стандарта

3 Термины и определения

В настоящем стандарте использованы термины по МЭК 61508-4.

4 Соответствие настоящему стандарту

Требования, которые следует выполнять для соответствия настоящему стандарту, приведены в МЭК 61508-1 (раздел 4).

5 Документация

Задачи и требования, предъявляемые к документации, приведены в МЭК 61508-1 (раздел 5).

6 Система управления качеством программного обеспечения

6.1 Цели

Цели подробно рассмотрены в МЭК 61508-1 (пункт 6.1).

6.2 Требования

6.2.1 В дополнение к требованиям, описанным в МЭК 61508-1 (пункт 6.2), предъявляются следующие требования.

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

Примечание - Философия настоящего подхода состоит в использовании планирования функциональной безопасности в качестве возможности для приспособления настоящего стандарта для учета различной степени полноты безопасности, необходимой для компонентов Е/Е/РЕ систем, связанных с безопасностью. При совместном использовании компонентов Е/Е/РЕ систем, связанных с безопасностью, имеющих разные уровни полноты безопасности, следует учитывать требования пункта 7.4.2.8.

6.2.3 Система управления конфигурацией программного обеспечения должна:

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

b) гарантировать выполнение всех операций, необходимых для того, чтобы продемонстрировать достижение заданной полноты безопасности программного обеспечения;

c) осуществлять аккуратную поддержку с использованием уникальной идентификации всех элементов конфигурации, которые необходимы для обеспечения целостности Е/Е/РЕ систем, связанных с безопасностью. Элементы конфигурации должны включать в себя, как минимум, следующее:

- анализ безопасности и требования к безопасности,

- спецификацию программного обеспечения и проектные документы,

- исходный текст программ,

- план и результаты тестирования,

- ранее разработанные программные компоненты и пакеты, которые должны быть включены в Е/Е/РЕ систему, связанную с безопасностью,

- все инструментальные средства и системы разработки, которые использовались при создании, тестировании или выполнении иных действий с программным обеспечением Е/Е/РЕ систем, связанных с безопасностью;

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

Примечание - Для осуществления руководства и применения административных и технических средств контроля необходимы принятие управленческих решений и наличие полномочий.

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

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

Примечание - Дополнительную информацию по управлению конфигурацией см. в ИСО/МЭК 12207.

7 Требования к жизненному циклу программного обеспечения, связанного с безопасностью

7.1 Общие положения

7.1.1 Цели

Целью требований, излагаемых в настоящем подразделе, является разделение процесса разработки программного обеспечения на этапы и процессы (см. таблицу 1 и рисунки 2 - 5).

7.1.2 Требования

7.1.2.1 Жизненный цикл систем безопасности при разработке программного обеспечения должен быть выбран и специфицирован при планировании безопасности в соответствии с МЭК 61508-1 (раздел 6).

Примечание - Модель жизненного цикла систем безопасности, удовлетворяющая требованиям МЭК 61508-1 (раздел 7), может быть переработана в соответствии с конкретными потребностями проекта или организации.

7.1.2.2 Процедуры оценки качества и безопасности должны быть интегрированы в процессы жизненного цикла систем безопасности.

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

Примечания

1 Более подробная информация о фазах жизненного цикла приведена в ИСО/МЭК 12207.

2 Выходные данные стадий жизненного цикла систем безопасности рассматриваются в МЭК 61508-1 (раздел 5). При разработке некоторых Е/Е/РЕ систем, связанных с безопасностью, выходные данные некоторых стадий жизненного цикла систем безопасности могут представлять собой отдельные документы, тогда как выходные данные от других стадий могут объединяться в один документ. Существенным является требование, чтобы выходные данные стадии жизненного цикла системы безопасности удовлетворяли ее предназначению. В случае простых разработок некоторые стадии жизненного цикла систем безопасности также могут объединяться (см. 7.4.5).

7.1.2.4 Если жизненный цикл модулей безопасности удовлетворяет требованиям, приведенным на рисунке 3 и в таблице 1, допускается изменять глубину, число и рабочий размер стадий V-модели (см. рисунок 5) в соответствии с полнотой безопасности и сложностью проекта.

Примечание - Полный список стадий жизненного цикла, приведенный в таблице 1, относится к большим системам, разрабатываемым с самого начала. Для небольших систем может оказаться целесообразным, например, объединить стадии проектирования системы программного обеспечения и проектирования архитектуры.

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

7.1.2.6 Для каждой стадии жизненного цикла следует использовать соответствующие методы и мероприятия. Рекомендации приведены в приложениях А и В (руководство по выбору методов и мероприятий). Выбор методов из приложений А и В не гарантирует сам по себе достижения необходимой полноты безопасности.

7.1.2.7 Результаты процессов жизненного цикла систем безопасности программного обеспечения должны быть документированы (см. раздел 5).

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

Рисунок 2 - Жизненный цикл безопасности E/E/PES систем (стадия реализации)

Рисунок 3 - Жизненный цикл безопасности программного обеспечения (стадия реализации)

Рисунок 4 - Соотношение между областями применения МЭК 61508-2 и МЭК 61508-3

Рисунок 5 - Полнота безопасности программного обеспечения и жизненный цикл разработки (V-модель)

Таблица 1 - Обзор жизненного цикла модулей безопасности программного обеспечения