ГОСТ Р МЭК 61508-3—2012
деления и документирования архитектуры может рассматриваться как информация, которую пользователь может
использовать при выборе П
Л
К (или эквивалентного ему устройства) для применения.
4 С точки зрения системы безопасности стадия разработки архитектуры программного обеспечения соответ
ствует периоду, когда для программного обеспечения разрабатывается базовая стратегия безопасности.
5 Хотя стандарты серии МЭК 61508 устанавливают числовые значения целевых мер отказов для функций
безопасности, выполняемых Э/Э/ПЭ системами, связанными с безопасностью, систематическая полнота безопас
ности обычно не определяется количественно (см. пункт 3.5.6 МЭК 61508-4). но полнота безопасности программ
ного обеспечения (см. пункт 3.5.5 МЭК 61508-4) определяется как стойкость к систематическим отказам со шкалой
уверенности от 1 до 4 (см. пункт 3.5.9 МЭК 61508-4). Для целей настоящего стандарта принято, что программная
ошибка гложет быть безопасной или опасной в зависимости от специфики использования программного обеспече
ния. Архитектура системы/программного обеспечения должна быть такой, чтобы опасные отказы элемента были
ограничены каким-либо архитектурным ограничением, а методы разработки должны эти ограничения учитывать. В
соответствии с требованиями настоящего стандарта методы разработки и подтверждения соответствия приме няют
со всей строгостью, которая является качественно согласованной с требуемой стойкостью к систематическим
отказам.
6 Для выбора соответствующих методов и средств (см. приложения А и В), выполняющих требования на
стоящего пункта, должны быть рассмотрены следующие свойства (см. руководство по интерпретации свойств в
приложении С и неформальные описания методов и средств в приложении F МЭК 61508-7) архитектуры программ
ного обеспечения:
- полнота спецификации требований к программному обеспечению системы безопасности;
- корректность спецификации требований к программному обеспечению системы безопасности;
- отсутствие собственных ошибок проекта;
- простота и ясность;
- предсказуемость поведения;
- верифицируемость и тестируемость проекта;
- отказоустойчивость;
- защита от отказов по общей причине, вызванной внешним событием.
7.4.3.1 В зависимости от характера разработки программного обеспечения ответственность
за соответствие 7.4.4 может лежать на нескольких сторонах. Распределение ответственности долж
но быть документально оформлено во время планирования системы безопасности (см. раздел 6
МЭК 61508-1).
7.4.3.2 Проект архитектуры программного обеспечения должен быть создан поставщиком про
граммного обеспечения и/или разработчиком, описание архитектуры должно быть подробным. Описа
ние должно:
a) содержать выбор и обоснование (см. 7.1.2.7) интегрированного набора методов и мероприятий,
которые будут необходимы в течениежизненного цикла программного обеспечения системы безопасно
сти. для того чтобы соответствовать требованиям к программному обеспечению системы безопасности
для заданного уровня полноты безопасности. Эти методы и мероприятия включают в себя стратегию
проектирования программного обеспечения для обеспечения устойчивости к отказам (совместимую с
аппаратными средствами) и избежания отказов, в том числе включая в себя (при необходимости) из
быточность и разнообразие;
b
) основываться на разделении на элементыУподсистемы. для каждой из которых должна предо
ставляться следующая информация:
1) проводилась ли верификация и если проводилась, то при каких условиях.
2) связан ли каждый из этих компонентов/подсистем с безопасностью или нет.
3) существует ли стойкость к систематическим отказам для компонеита/подсистемы программ
ного обеспечения;
c) определять все взаимодействия между программным обеспечением и аппаратным средствами,
а также оценивать и детализировать их значение.
П р и м е ч ан и е — Если взаимодействие между программным обеспечением и аппаратным средствами уже
определено архитектурой системы, то достаточно сослаться на архитектуру системы;
d) использовать для представления архитектуры нотацию, которая является однозначно опреде
ленной или ограничена до подмножества однозначно определенных характеристик;
e) содержать набор проектных характеристик, которые должны использоваться для поддержания
полноты безопасности всех данных. В число таких данных допускается включать входные и выходные
производственные, коммуникационные данные, данные интерфейса оператора, сопровождения и хра
нящиеся во внутренних базах данных;
22