ГОСТ Р МЭК 61508-3—2007
7.4.3 Требования к архитектуре программного обеспечения
П р и м е ч а н и я
1 См. также таблицы А.2 (приложение А) и В.7 (приложение В).
2 Архитектура программного обеспечения определяет основные компоненты и подсистемы программного
обеспечения, их взаимосвязь, способ реализации необходимых характеристики, ачастности, полноты безопаснос
ти. Примеры основных компонентов программного обеспечения включают операционные системы, базы данных,
подсистемы ввода и вывода производственных данных, коммуникационные подсистемы, прикладные программы,
инструментальные средства программирования и диагностики и т.п.
3 Внекоторыхотраслях промышленности архитектура программного обеспечения может называться описа
нием функций или спецификацией функций проекта (хотя эти документы могут также включать вопросы,относящи
еся к аппаратным средствам).
4 Для пользовательского прикладного программирования в языках с ограниченной изменчивостью, в част
ности в языках, используемых в ПЛК (МЭК 61508-6. приложение Е). архитектура определяется поставщиком как
стандартная характеристика ПЛК. Однако в рамках настоящего стандарта к поставщику может быть предъявлено
требование, гарантировать пользователю соответствие поставляемого продукта требованиям 7.4. Пользователь
приспосабливаетПЛК. используя стандартные возможности программирования, например многозвенныелогичес
кие схемы. Требования 7.4.3 — 7.4.8 сохраняют свою силу. Требование определения идокументирования архитек
туры может рассматриваться как информация, которую пользователь может исполазовать при выборе ПЛК (или
эквивалентного ему устройства) для приложения.
5 8 другом крайнем случае, в некоторыхвстроенных приложениях,использующих языке полной изменчивос
тью. например а машине, управляемой микропроцессором, архитектура должна создаваться поставщиком специ
ально для приложения (или класса приложений). Пользователь обычно не имеет инструментария для
программирования. В этих условиях ответственность за обеспечение соответствия 7.4 ложится на поставщика.
6 Имеются системы, попадающие в промежуток между типами, упомянутыми в примечаниях 4 и 5. а таких
случаях ответственность за соответствие разделяется между пользователем и поставщиком.
7 С точки зрения безопасности стадия разработки архитектуры программного обеспечения соответствует
периоду, когда разрабатывается базовая стратегия безопасности для программного обеспечения.
7.4.3.1 В зависимости от характера разработки программного обеспечения ответственность за
соответствие 7.4.3 может лежать только на поставщике, только на разработчике или на обеих сторонах
(см. примечания, приведенные выше). Распределение ответственностидолжно бытьдокументировано
во время планирования безопасности (см. раздел 6).
7.4.3.2 Предлагаемый проект архитектуры программного обеспечения должен быть создан
поставщиком программного обеспечения и/или разработчиком, описание архитектуры должно быть
подробным. Описание должно:
a) содержать выбор и обоснование интегрированного набора методов и мероприятий, которые
будут необходимы в течение жизненного цикла модулей безопасности для того, чтобы удовлетворить
требования к безопасности программного обеспечения на заданном уровне полноты безопасности
(см. 7.2). Эти методы и мероприятия включают стратегию проектирования программного обеспечения
для обеспечения устойчивости к отказам (совместимую с аппаратными средствами) и для избежания
отказов, в том числе (при необходимости) избыточность и разнообразие;
b
) основываться на разделении на компоненты/подсистемы, для каждой из которыхдолжна предо
ставляться следующая информация.
- являются ли они вновь разработанными, уже существующими или находящимися в частной
собственности.
- проводилась ли верификация и если проводилась, то при каких условиях,
- связан ли каждый из этих компонентов/подсистем с безопасностью или нет,
- уровень полноты безопасности для компонента/подсистемы;
c) определять все взаимодействия между программными средствами и аппаратным обеспечени
ем. а также оценивать идетализировать их значение;
d) использоватьдля представленияархитектуры нотацию, которая является однозначноопреде
ленной или ограничена до подмножества однозначно определенных характеристик;
e) содержать набор проектныххарактеристик, которыедолжны использоватьсядля поддержания
полноты безопасности всех данных. В число таких данных допускается включать входные и выходные
производственныеданные, коммуникационныеданные, данные интерфейсаоператора, данные сопро
вождения и данные, хранящиеся во внутренних базах данных;
0 определять тесты интеграции архитектуры программного обеспечениядля того, чтобы обеспе
чить выполнение спецификации требований к безопасности программного обеспечения на заданном
уровне полноты безопасности (см. 7.2).
17