ГОСТ Р МЭК 60601-1—2022
Требования к отделению основных правил техники безопасности от неосновных включают ОЦЕНКУ РИСКА
для полной системы, применяемые стратегии УПРАВЛЕНИЯ РИСКОМ, анализ физических ресурсов и анализ ло
гических свойств (например, соединение управления иданных). Вобщем случае разделение должно при разработ ке
и внедрении позволять отделять и изолировать связанные с безопасностью функциональные возможности от не
связанных с ней. Этот ПРОЦЕСС может быть минимизирован или по крайней мере ограничен, а ВЕРИФИКАЦИЯ
может потребоваться для гарантии того, что отделенные или пропущенные в основную часть программного обе
спечения данные не будут влиять на определенные операции, обеспечивающие выполнение основных правил
техники безопасности.
Разделение функциональных возможностей включает следующие этапы:
a) идентификацию основной, неосновной и контрольной частей программного обеспечения. Средства для
подобной идентификации зависят от модульности кодов, языка программирования, структуры кода и других атри
бутов спецификации;
b
) описание интерфейсов между критическими и некритическими частями программного обеспечения, т. е.:
1) идентификацию данных или переменных, глобальных для основной и неосновной частей, модулей
и т. д., идентифицированных на этапе а);
2) идентификацию любых параметров, которыми обмениваются основные и неосновные части програм
много обеспечения, модуля и т. д., идентифицированных на этапе а);
3) описание потока данных, переменных или параметров, идентифицированных на этапах Ь) 1) и Ь) 2);
4) описание метода, используемого для предотвращения повреждения данных, их перезаписи и других
ошибок при обработке вышеупомянутых идентифицированных данных, переменных или параметров, которые мо
гут влиять на основные характеристики безопасности;
c) проверку безошибочности разделения частей, которая может осуществляться с помощью функциональ
ных и нагрузочных испытаний.
Подпункт 14.8 д)—п)
Существует перечень пунктов, которые будут принимать во внимание при выборе технических требований к
структуре ПЭМС, поскольку каждый из них может влиять на ее выбор.
Подпункт 14.9 — Проектирование и реализация ПЭМС
Необходимо указывать выбранные технические решения. Часто целесообразно разбивать ПЭМС на под
системы. На рисунке Н.1 приведены примеры ПЭМС/ПЭПС-структур с различным числом разбиений ПЭМС, при
чинами которых могут быть следующие:
Поддержание управляемости подсистем
Чем проще система, тем легче ее понимание и, следовательно, легче ее проектирование и последующее об
служивание. При этом в окончательном варианте система будет более правильной и более легкой для испытаний.
Стандарты на программирование должны устанавливать пределы сложности системы.
Структура системы
Структура системы может быть сделана логичной с точки зрения разделения систем. Например, при необхо
димости создания разнотипных систем они должны реализовываться как различные подсистемы.
Модульность системы
Модульность может облегчать условия реализации различных вариантов системы, обеспечивать многократ
ное применение уже существующих, проверенных подсистем и расширение функциональных возможностей самой
системы.
Физическое разделение системы на компоненты
Разумное физическое разделение системы на подсистемы облегчает диагностику и ремонт вышедших из
строя аппаратных средств.
Разделение по технологии проектирования
Часто реализация аппаратной и программной частей изделия осуществляется различными инженерами, по
этому разделение системы на отдельные подсистемы позволит каждому разработчику работать независимо.
Полная система будет функционировать правильно, если каждая из ее подсистем будет соответствующим
образом определена. Поэтому необходима разработка спецификации (технических требований) на каждую из под
систем, которая, как правило, должна содержать подробные требования к интерфейсу, а также подробные сведе ния
о реализации подсистемы, например используемые алгоритмы.
Каждая подсистема для подтверждения правильности выполнения проектных требований должна подвер гаться
испытаниям, поэтому необходима разработка и технических требований к испытаниям каждой подсистемы.
Технические требования (спецификации) к разработке и испытаниям могут регистрироваться в любой фор
ме, например в форме отдельных документов или объединенного большого документа. Технические требования к
разработке и испытаниям для каждой из подсистем должны быть легко идентифицируемыми.
Примеры элементов среды проектирования приведены в Н.4 а). Эти элементы будут оказывать влияние на
качество и правильность проектирования. Некоторые элементы будут идентифицироваться как соответствующим
образом проверенные средства и ПРОЦЕДУРЫ (см. 14.6.2). Описательные данные относительно среды проекти
рования облегчают ВЕРИФИКАЦИЮ использованных и соответствующим образом проверенных средств и ПРО
ЦЕДУР.
261