ГОСТ Р 53195.4—2010
5.6.4.12 В состав проекта по мере возможности должны быть включены средства самоконтроля
потоков управления и потоков данных, адекватные требуемому уровню полноты безопасности. При
обнаружении ошибки должны быть выполнены соответствующие действия (см. таблицы А.2 иА.4 при
ложения А).
5.6.4.13 Если стандартное или ранее разработанное программное обеспечение должно исполь
зоваться как часть проекта (см. таблицы А.2 и А.4 приложения А), онодолжно быть четко идентифици
ровано. Способность программного обеспечения удовлетворять требованиям, изложенным в
спецификации требований к безопасности СБЗС ПО (см. 5.6). должна быть обоснована. Обоснование
этой способности должно быть подкреплено данными по удовлетворительной работе ПО в схожем
приложении или быть предметом техже самых процедур верификации иподтверждения соответствия,
которые подразумеваются для любого вновь разрабатываемого ПО. При этом должны быть оценены
ограничения, связанные с условиями, в которых работало ПО (например, зависимость от
операционной системы и компилятора).
П р и м е ч а н и е — Такое обоснование может быть разработано при планировании безопасности (см. 5.4).
5.6.4.14 Подраздел 5.6.4 должен по мере возможности применяться к данным, включая любой
язык генерации данных.
5.6.5 Требования к структуре ПО
5.6.5.1 Структура ПО должна определять основные компоненты и подсистемы ПО. их взаимо
связь. способ реализации необходимых характеристик, в том числе полноты безопасности.
П р и м е ч а н и я
1 Примерами компонентов ПО являются операционные системы, базы данных, коммуникационные подсис
темы. прикладные программы, инструментапьные средства программирования и диагностики и т. п.
2 С точки зрения безопасности стадия разработки структуры программного обеспечения соответствует
периоду разработки базовой стратегии безопасности для ПО.
5.6.5.2 В зависимости от характера разработки ПО ответственность за выполнение требова
ний 5.6.5 может быть возложена только на поставщика, только на разработчика или на обе стороны.
Распределение ответственности определяется разработчиком и должно быть документировано во
время планирования безопасности (см. 5.4).
П р и м е ч а н и я
1 Для пользовательского прикладного программирования в языках с ограниченной изменчивостью, в част
ности в языках, используемых в ПЛК. структура определяется поставщиком как стандартная характеристика ПЛК.
Однако в рамках настоящего стандарта к поставщику может быть предъявлено требование гарантировать
пользователю соответствие поставляемого продукта требованиям 5.6.4. В этом случае пользователь приспосаб
ливает ПЛК. используя стандартные возможности программирования, например многозвенные логические
схе мы. При этом требования 5.6.5— 5.6.11 сохраняют свою силу. Требование определения и
документирования структуры может рассматриваться как информация, которую пользователь может
использовать при выборе ПЛК (или эквивалентного ему устройства), для приложения.
2 В другом крайнем случае в некоторых встроенных приложениях, использующих язык с полной изменчи
востью. например а устройствах биометрической идентификации системы контроля и управления доступом,
управляемых микропроцессором, структура должна создаваться поставщиком специально для приложения (или
класса приложений). Пользователь обычно не имеет инструментария для программирования. В этих условиях
ответственность за обеспечение соответствия по 5.4 ложится на поставщика.
3 Имеются системы, попадающие в промежуток между типами, упомянутыми в примечаниях 1 и 2. в таких
случаях ответственность за соответствие разделяется между пользователем и поставщиком.
5.6.5.3 Разрабатываемый проект структуры ПО должен быть создан поставщиком и/или разра
ботчиком ПО. Описание структуры должно быть подробным. Описание должно:
- содержать выбор и обоснование интегрированного набора методов/средств. которые будут
необходимы в течение жизненного цикла модулей безопасности для удовлетворения требований к
безопасности ПО на заданном уровне полноты безопасности (см. 5.5). Эти методы/средства включают в
свой состав стратегию проектирования ПО для обеспечения устойчивости к отказам (совместимую с
аппаратными средствами) идля избегания отказов, в том числе (при необходимости) могут включать в
свой состав избыточность и разнообразие;
- основываться на разделении на компоненты/подсистемы. для каждой из которых должна быть
предоставлена следующая информация:
- являются ли они вновь разработанными, уже существующими или находящимися в частной
собственности;
- проводилась ли верификация, и если проводилась, то при каких условиях;
12