ГОСТ IEC 62304—2022
d) формулируются в терминах, которые позволяют установить критерии тестирования и осуще
ствить тестирование;
e) могут быть идентифицированы уникальным образом;
f) являются прослеживаемыми в отношении требований к СИСТЕМЕ или к другому источнику.
[Классы А, В, С]
Примечание — Настоящий стандарт не требует использования формально установленного языка.
5.3 Проектирование АРХИТЕКТУРЫ программного обеспечения
5.3.1 Преобразование требований к программному обеспечению в АРХИТЕКТУРУ
ИЗГОТОВИТЕЛЬ должен преобразовать требования к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ МЕДИ
ЦИНСКОГО ИЗДЕЛИЯ в документированную АРХИТЕКТУРУ, которая описывает структуру программ
ного обеспечения и идентифицирует ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ. [Классы В, С]
5.3.2 Разработка АРХИТЕКТУРЫ для интерфейсов ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ
ИЗГОТОВИТЕЛЬ должен разработать и документировать АРХИТЕКТУРУ для интерфейсов между
ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ и компонентами, внешними по отношению к ПРОГРАММ
НЫМ СОСТАВНЫМ ЧАСТЯМ (как для программной, так и для аппаратной части), а также между ПРО
ГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ. [Классы В, С]
5.3.3 Определение требований к функциональным и эксплуатационным характеристикам
элементов ПОНП
Если ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ идентифицирован как ПОНП, ИЗГОТОВИТЕЛЬ должен
определить требования к функциональным и эксплуатационным характеристикам элементов ПОНП,
которые необходимы для их использования согласно предусмотренному назначению. [Классы В, С]
5.3.4 Определение требований к аппаратным и программным средствам СИСТЕМЫ, требу
емых элементами ПОНП
Если ПРОГРАММНАЯ СОСТАВНАЯ ЧАСТЬ определяется как ПОНП, ИЗГОТОВИТЕЛЬ должен
определить аппаратные и программные средства СИСТЕМЫ, необходимые для поддержания правиль
ной работы элемента ПОНП. [Классы В, С]
Примечание — Примеры включают тип и скорость процессора, тип и размер памяти, тип программного
обеспечения СИСТЕМЫ, коммуникационные и дисплейные требования.
5.3.5 Идентификация обособленности, необходимой для УПРАВЛЕНИЯ РИСКОМ
ИЗГОТОВИТЕЛЬ должен идентифицировать любую обособленность ПРОГРАММНЫХ СОСТАВ
НЫХ ЧАСТЕЙ, которая необходима для УПРАВЛЕНИЯ РИСКОМ, и указать, как обеспечить результа
тивность созданной обособленности. [Класс С]
Примечание — В качестве примера создания обособленности можно привести ПРОГРАММНЫЕ СО
СТАВНЫЕ ЧАСТИ, выполняемые на разных процессорах. Результативность обособленности может быть обеспе
чена за счет отсутствия общих ресурсов у разных процессоров. Другие способы создания обособленности могут
применяться, когда результативность может быть обеспечена посредством разработки АРХИТЕКТУРЫ программ
ного обеспечения (см. В. 4.3).
5.3.6 Верификация АРХИТЕКТУРЫ программного обеспечения
ИЗГОТОВИТЕЛЬ должен верифицировать и документировать, что:
a) АРХИТЕКТУРА программного обеспечения реализует требования к СИСТЕМЕ и к программно
му обеспечению, включая относящиеся к УПРАВЛЕНИЮ РИСКОМ;
b
) АРХИТЕКТУРА программного обеспечения способна поддерживать взаимодействие между
ПРОГРАММНЫМИ СОСТАВНЫМИ ЧАСТЯМИ, а также между ПРОГРАММНЫМИ СОСТАВНЫМИ ЧА
СТЯМИ и аппаратными средствами;
c) АРХИТЕКТУРА МЕДИЦИНСКОГО ИЗДЕЛИЯ поддерживает правильную работу любых элемен
тов ПОНП. [Классы В, С]
Примечание — Для выполнения требования а) может быть использован анализ ПРОСЛЕЖИВАЕМО
СТИ АРХИТЕКТУРЫ к требованиям по программному обеспечению.
14