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