ГОСТ Р МЭК 60601-1—2022
- в рамках ПРОЦЕССА;
- между ПРОЦЕССАМИ.
Примеры подобных проблем;
- противоречивость требований;
- неоднозначность требований;
- отсутствие технических условий (требований);
- ошибки кодировки;
- неправильная работа ПЭМС.
Система разрешения проблем (при их возникновении) необходима для гарантии контроля ее воздействия на
ОПАСНОСТИ и соответствующие РИСКИ. Методы, специально создаваемые для разрешения данной проблемы,
могут снижать выгоды, получаемые при использовании систематического подхода к жизненному циклу. Допусти
мым местом для документирования системы разрешения проблем является часть ЖИЗНЕННОГО ЦИКЛА РАЗРА
БОТКИ ПЭМС.
Подпункт 14.6.1 — Идентификация известных и прогнозируемых ОПАСНОСТЕЙ
У ПЭМС имеются дополнительные причины возникновения ОПАСНОСТЕЙ.
Подпункт 14.6.2 — УПРАВЛЕНИЕ РИСКОМ
Поскольку на выбор ПРОЦЕДУР и средств, используемых ИЗГОТОВИТЕЛЕМ для разработки ПЭМС, будет
влиять множество факторов, этот подпункт требует, чтобы одним из этих факторов при их выборе было уменьше ние
РИСКА. Это необходимо для реализации показателей УПРАВЛЕНИЯ РИСКОМ, которые были разработаны с
использованием ПРОЦЕДУР и средств, способных обеспечивать более качественное выполнение предназначен
ных функций, чем при использовании ПРОЦЕДУР и средств, обладающих неизвестным качеством.
Подпункт 14.7 — Перечень требований
Показатели УПРАВЛЕНИЯ РИСКОМ используют для контроля РИСКА идентифицированных ОПАСНОСТЕЙ.
Требования к этим средствам, задокументированные в перечне, должны определять объем работ и способы их
выполнения. Подпункт 4.2 не предъявляет никаких требований к подобному перечню.
Поддающиеся проверке требования
Все требования, относящиеся как к функциям средств УПРАВЛЕНИЯ РИСКОМ, так и (возможно) к правиль
ности их выполнения, должны поддаваться проверке. В общем случае количественная ВЕРИФИКАЦИЯ частоты
нарушений для программного обеспечения нецелесообразна. ВЕРИФИКАЦИЯ качественного подхода должна под
тверждаться с помощью соответствующих ПРОЦЕССОВ.
Идентифицируемые требования безопасности
Требование разграничения показателей УПРАВЛЕНИЯ РИСКОМ и ОСНОВНЫХ ФУНКЦИОНАЛЬНЫХ ХА
РАКТЕРИСТИК необходимо для гарантии его исполнения или при необходимости — изменения ОСНОВНОЙ
ФУНКЦИОНАЛЬНОЙ ХАРАКТЕРИСТИКИ или показателя УПРАВЛЕНИЯ РИСКОМ — для возможности оценки
ОСТАТОЧНОГО РИСКА.
Разделение на компоненты
Примеры структуры ПЭМС приведены в приложении Н. Требования к применению показателей УПРАВЛЕ
НИЯ РИСКОМ должны определяться для ПЭМС и для любого ПЭПС, в которых применяются (или частично при
меняются) один или несколько подобных показателей, что может отражаться в одном или нескольких документах.
Подпункт 14.8 — Структура
Технические требования к структуре ПЭМС в4.2 не устанавливаются. Здесь были введены дополнительные
требования к ПЭМС, поскольку:
- часто выбранная структура ПЭМС входит в показатели УПРАВЛЕНИЯ РИСКОМ, причем эти показатели
для сложных систем, таких как ПЭМС, должны быть четко сформулированы;
- признано, что формулирование технических требований к структуре является необходимой частью ПРО
ЦЕССА разработки качественного программного обеспечения, предназначенного для ПЭМС.
Существует перечень особенностей структуры, которые могут, если это целесообразно, включаться в спе
цификацию требований. Этот перечень был составлен по той причине, что при определенных обстоятельствах
одна или несколько этих особенностей могут быть использованы для контроля РИСКА возникновения ОПАСНО
СТИ. Например, использование КОМПОНЕНТОВ С ВЫСОКОЙ СТЕПЕНЬЮ НАДЕЖНОСТИ будет эффективно
предотвращать возникновение любого РИСКА, связанного с неисправностью этого компонента.
Подпункт 14.8 е)
Разделение функциональных возможностей может оказаться полезным при наличии настоятельной потреб
ности в строгой проверке безопасности ПЭМС.
Программное обеспечение (как встроенное, так и прикладное) четко разделяется на основное, неосновное и
контрольное и используется таким образом, чтобы данные в этих частях программного обеспечения не создавали
помех друг другу и разделяли между собой функции при выполнении программы. В отсутствие такого разделения
между частями программного обеспечения все оно должно считаться основным, чтобы быть уверенным втом, что
при анализе принята во внимание основная часть программного обеспечения.
260