ГОСТ Р 53195.4—2010
- связан ли каждый из этих комломентов/подсиствм с безопасностью;
- каков уровень полноты безопасности для компонента/подсистемы;
- определять все взаимодействия между ПО и АС СБЗС-системы. а также оценивать идетализи
ровать их значения;
- использовать для представления структуры нотацию, однозначно определенную или ограни
ченную до подмножества однозначно определенных характеристик;
- содержать набор проектных характеристик, которые должны использоваться для поддержания
полноты безопасности всех данных. В число таких данных допускается включать входные и выходные
данные процесса, коммуникационныеданные, данные интерфейса оператора, данные сопровождения
и данные, хранящиеся во внутренних базах данных;
- определять тесты интеграции структуры ПО для обеспечения выполнения требований, изло
женных в спецификации требований к безопасности ПО. на заданном уровне полноты безопасности
(см. 5.5).
П р и м е ч а н и е — Мвтоды/средства, рекомендуемые для применения при проектировании структуры ПО.
приведены в таблице А.2 приложения А и таблице Б.7 приложения Б.
5.6.5.4 Любые изменения, которые может потребоваться внести в специфицированные требова
ния к СБЗС-системе после использования мероприятий 5.6.5, должны быть согласованы с разработчи
ком СБЗС-систем и документированы.
П р и м е ч а н и е — Итерационное взаимодействие между структурой АС и ПО является неизбежным
{см. рисунок 4). Взаимодействие разработчика ПО с разработчиком АС при рассмотрении спецификации тестирова
ния интеграции РЕ и ПО является обязательным условием процесса разработки СБЗС ПО (см. 5.6.11).
5.6.5.5 Структура ПО комплексных СБЗС-систем должна иметь многоуровневую (двух- или трех
уровневую) распределенную архитектуру.
5.6.5.6 ПО автоматизированного рабочего места (далее — АРМ) не должно выполнять функции
хранения базы данных системы и непосредственного взаимодействия с УО оборудования СБЗС-под-
систем.
5.6.57 В структуре ПО комплексных СБЗС-систем должны быть предусмотрены отдельные про
граммные модули, реализующие непосредственное взаимодействие с УО оборудования СБЗС-под-
систем.
5.6.5.8Протоколы взаимодействия программными модулями и остальной частью СБЗС ПО дол
жны быть, по возможности, открытыми, документированными идолжны поставляться вместе с ПО для
обеспечения возможностидальнейшего наращивания перечня УО в ходе модификации без изменения
общей структуры СБЗС ПО.
5.6.5.ЭВ структуре СБЗС ПО должны быть предусмотрены возможность переключения на избы
точный (резервный) компонент СБЗС-системы (сервер, технологический компьютер, линию связи,
источник электропитания ит. п.) в случаеотказа основного компонента, а также возможность автомати ческого
переключения на прежний компонент при восстановлении его работоспособности.
5.6.5.10 В структуре ПО комплексной СБЗС-системы должна быть предусмотрена возможность
поддержки работы в многосерверной среде, в том числе с поддержкой «горячего» резервирования сер
веров исинхронизации информационной базы данных между серверами, а также автоматической син
хронизации времени во всех компонентах.
5.6.5.11 В структуре ПО комплексной СБЗС-системы должна быть предусмотрена возможность
автоматической посылки управляющего воздействия и выполнения управляющих воздействий при
возникновении любого события в любой подсистеме СБЗС-системы.
5.6.5.12 В структуре СБЗС ПО должна быть предусмотрена возможность поддержания удален
ного контроля и тестирования АС и ПО СБЗС-систем и их составляющих.
5.6.6 Требования к инструментальным средствам поддержки и языкам программирования
5.6.6.1 Выбор инструментов для разработки ПО определяется разработчиком в зависимости от
характера процессов разработки ПО и его структуры (см. 5.6.5).
5.6.6.2 В зависимости от характера ПО ответственность за выполнение требований 5.6.6 может
быть возложена только на поставщика, только на пользователя (разработчика СБЗС ПО) или на обе
стороны. Разделение ответственности должно быть документировано во время планирования безо
пасности (см. 5.6.3).
П р и м е ч а н и я
1Если пользовательское прикладное ПО выполняется на языке с ограниченной варьируемостью при низ
ких уровнях полноты безопасности, то круг необходимых инструментов и языков программирования может быть
13