---

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

Примечания

1 См. также таблицы А.1 (приложение А) и В.7 (приложение В).

2 Данная стадия представлена на рисунке 3 (см. 9.1).

7.2.1 Цели

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

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

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

7.2.2 Требования

Примечание - В большинстве случаев эти требования выполняются комбинацией базового встраиваемого программного обеспечения и программных модулей, которые разработаны специально для конкретного приложения. Именно комбинация этих двух видов программного обеспечения позволяет достигать характеристик, описанных в подразделах, приводимых ниже. Точная граница между базовым и прикладным программным обеспечением зависит от выбранной архитектуры программной системы (см. 7.4.3 и рисунок 6).

РЕ - программируемая электроника; NP - непрограммируемые устройства; Н/W - аппаратные средства; S/W - программное обеспечение; MooN - М из N (например 1оо2 представляет собой 1 из 2).

Рисунок 6 - Взаимосвязь между архитектурой аппаратного и программного обеспечения программируемой электроники

7.2.2.1 Если требования к безопасности программного обеспечения уже были определены в требованиях к Е/Е/РЕ системам, связанным с безопасностью (МЭК 61508-2, пункт 7.2), повторять их не требуется.

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

Примечание - Это требование означает, что должно быть тесное взаимодействие между разработчиком E/E/PES и разработчиком программного обеспечения (МЭК 61508-2 и МЭК 61508-3). По мере того, как требования к безопасности и архитектура программного обеспечения (см. 7.4.3) становятся более определенными, может проявляться влияние на архитектуру аппаратных средств E/E/PES, и по этой причине становится важным тесное взаимодействие между разработчиками аппаратных средств и программного обеспечения (см. рисунок 4).

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

Примечание - Уровень детальности спецификации может изменяться в зависимости от сложности приложения.

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

a) функции безопасности;

b) конфигурацию или архитектуру системы;

c) требования к полноте безопасности аппаратных средств (программируемой электроники, датчиков и устройств привода);

d) требования к полноте безопасности программного обеспечения;

e) производительность и время отклика;

f) интерфейсы оборудования и оператора.

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

7.2.2.6 В той степени, в которой этого требует уровень полноты безопасности, требования к безопасности программного обеспечения должны быть выражены и структурированы так, чтобы они:

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

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

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

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

Примечание - В большинстве случаев это требование будет достигаться объединением общего встроенного и специального прикладного программного обеспечения. Именно от этого объединения требуется обеспечение характеристик, удовлетворяющих требованиям к безопасности. Точное разделение между общим и специальным прикладным программным обеспечением зависит от выбранной архитектуры программного обеспечения (см. 7.4.3 и рисунок 4).

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

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

a) самоконтроль программного обеспечения (например, МЭК 61508-7, пункты С.2.5 и С.3.10 приложения С);

b) мониторинг программируемой электронной аппаратуры, датчиков и устройств привода;

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

d) разрешение тестирования функций безопасности во время работы EUC.

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

7.2.2.11 Спецификация требований к безопасности программного обеспечения должна выражать необходимые характеристики безопасности продукта, а не проекта. С учетом 7.2.2.1 - 7.2.2.10, в зависимости от конкретных обстоятельств, должны быть определены следующие положения:

a) требования к функциям безопасности программного обеспечения:

- функции, которые позволяют EUC достигать или поддерживать безопасное состояние,

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

- функции, связанные с обнаружением, оповещением и обработкой ошибок датчиков и устройств привода,

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

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

- функции, связанные с периодическим тестированием функций в автономном режиме,

- функции, обеспечивающие безопасную модификацию PES,

- интерфейсы функций, не связанных с безопасностью,

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

- интерфейсы между программным обеспечением и PES.

Примечание - Интерфейсы должны включать средства онлайнового и автономного программирования;

b) требования к полноте безопасности программного обеспечения:

- уровни полноты безопасности для каждой функции перечисления а).

Примечание - Назначение полноты безопасности компонентам программного обеспечения описано в МЭК 61508-5, приложение А.

7.3 Планирование подтверждения соответствия безопасности программного обеспечения

Примечание - Эта стадия представлена на рисунке 3 (см. 9.2).

7.3.1 Цели

Целью требований настоящего подраздела является разработка плана подтверждения соответствия безопасности программного обеспечения.

7.3.2 Требования

7.3.2.1 В ходе планирования должны быть определены процедурные и технические шаги, которые нужно использовать для того, чтобы продемонстрировать, что программное обеспечение удовлетворяет требованиям безопасности (см. 7.2).

7.3.2.2 План подтверждения соответствия безопасности программного обеспечения должен содержать следующие положения:

a) описание этапов подтверждения соответствия;

b) перечень лиц, осуществляющих подтверждение соответствия;

c) идентификацию соответствующих режимов работы EUC, включая:

- подготовку к использованию, а также установку и настройку,

- работу в режиме запуска и обучения, в автоматическом, ручном, полуавтоматическом и стационарном режимах,

- переустановку, выключение, сопровождение,

- предполагаемые ненормальные режимы;

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

e) техническую стратегию для подтверждения соответствия (например, аналитические методы, статистическое тестирование и т.п.) (см. 7.3.2.3);

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

g) конкретные ссылки на требования к безопасности программного обеспечения (см. 7.2);

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

i) критерии прохождения/непрохождения подтверждения соответствия (см. 7.3.2.5);

j) политику и процедуры, используемые для оценки результатов подтверждения соответствия, в частности, при оценке отказов.

Примечание - Эти требования основаны на общих требованиях МЭК 61508-1, пункт 7.8.

7.3.2.3 Техническая стратегия для подтверждения соответствия программного обеспечения, связанного с безопасностью (см. таблицу А.7, приложение А), должна содержать следующую информацию:

a) выбор ручных или автоматических методов, или и тех и других;

b) выбор статических или динамических методов, или и тех и других;

c) выбор аналитических или статистических методов, или и тех и других.

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

7.3.2.5 Критерии прохождения/непрохождения при завершении подтверждения соответствия программного обеспечения должны включать:

a) необходимые входные сигналы, включая их последовательность и значения;

b) предполагаемые выходные сигналы, включая их последовательность и значения и

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

7.4 Проектирование и разработка программного обеспечения

Примечание - Эта фаза представлена на рисунке 3 (см. 9.3).

7.4.1 Цели

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

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

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

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