ГОСТ Р 55544—201З
Л
ЕС/TR 80002-1:2009
6.2.2.2Моры по УПРАВ
Л
ЕНИЮ РИСКОМ и проектирование структуры программного обеспе
чения
6.2.2.2.1 Краткий обзор
АРХИТЕКТУРА программного обеспечения должна описыватьособенности программного обеспече
ния. используемые для управления РИСКОМ путем изначально безопасной конструкции, а также програм
мных механизмов реализации защитных мер для снижения РИСКА.
6.2.2.2.2 Изначально безопасная конструкция на основе особенностей АРХИТЕКТУРЫ
ОПАСНОСТИ, связанной сфункцией программного управления, можно избежать, например, исполь
зуя аппаратные средства для реализации этой функции. Точнотакже ОПАСНОСТИ, связанной с функцией
аппаратныхсредств (изнашивание, усталость), можно избежать, используя программное обеспечение.
Иногда ОПАСНОСТЕЙ можно полностью избежать, используя проектное решение высокого уровня.
Примером в отношении аппаратныхсредств, является решение использовать батарейки в качестве источ
ника энергии вместо переменного тока, которое может устранить РИСК смерти от электрического тока.
Подобным образом целый классошибок программирования, которые могут привести к ОПАСНОСТИ,
может быть устранен на основе проектных решений высокого уровня. Например, утечек памяти можно
избежать, используя только статические структуры данных.
Особой проблемой вСИСТЕМАХ, использующих программное обеспечение, является представле
ние о том. что нетпредела той степени, до которой различное программное обеспечение может совместно
использоватьобщую физическую инфраструктуру. Это представление ложно.
Обычным правилом проектирования СИСТЕМЫ является то. что. когда требуется, система должна
включать достаточные ресурсы для выполнения всех необходимых ЗАДАЧ. Это правило должно приме
няться к программному обеспечению и к оборудованию. Если ПРОГРАММНЫЙ Э
Л
ЕМЕНТ играет роль в
обеспечении БЕЗОПАСНОСТИ, то ОЦЕНКА РИСКАдолжна охватывать следующие вопросы:
- может ли связанный с БЕЗОПАСНОСТЬЮ ПРОГРАММНЫЙ Э
Л
ЕМЕНТ получить доступ к своему
процессору, когда необходимо?
- может ли связанному с БЕЗОПАСНОСТЬЮ ПРОГРАММНОМУ Э
Л
ЕМЕНТУ быть обеспеченодоста
точно времени процессора, чтобы завершить его ЗАДАЧУдо того, как небезопасное состояние перерастет в
неблагоприятноесобытие?
- можно ли продемонстрировать, что никакой другой ПРОГРАММНЫЙ Э
Л
ЕМЕНТ не может прервать
или вмешаться в работу СВЯЗАННОГО С БЕЗОПАСНОСТЬЮ ПРОГРАММНОГО Э
Л
ЕМЕНТА?
Если связанное с БЕЗОПАСНОСТЬЮ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ должно использовать про
цессор совместно с не СВЯЗАННЫМ С БЕЗОПАСНОСТЬЮ ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ, то выше
упомянутые вопросы особенно важны, поскольку функции обеспечения БЕЗОПАСНОСТИ будут конкури
ровать с другими за ресурсы (см. п. 6.2.2.2.4 о разделении).
Методы разработки должны быть выбраны так, чтобы сделать все вышеупомянутые проблемы
видимыми проектировщику. Например, недостаточно создать СВЯЗАННЫЙ С БЕЗОПАСНОСТЬЮ
ПРОГРАММНЫЙ Э
Л
ЕМЕНТ, как ПРОЦЕСС, который запустится когда «все хорошо» и операционная
система найдетдля него время. Метод разработки должен намеренно поддерживать надлежащее проекти
рование планирования, приоритетов и сроков.
6.2.2.2.3 Отказоустойчивая АРХИТЕКТУРА
Для обеспечения БЕЗОПАСНОСТИ пациента или пользователя наличие некоторых функций
МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ может носить обязательный характер. Такие функции могут включать меди
цинские процедуры, которые не должны быть прерваны или отсрочены, а также функции, которые осуще
ствляют защитные меры по УПРАВ
Л
ЕНИЮ РИСКОМ.
Отказоустойчивая конструкция — это очень распространенный подход к улучшению надежности
МЕДИЦИНСКОГО ИЗДЕ
Л
ИЯ (ссылкидля специалистов-лрактикое по разработке программного обеспече
ния включают Паллума (7) и Банатрв (8)). Целью отказоустойчивой конструкции является обеспечение того,
что СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ функции продолжают работать при наличии отказов компонентов,
включая АНОМА
Л
ИИ программного обеспечения.
Отказоустойчивая конструкция обычно обладает некоторой ИЗБЫТОЧНОСТЬЮ. Это может быть про
стымдублированием жизненноважного компонента для обеспечения продолжения функционирования,если
один из компонентов откажет, или может состоять издополнительных компонентов, которые обнаруживают
отказ и переводят выполнение операции на альтернативный режим работы, возможно и с ограниченной
функциональностью.
24