---

c) результаты несоответствия между:

- проверками, определенными для стадии N, и проверками, определенными для предыдущей стадии N-1,

- выходными данными стадии N.

7.9.2.7 С учетом 7.1.2.1 должны быть выполнены следующие операции верификации:

a) верификация требований к безопасности программного обеспечения (см. 7.9.2.8);

b) верификация архитектуры программного обеспечения (см. 7.9.2.9);

c) верификация проекта системы программного обеспечения (см. 7.9.2.10);

d) верификация проектов программных модулей (см. 7.9.2.11);

e) верификация исходных текстов программ (см. 7.9.2.12);

f) верификация данных (см. 7.9.2.13);

g) тестирование программных модулей (см. 7.4.7);

h) тестирование интеграции программного обеспечения (см. 7.4.8);

i) тестирование интеграции программируемой электроники (см. 7.5);

j) тестирование требований к безопасности программного обеспечения (подтверждение соответствия программного обеспечения) (см. 7.7).

7.9.2.8 Верификация требований к безопасности программного обеспечения

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

a) соответствуют ли требования к безопасности программного обеспечения (см. 7.2) требованиям к безопасности E/E/PES систем (МЭК 61508-2) в отношении функциональности, безопасности, полноты, характеристик и других требований к планированию безопасности;

b) соответствует ли планирование подтверждения соответствия программ для обеспечения безопасности (см. 7.3) требованиям к безопасности программного обеспечения (см. 7.2);

c) наличие несоответствия между:

- специфицированными требованиями к безопасности программного обеспечения (см. 7.2) и специфицированными требованиями к безопасности Е/Е/РЕ систем (МЭК 61508-2),

- специфицированными требованиями к безопасности программного обеспечения (см. 7.2) и планированием подтверждения соответствия безопасности программного обеспечения (см. 7.3).

7.9.2.9 Верификация архитектуры программного обеспечения

После того, как установлена спроектированная архитектура программного обеспечения, верификация должна проверить:

a) удовлетворяет ли описание проекта архитектуры программного обеспечения (см. 7.4.3) специфицированным требованиям к безопасности программного обеспечения (см. 7.2);

b) адекватны ли специфицированные проверки интеграции архитектуры программного обеспечения (см. 7.4.3) описанию проекта архитектуры программного обеспечения (см. 7.4.3);

c) адекватность атрибутов каждого основного компонента/подсистемы по отношению к:

- реализуемости требуемых характеристик безопасности,

- возможности проверки при последующей верификации,

- пониманию персоналом, выполняющим разработку и верификацию,

- безопасной модификации, позволяющей выполнять дальнейшее развитие программы;

d) наличие несовместимости между:

- описанием проекта архитектуры программного обеспечения (см. 7.4.3) и специфицированными требованиями к безопасности программного обеспечения (см. 7.2),

- описанием проекта архитектуры программного обеспечения (см. 7.4.3) и специфицированными тестами интеграции архитектуры программного обеспечения (см. 7.4.3),

- специфицированными тестами интеграции архитектуры программного обеспечения (см. 7.4.3) и планированием подтверждения соответствия безопасности программного обеспечения (см. 7.3).

7.9.2.10 Верификация проекта системы программного обеспечения

После завершения спецификации системы программного обеспечения верификация должна проверить:

а) удовлетворяет ли специфицированный проект системы программного обеспечения (см. 7.4.5) проекту архитектуры программного обеспечения (см. 7.4.3);

b) удовлетворяют ли специфицированные тесты интеграции системы программного обеспечения (см. 7.4.5) проекту системы программного обеспечения (см. 7.4.5);

c) адекватность атрибутов каждого основного компонента проекта системы программного обеспечения (см. 7.4.5) по отношению к:

- реализуемости требуемых характеристик безопасности,

- возможности проверки при последующей верификации,

- пониманию персоналом, выполняющим разработку и верификацию,

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

Примечание - Проверки интеграции системы программного обеспечения могут быть определены как часть проверок интеграции архитектуры программного обеспечении.

d) наличие несоответствий между:

- специфицированным проектом системы программного обеспечения (см. 7.4.5) и описанием проекта архитектуры программного обеспечения (см. 7.4.3),

- описанием проекта системы программного обеспечения (см. 7.4.5) и специфицированными тестами интеграции системы программного обеспечения (см. 7.4.5),

- тестами интеграции системы программного обеспечения (см. 7.4.5) и специфицированными тестами интеграции архитектуры (см. 7.4.3).

7.9.2.11 Верификация проекта модулей программного обеспечения

После того, как определен проект каждого программного модуля, верификация должна проверить:

a) удовлетворяет ли специфицированный проект программного модуля (см. 7.4.5) проекту системного программного обеспечения (см. 7.4.5);

b) адекватны ли специфицированные проверки каждого программного модуля (см. 7.4.5) проекту программного модуля (см. 7.4.5);

c) адекватность атрибутов каждого программного модуля по отношению к:

- реализуемости требуемых характеристик безопасности (см. 7.2),

- возможности проверки при последующей верификации,

- пониманию персоналом, выполняющим разработку и верификацию,

- безопасной модификации, позволяющей выполнять дальнейшее развитие программы;

d) наличие несоответствий между:

- специфицированным проектом программного модуля (см. 7.4.5) и специфицированным проектом системы программного обеспечения (см. 7.4.5),

- специфицированным проектом каждого программного модуля (см. 7.4.5) и специфицированными проверками программных модулей (см. 7.4.5),

- специфицированными проверками программных модулей (см. 7.4.5) и специфицированными проверками интеграции системы программного обеспечения (см. 7.4.5).

7.9.2.12 Верификация исходного текста

Исходный текст должен быть верифицирован статическими методами для того, чтобы гарантировать соответствие специфицированным проектам программных модулей (см. 7.4.5), необходимым стандартам кодирования (см. 7.4.4) и требованиям планирования безопасности (см. 7.3).

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

7.9.2.13 Верификация данных

a) Структуры данных, специфицированные во время проектирования, должны быть проверены на:

- полноту;

- согласованность;

- защиту от изменения или повреждения;

- соответствие функциональным требованиям системы, управляемой данными.

b) Прикладные данные должны быть проверены на:

- соответствие структурам данных;

- полноту;

- совместимость с базовым программным обеспечением (например, последовательность исполнения, совместимость на этапе исполнения и др.) и

- правильность значений данных.

Примечание - Примером прикладных данных являются программы для станков с числовым программным управлением. Системное программное обеспечение (обычно представляющее собой набор подпрограмм) действует как интерпретатор по отношению к прикладным данным. В других контекстах такие прикладные данные могут рассматриваться как прикладные программы.

c) Все параметры, которые могут быть изменены, должны быть проверены на защиту от:

- неверных и неопределенных начальных значений;

- ошибочных, несовместимых или необоснованных значений;

- несанкционированных изменений;

- повреждения данных.

d) Все промышленные интерфейсы и соответствующее программное обеспечение (т.е. датчики и устройства привода, а также автономные интерфейсы: см. 7.2.2.11) должны быть проверены на:

- выявление предполагаемых отказов интерфейса;

- устойчивость по отношению к предполагаемым отказам интерфейса.

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

- обнаружения ошибок;

- защиты от повреждения;

- подтверждения данных.

8 Оценка функциональной безопасности

8.1 Цели и требования раздела 8 МЭК 61508-1 относятся к оценке программного обеспечения, связанного с безопасностью.

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

8.3 Оценка функциональной безопасности может использовать результаты процессов, приведенных в таблице А.10 (приложение А).

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

- совместимость и взаимное дополнение выбранных методов, языков и инструментов для всего цикла разработки;

- полностью ли понимают разработчики методы, языки и инструменты, которые они используют;

- насколько хорошо адаптированы методы, языки и инструменты к конкретным проблемам, с которыми приходится сталкиваться при разработке.

Приложение А
(обязательное)
Руководство по выбору методов и средств

Некоторые из подразделов настоящего стандарта имеют ассоциированные с ними таблицы, например подраздел 7.2 связан с таблицей А.1. Более подробные таблицы, содержащиеся в приложении В, раскрывают содержание некоторых элементов таблиц приложения А, например таблица В.2 раскрывает содержание динамического анализа и тестирования из таблицы А.5.

Обзор методов и средств, упоминаемых в приложениях А и В, приведен в МЭК 61508-7. Для каждого из них даны рекомендации по уровню полноты безопасности, изменяющемуся от 1 до 4. Эти рекомендации обозначаются следующим образом:

HR: настоятельно рекомендуется использовать этот метод или средство для данного уровня полноты безопасности. Если метод или средство не используются, то на этапе планирования безопасности этому должно быть дано подробное объяснение, которое должно быть согласовано с экспертом.

R: метод или средство рекомендуется использовать для данного уровня полноты безопасности, но степень обязательности рекомендации ниже, чем в случае рекомендации HR.

---: для данного метода или средства не даются рекомендации ни за, ни против.

NR: данный метод или средство определенно не рекомендуется для этого уровня полноты безопасности. Если данный метод или средство используются, то на стадии планирования безопасности этому должно быть дано подробное обоснование, которое следует согласовать с экспертом.

Методы и средства следует выбирать в соответствии с уровнем полноты безопасности. Альтернативные или эквивалентные методы и средства обозначаются буквой, следующей за номером. Следует выполнять только один из альтернативных или эквивалентных методов/средств.

Ранжирование методов и средств связано с концепцией эффективности, используемой в МЭК 61508-2. При прочих равных условиях методы, имеющие ранг HR, будут более эффективны в предотвращении внесения систематических ошибок при разработке программного обеспечения либо (при разработке архитектуры программ) будут более эффективны при выявлении ошибок, оставшихся необнаруженными на этапе выполнения, по сравнению с методами, имеющими ранг R.

При большом числе факторов, влияющих на полноту безопасности программного обеспечения, невозможно дать алгоритм, определяющий такую комбинацию методов и средств, которая была бы корректной для любого заданного приложения. Тем не менее, руководство по использованию этих таблиц, иллюстрированное двумя рабочими примерами, приведено в МЭК 61508-6.

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

Предварительное руководство по интерпретации таблиц для прикладного программирования приведено в МЭК 61508-6.

Примечание - Ссылки указывают на подробные описания методов/средств, приведенные в МЭК 61508-7.

Таблица А.1 - Спецификация требований к безопасности программного обеспечения (см. 7.2)