ГОСТ Р МЭК 61508-3—2007
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) производительность и время отклика;
0 интерфейсы оборудования и оператора.
7.2.2.5 Разработчик программного обеспечения должен установить процедуры для устранения
разногласий при назначении уровня полноты безопасности программного обеспечения.
7.2.2.6 В той степени, в которой этого требуетуровень полноты безопасности, требования к безо
пасности программного обеспечения должны быть выражены и структурированы так, чтобы они:
a) были ясными, точными, недвусмысленными, пригодными для верификации, тестирования,
поддержки и выполнения и соразмерными с уровнем полноты безопасности;
b
) были пригодными для того, чтобы можно было определить их источникв спецификации требо
ваний к безопасности Е/Е/РЕ систем;
c) не содержали информации иописаний, которые являютсядвусмысленными и/или могут бытьне
поняты теми, кто использует документ на той или иной стадии жизненного цикла систем безопасности.
7.2.27 В требованиях к безопасности программного обеспечения должны быть подробно описа
ны все соответствующие режимы работы EUC. если только они не были уже адекватно определены в
требованиях к безопасности Е/Е/РЕ систем, связанных с безопасностью.
П р и м е ч а н и е — В большинстве случаев это требование будет достигаться объединением общего встро
енного и специального прикладного программного обеспечения. Именно от этого объединения требуется обеспече
ние характеристик, удовлетворяющих требованиям к безопасности. Точное разделение между общим и специаль
ным прикладным программным обеспечением зависит от выбранной архитектуры программного обеспечения
(см. 7.4.3 и рисунок 4).
7.2.2.8 Спецификация требований к безопасности программного обеспечения должна опреде
лять и документировать все относящиеся к безопасности и иные необходимые ограничения, связанные
с взаимодействием между аппаратными средствами и программным обеспечением.
7.2.2.9 В той степени, в которой этого требуетописание проекта архитектуры аппаратныхсредств
Е/Е/РЕ систем, спецификация требований к безопасности программного обеспечения должна учиты
вать следующее:
a) самоконтроль программного обеспечения (например. МЭК 61508-7, пункты С.2.5 и С.3.10 при
ложения С);
b
) мониторинг программируемой электронной аппаратуры, датчиков и устройств привода;
c) периодическое тестирование функций безопасности во время выполнения программы;
13