ГОСТ Р 53195.4-2010 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению.
ГОСТ Р 53195.4-2010
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ ЗДАНИЙ И СООРУЖЕНИЙ СИСТЕМ
Часть 4
Требования к программному обеспечению
Functional safety of building/erection safety-related systems. Part 4. Software requirements
ОКС 13.110, 13.220.01,
13.310, 13.320, 29.130.20,
35.240
ОКП 43 7000, 43 7100,
43 7200, 43 7280,
70 3000
Дата введения 2012-01-01
Предисловие
1 РАЗРАБОТАН Университетом комплексных систем безопасности и инженерного обеспечения
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 439 "Средства автоматизации и системы управления" при поддержке Технического комитета по стандартизации ТК 465 "Строительство"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. N 820-ст
4 В настоящем стандарте использованы основные нормативные положения следующих международных стандартов:
МЭК 61508-3:2010* "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению" (IEC 61508-3:2010 "Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements", NEQ)
МЭК 61508-4:2010 "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины, определения, сокращения" (IEC 61508-4:2010 "Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations", NEQ)
Руководство ИСО/МЭК 51:1999 "Аспекты безопасности. Руководящие указания по включению их в стандарты" (ISO/IEC Guide 51:1999 "Safety aspects - Guidelines for their inclusion in standards", NEQ)
5 ВВЕДЕН ВПЕРВЫЕ
6 ПЕРЕИЗДАНИЕ. Октябрь 2018 г.
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Современные здания и сооружения - объекты капитального строительства - представляют собой сложные системы, включающие в свой состав систему конструкций и ряд систем в разных сочетаниях, в том числе инженерные системы жизнеобеспечения, реализации технологических процессов, энерго-, ресурсосбережения, безопасности и другие системы. Эти системы взаимодействуют друг с другом, с внешней и внутренней средами.
Объекты капитального строительства жестко привязаны к местности. Рабочие характеристики зданий, сооружений и входящих в них систем могут быть реализованы, проверены и использованы только в том месте, в котором объекты построены и системы установлены.
Безопасность зданий и сооружений обеспечивается применением совокупности мер, мероприятий и средств снижения риска причинения вреда до уровня приемлемого риска и поддержания его в течение периода эксплуатации или использования этих объектов. К средствам снижения риска относятся системы, связанные с безопасностью зданий и сооружений. Эти системы, состоящие из электрических, и/или электронных компонентов, и/или программируемых электронных компонентов, в течение многих лет используются для выполнения функций безопасности. Для решения задач безопасности зданий и сооружений во все больших объемах используются программируемые электронные (в том числе компьютерные) системы.
Настоящий стандарт устанавливает основные требования к функциональной безопасности программного обеспечения программируемых электронных систем, связанных с безопасностью зданий и сооружений, и к программному обеспечению, используемому для разработки таких систем в рамках области применения ГОСТ Р 53195.1, ГОСТ Р 53195.2 и ГОСТ Р 53195.3.
Стандарт устанавливает требования к действиям и процедурам, которые должны быть выполнены на стадиях жизненного цикла программного обеспечения этих систем для достижения и поддержания их функциональной безопасности.
Настоящий стандарт входит в комплекс стандартов с наименованием "Безопасность функциональная связанных с безопасностью зданий и сооружений систем" и является четвертым стандартом этого комплекса "Часть 4. Требования к программному обеспечению". Другие стандарты, входящие в этот комплекс:
Часть 1. Основные положения;
Часть 2. Общие требования;
Часть 3. Требования к системам;
Часть 5. Меры по снижению риска, методы оценки;
Часть 6. Внешние средства уменьшения риска, системы мониторинга;
Часть 7. Порядок применения требований, примеры расчетов.
Структура комплекса стандартов приведена ниже.
|
 |
1 Область применения
Настоящий стандарт распространяется на:
- программное обеспечение (далее - ПО) программируемых электронных связанных с безопасностью зданий и сооружений систем (далее - Е/Е/РЕ СБЗС-систем), в дальнейшем именуемое СБЗС ПО, а также на системы, подсистемы и компоненты внутри Е/Е/РЕ СБЗС-систем, которые содержат хотя бы один программируемый электронный компонент;
- любое программное обеспечение, являющееся частью СБЗС-системы либо используемое для разработки системы, связанной с безопасностью, в рамках области применения ГОСТ Р 53195.1, ГОСТ Р 53195.2 и ГОСТ Р 53195.3. Такое программное обеспечение называется программным обеспечением систем, связанных с безопасностью зданий и сооружений (далее - СБЗС ПО). СБЗС ПО включает в себя операционные системы, системное программное обеспечение, программы, используемые в коммуникационных сетях, интерфейсы пользователей и обслуживающего персонала, инструментальные средства поддержки, встроенные программно-аппаратные средства, а также прикладные программы. Прикладные программы включают в себя программы высокого и низкого уровней, а также специальные программы на языках с ограниченной варьируемостью (см. 3.12) [1].
Настоящий стандарт устанавливает:
- требования к стадиям жизненного цикла СБЗС ПО и действиям, которые должны предприниматься на этих стадиях во избежание ошибок и отказов СБЗС ПО и для принятия необходимых мер при их возникновении;
- минимальный состав информации, относящейся к подтверждению безопасности СБЗС ПО, необходимой для установки, ввода в действие, интеграции и подтверждения соответствия Е/Е/РЕ СБЗС-систем требованиям безопасности;
- требования к подготовке информации и процедурам, относящимся к СБЗС ПО, необходимым пользователю для работы и поддержания Е/Е/РЕ СБЗС-систем в период эксплуатации;
- требования, предъявляемые к действиям при выполнении модификации СБЗС ПО;
- совместно с ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.5 требования к инструментальным средствам поддержки.
Примечание - Области применения ГОСТ Р 53195.3 и ГОСТ Р 53195.4 взаимосвязаны между собой (см. рисунок 1).
Настоящий стандарт не распространяется на ПО одиночных СБЗС-систем, способных осуществить необходимое снижение риска, и требуемая полнота безопасности которых ниже самого низкого уровня полноты безопасности (SIL1), определенного в таблицах 1 и 2 ГОСТ Р 53195.2-2008.
Настоящий стандарт должен применяться совместно с ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.5.
|
 |
Рисунок 1 - Взаимосвязь областей применения АС и ПО
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р 53195.1 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 1. Основные положения
ГОСТ Р 53195.2-2008 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 2. Общие требования
ГОСТ Р 53195.3 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 3. Требования к системам
ГОСТ Р 53195.5-2010 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 5. Меры по снижению риска, методы оценки
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.5, а также приведенные ниже термины с соответствующими определениями.
3.1 анимация (animation): Имитация работы программного обеспечения (или отдельной его части), предназначенная для отображения существенных аспектов поведения программируемой электронной системы, связанной с безопасностью зданий и сооружений.
Примечания
1 Анимация применима, например, к спецификации требований для представления проекта системы на достаточно высоком уровне в соответствующем формате.
2 Анимация позволяет оценить специфическое поведение системы при задании параметров и данных, близких к реальным.
3.2 динамическое тестирование (dynamic testing): Работа программного обеспечения и/или работа аппаратного средства, выполняемая под контролем и планомерно для демонстрации наличия требуемого поведения и отсутствия нежелательного поведения.
Примечание - Динамическое тестирование представляет собой противоположность статическому анализу, при котором не требуется выполнение программ.
3.3 жизненный цикл программного обеспечения (software lifecycle): Период времени, включающий в себя стадии: разработки требований к программному обеспечению, разработки программного обеспечения, кодирования, тестирования, интеграции, установки, а также стадию модификации.
3.4 избыточность (redundancy): Наличие средств в дополнение к средствам, которые могут быть достаточны функциональному блоку, для выполнения требуемой операции или данным для представления информации.
ПРИМЕР - Примерами избыточности являются дублирование функциональных компонентов и добавление битов четности.
3.5 инспекция программы по Файгану (Fagan inspection): Один из методов обнаружения ошибок на ранних этапах разработки программного обеспечения рабочей группой (при подготовке требований, проектировании, начальных этапах кодирования, планировании тестов), основанный на тщательном анализе первичных документов и проверке соответствия им вторичных документов.
3.6 инструментальные средства поддержки программного обеспечения, инструментальные средства поддержки ПО: Средства разработки, проектирования, кодирования, тестирования, отладки, управления конфигурацией программного обеспечения.
3.7 полнота безопасности программного обеспечения (software safety integrity): Количественная характеристика, которая означает вероятность того, что программное обеспечение программируемой электронной системы будет выполнять заданные функции безопасности при всех оговоренных условиях в течение установленного периода времени.
3.8 программное обеспечение, ПО (software): Продукт интеллектуальной деятельности, включающий в свой состав программы, процедуры, данные, правила и ассоциированную информацию, имеющую отношение к работе системы обработки данных.
Примечание - Программное обеспечение является независимым от носителя записи, на котором оно записано.
3.9 тестовая программа (test harness): Программный продукт, который позволяет имитировать среду, в которой будет действовать разрабатываемое программное обеспечение или аппаратное средство, путем передачи тестовых данных в программу и регистрации ответа.
3.10 уровень полноты безопасности программного обеспечения (software safety integrity level): Дискретный уровень (принимающий одно из четырех возможных значений от 1 до 4), определяющий полноту безопасности программного обеспечения в связанной с безопасностью системе.
3.11 функциональный блок (functional unit): Объект аппаратного средства и/или программного обеспечения, выполняющий определенную задачу.
3.12 язык с ограниченной варьируемостью (limited variability language): Текстовый или графический язык программирования, предназначенный для коммерческих и промышленных программируемых электронных логических контроллеров, диапазон возможностей которого ограничен применением этих устройств.
ПРИМЕР - К языкам с ограниченной изменчивостью, которые используются для представления прикладных программ для систем на основе программируемых логических контроллеров, относятся:
- многоступенчатые схемы: графический язык, состоящий из набора символов для входов (представляющих поведение, характерное для таких устройств, как контакты, которые в нормальном состоянии замкнуты или разомкнуты), соединенных с помощью линий (указывающих направление тока), с символами, обозначающими выходы (представляющими поведение, свойственное реле);
- булева алгебра: низкоуровневый язык, основанный на булевых операторах, таких как И, ИЛИ и НЕ, с возможностью добавления некоторых мнемонических инструкций;
- функциональные блок-диаграммы: в дополнение к булевым операторам допускают использование более сложных функций, таких как операции с файлами, чтение и запись блоков данных, команд для сдвиговых регистров и устройств, задающих последовательность;
- последовательные функциональные схемы: графическое представление многостадийной программы, состоящее из взаимосвязанных шагов, действий и ориентированных связей с промежуточными состояниями.
4 Обозначения и сокращения
В настоящем стандарте приняты следующие обозначения и сокращения:
АРМ - автоматизированное рабочее место;
АС - аппаратное(ые) средство(а);
ПЗУ - постоянное запоминающее устройство;
ПЛК - программируемый логический контроллер;
ПО - программное обеспечение;
СБЗС ПО - программное обеспечение системы, связанной с безопасностью зданий и сооружений;
СБЗС-система - система, связанная с безопасностью зданий и сооружений;
УО - управляемое оборудование;
E/E/PE - электрическая, и/или электронная, и/или программируемая электронная (в отношении системы);
PE - программируемая электроника (программируемое электронное средство, программируемая электронная система);
SIL - обозначение уровня полноты безопасности.
5 Требования
5.1 Соответствие требованиям стандарта
Признание соответствия СБЗС ПО требованиям настоящего стандарта - по ГОСТ Р 53195.2-2008 (см. 5.1).
5.2 Требования к документации
Требования к документации E/E/PE СБЗС-систем - по ГОСТ Р 53195.2-2008 (см. 5.2).
5.3 Требования к управлению функциональной безопасностью
Требования к управлению функциональной безопасностью E/E/PE СБЗС-систем - по ГОСТ Р 53195.2-2008 (см. раздел 6).
5.4 Общие требования к СБЗС ПО
5.4.1 Основные цели и требования для полного жизненного цикла СБЗС ПО установлены в ГОСТ Р 53195.2. Дополнительно к ним к СБЗС ПО предъявляются следующие требования.
5.4.2 Жизненный цикл систем безопасности при разработке ПО должен быть выбран и специфицирован при планировании безопасности в соответствии с ГОСТ Р 53195.2-2008 (раздел 6). На стадии планирования функциональной безопасности СБЗС ПО (см. блок 1.2 на рисунке 3) должны быть определены стратегия поставки, разработки, интеграции, верификации, приемки и модификации ПО в той мере, в какой этого требует уровень полноты безопасности Е/Е/РЕ СБЗС-системы.
5.4.3 При совместном использовании компонентов Е/Е/РЕ СБЗС-систем, имеющих разные уровни полноты безопасности, следует учитывать требования, установленные в 5.6.4.9.
5.4.4 Система управления конфигурацией СБЗС ПО должна:
- использовать административные и технические средства контроля на протяжении всего жизненного цикла ПО для управления изменениями в программах и гарантирования выполнения указанных в спецификациях требований к безопасности СБЗС ПО;
- гарантировать выполнение всех операций, необходимых для достижения заданной полноты безопасности СБЗС ПО;
- обеспечивать точную поддержку Е/Е/РЕ СБЗС-систем с использованием уникальной идентификации всех элементов конфигурации, необходимых для обеспечения полноты безопасности. Элементы конфигурации должны включать в себя, как минимум, следующее:
- анализ безопасности и требования к безопасности;
- спецификацию ПО и проектные документы;
- исходный текст программ;
- план и результаты тестирования;
- ранее разработанные программные компоненты и пакеты, которые должны быть включены в Е/Е/РЕ СБЗС-систему;
- все инструментальные средства и системы разработки, используемые при создании, тестировании или выполнении иных действий с СБЗС ПО;
- использовать процедуры контроля над внесением изменений для предотвращения несанкционированных модификаций.
Примечание - Для осуществления руководства и применения административных и технических средств контроля необходимо принятие управленческих решений и наличие полномочий;
- обеспечивать документирование запросов на выполнение модификаций;
- обеспечивать анализ влияния предлагаемых модификаций и предусматривать утверждение либо отклонение модификации;
- обеспечивать подробное документирование модификации и выдачу полномочий на выполнение всех утвержденных модификаций;
- обеспечивать установление основных параметров конфигурации системы для стадий разработки СБЗС ПО и документирование результатов тестирования интеграции системы, которое подтверждает достижение целей стадии (см. 5.8);
- гарантировать объединение и встраивание всех подсистем ПО (включая переработку более ранних версий);
- предусматривать документирование перечисленной выше информации для обеспечения возможности последующего аудита: состояние конфигурации, текущее состояние системы, обоснование и утверждение всех модификаций, подробное описание всех модификаций;
- обеспечивать строгое документирование каждой версии СБЗС ПО, хранение всех версий ПО и всей относящейся к ним документации для обеспечения возможности сопровождения и выполнения модификаций на протяжении всего периода использования разработанного программного продукта.
5.5 Требования к жизненному циклу СБЗС ПО
5.5.1 Процесс разработки СБЗС ПО должен быть разделен на отдельные стадии, этапы и подпроцессы (см. рисунки 2-5).
5.5.2 При разработке СБЗС ПО жизненный цикл должен быть выбран и специфицирован при планировании безопасности СБЗС-систем в соответствии с требованиями ГОСТ Р 53195.2-2008 (раздел 6).
Примечание - Модель жизненного цикла Е/Е/РЕ СБЗС-систем, удовлетворяющая требованиям ГОСТ Р 53195.2-2008 (раздел 7), может быть переработана в соответствии с конкретными потребностями проекта или организации.
5.5.3 Процедуры оценки качества и безопасности СБЗС ПО должны быть интегрированы в процессы жизненного цикла Е/Е/РЕ СБЗС-систем.
Рисунок 2 - Детализация стадии реализации жизненного цикла Е/Е/РЕ СБЗС-системы
5.5.4 Каждая стадия жизненного цикла СБЗС ПО должна быть разделена на элементарные процессы. Для каждой стадии должны быть определены область применения, входные данные и выходные данные.
Примечание - При совместном использовании компонентов Е/Е/РЕ СБЗС-систем, имеющих разные уровни полноты безопасности, следует учитывать требования 5.6.4.9.
5.5.5 Выходные данные стадии жизненного цикла СБЗС-системы, включая СБЗС ПО, должны соответствовать назначению системы и ПО.
Примечание - В случае относительно простых систем допускается объединение некоторых стадий жизненного цикла.
5.5.6 Если жизненный цикл СБЗС ПО удовлетворяет требованиям, приведенным на рисунке 4 и в таблице А.1 приложения А, допускается изменять глубину, число и размер этапов и процессов в зависимости от сложности проекта и требуемой полноты безопасности.
5.5.7 Для каждой стадии жизненного цикла следует использовать соответствующие методы/средства, приведенные в приложениях А и Б.
|
 |
Рисунок 3 - Детализация стадии реализации жизненного цикла СБЗС ПО
Примечание - Применение методов/средств, выбранных из приложений А и Б, само по себе не гарантирует достижения необходимой полноты безопасности.
5.5.8 Результаты процессов жизненного цикла СБЗС ПО должны быть документированы (см. 5.2).
5.5.9 Если на какой-либо стадии жизненного цикла СБЗС ПО возникает необходимость внесения изменений, относящихся к более ранней стадии жизненного цикла, то следует повторно выполнить эту стадию и все последующие стадии.
|
 |
Рисунок 4 - V-модель проектирования и разработки СБЗС ПО
|
 |
РЕ - программируемая электроника; NP - непрограммируемое устройство; АС - аппаратное средство; ПО - программное обеспечение
|
|
|
Структура программируемой электроники | ||
Структура аппаратных средств РЕ | Структура программного обеспечения РЕ (структура ПО, включая "зашитое" в ПЗУ ПО и прикладные программы) | |
Базовые и прикладные АС, например:
- встроенные устройства диагностического тестирования;
- избыточные процессоры;
- сдвоенные платы ввода/вывода | ПО, "зашитое" в ПЗУ, например:
- коммуникационные драйверы;
- программы обработки отказов;
- исполнительные программы | Прикладные программы, например:
- функции ввода/вывода;
- производные функции (например, контроль сенсора, если он не обеспечен как сервис "зашитого" в ПЗУ ПО) |
Рисунок 5 - Взаимосвязь между структурами АС и ПО программируемой электроники
5.6 Требования к обеспечению безопасности ПО
5.6.1 Спецификация требований к безопасности СБЗС ПО (см. блок 1.1 на рисунке 3) разрабатывается в целях:
- установления требований к функциям безопасности ПО как требований к функциям безопасности и требований к полноте безопасности;
- установления требований к функциям безопасности каждой СБЗС-системы, которые необходимы для реализации этих функций безопасности;
- установления требований к полноте безопасности каждой СБЗС-системы, необходимых для достижения уровня полноты безопасности, назначенного для каждой функции безопасности, реализуемой этой СБЗС-системой.
5.6.2 Требования
5.6.2.1 Выполнение требований достигается комбинацией базового встраиваемого ПО и прикладных программных модулей, разработанных специально для конкретного приложения. Точная граница между базовым и прикладным ПО зависит от выбранной структуры программной системы (см. рисунок 5).
5.6.2.2 Если требования к безопасности ПО были уже установлены в требованиях к безопасности СБЗС-систем (см. ГОСТ Р 53195.3), повторно устанавливать их не следует.
5.6.2.3 Спецификация требований к безопасности ПО должна быть разработана на основе требований к безопасности СБЗС-систем (см. ГОСТ Р 53195.3) и требований к планированию безопасности (см. 5.4.2 настоящего стандарта).
Примечание - Спецификация требований к безопасности СБЗС-систем должна быть доступна разработчикам ПО. Должно быть обеспечено взаимодействие между разработчиками АС и ПО СБЗС-систем.
5.6.2.4 Степень подробности спецификации требований к безопасности ПО должна быть достаточной для обеспечения стадии проектирования и реализации необходимой информации для достижения требуемой полноты безопасности и проведения оценки функциональной безопасности. Уровень детализации зависит от сложности проекта и определяется проектировщиком ПО.
5.6.2.5 Разработчиком ПО должен быть проведен анализ информации, содержащейся в 5.6.2, для гарантирования того, что требования определены адекватным образом. При этом должны быть учтены:
- функции безопасности;
- конфигурация или структура системы;
- требования к полноте безопасности АС (РЕ, датчиков и устройств привода);
- требования к полноте безопасности ПО;
- производительность и время отклика системы;
- интерфейсы оборудования и оператора.
5.6.2.6 Разработчиком ПО должны быть установлены процедуры для устранения разногласий при назначении уровня полноты безопасности ПО.
5.6.2.7 В степени, необходимой для конкретного уровня полноты безопасности, требования к безопасности ПО должны быть выражены и структурированы так, чтобы они:
- были ясными, точными, недвусмысленными, пригодными для верификации, тестирования, поддержки и выполнения, а также соразмерными с уровнем полноты безопасности;
- были пригодными для определения их источника в спецификации требований к безопасности СБЗС-систем;
- не содержали информации и описаний, которые являются двусмысленными и/или могут быть не поняты другими пользователями документа на различных стадиях жизненного цикла СБЗС-систем.
5.6.2.8 В требованиях к безопасности ПО должны быть подробно описаны все соответствующие режимы работы УО, если они не были уже адекватно определены в требованиях к безопасности СБЗС-систем.
5.6.2.9 В спецификации требований к безопасности ПО должны быть установлены и документированы все относящиеся к безопасности и иные необходимые ограничения, связанные с взаимодействием между АС и ПО.
5.6.2.10 В спецификации требований к безопасности ПО в степени, требуемой в описании проекта структуры АС СБЗС-системы, должны быть учтены:
- самоконтроль программного обеспечения;
- мониторинг РЕ, аппаратуры, датчиков и устройств привода;
- периодическое тестирование функций безопасности во время выполнения программы;
- разрешение тестирования функций безопасности во время работы УО.
5.6.2.11 Если СБЗС-система должна выполнять функции, не относящиеся к безопасности, эти функции должны быть четко указаны в спецификации требований к безопасности ПО.
5.6.2.12 Спецификация требований к безопасности ПО должна содержать необходимые характеристики безопасности продукции, а не проекта. С учетом 5.6.2.2-5.6.2.11 в зависимости от конкретных обстоятельств должны быть установлены следующие положения:
а) требования к функциям безопасности ПО:
- функции, обеспечивающие достижение и поддержание безопасного состояния УО;
- функции, связанные с обнаружением, оповещением и обработкой ошибок АС РЕ;
- функции, связанные с обнаружением, оповещением и обработкой ошибок датчиков и устройств привода;
- функции, связанные с обнаружением, оповещением и обработкой ошибок в самом ПО (самоконтроль ПО);
- функции, связанные с периодическим тестированием функций в режиме реального времени;
- функции, связанные с периодическим тестированием функций в автономном режиме;
- функции, обеспечивающие безопасную модификацию СБЗС-систем;
- интерфейсы функций, не связанных с безопасностью;
- емкость системы и диапазон временных характеристик;
- интерфейсы между ПО и РЕ СБЗС-системами.
Примечание - Интерфейсы должны содержать средства автономного программирования и программирования с внешнего устройства (онлайн);
б) требования к полноте безопасности ПО:
- уровни полноты безопасности для каждой функции, приведенной в перечислении а).
5.6.3 Планирование подтверждения соответствия (см. блок 1.2 на рисунке 3)
5.6.3.1 В ходе планирования подтверждения соответствия должны быть установлены процедурные и технические шаги, используемые для демонстрации того, что СБЗС ПО удовлетворяет требованиям безопасности (см. 5.6.2).
Примечания
1 В зависимости от состава и сложности полной СБЗС-системы возможны варианты осуществления подтверждения соответствия ПО: подтверждение соответствия ПО отдельных РЕ СБЗС-систем (подсистем) до объединения их в комплексную систему безопасности; оценка соответствия ПО отдельных РЕ СБЗС-систем (подсистем) в составе комплексной системы безопасности; оценка соответствия ПО комплексной системы безопасности.
2 Выбор варианта осуществления подтверждения соответствия ПО РЕ СБЗС-систем (подсистем) или их комбинации определяется разработчиком ПО.
5.6.3.2 План подтверждения соответствия безопасности ПО должен содержать следующую информацию:
а) описание этапов подтверждения соответствия;
б) перечень лиц, осуществляющих подтверждение соответствия;
в) идентификацию соответствующих режимов работы УО, включая:
- подготовку к использованию, а также установку и настройку;
- работу в режиме запуска и обучения, в автоматическом, ручном, полуавтоматическом и стационарном режимах;
- переустановку, выключение, сопровождение;
- предполагаемые ненормальные режимы;
г) идентификацию СБЗС ПО, для которого должна быть проведена процедура подтверждения соответствия для каждого режима работы УО до момента его ввода в эксплуатацию;
д) техническую стратегию, применяемую для подтверждения соответствия (например, имитация/моделирование, вероятностное тестирование и т.п.) (см. таблицу А.7 приложения А);
е) методы/средства и процедуры в соответствии с перечислением д), которые должны быть использованы для подтверждения каждой функции требованиям к функциям безопасности ПО и требованиям к полноте безопасности ПО (см. 5.6.4);
ж) конкретные ссылки на требования к безопасности ПО (см. 5.6.4);
и) условия, в которых должны происходить процедуры подтверждения соответствия (например, при тестировании может потребоваться использование калиброванных инструментов и оборудования);
к) критерии соответствия/несоответствия при процедуре подтверждения соответствия (см. 5.6.3.4);
л) методы и процедуры, используемые для оценки результатов подтверждения соответствия, в частности при оценке отказов.
5.6.3.3 В рамках процедуры подтверждения соответствия СБЗС ПО, если этого требует уровень полноты безопасности (см. ГОСТ Р 53195.2-2008, 7.15 и ГОСТ Р 53195.3-2015, 5.16.2), область применения и содержание планирования подтверждения соответствия безопасности ПО должны быть изучены экспертом или третьей стороной, представляющей эксперта. Эта процедура должна также включать в себя заявление о присутствии эксперта при испытаниях.
5.6.3.4 Критерии прохождения/непрохождения при завершении подтверждения соответствия ПО должны включать в себя:
- необходимые входные сигналы, включая их последовательность и значения;
- предполагаемые выходные сигналы, включая их последовательность и значения;
- другие критерии приемки, например использование памяти, хронометраж, допустимые интервалы для значений.
5.6.4 Проектирование и разработка ПО (см. блок 1.3 на рисунке 3)
5.6.4.1 На стадии проектирования и разработки СБЗС ПО должны быть:
- создана структура ПО, удовлетворяющая требованиям к безопасности ПО, относящаяся к необходимому уровню полноты безопасности;
- проведен анализ и оценка требований, предъявляемых к ПО, обусловленных АС СБЗС-системы, с учетом степени взаимодействия между АС и ПО СБЗС-системы для обеспечения безопасной работы УО;
- проведен выбор инструментальных средств, включая языки программирования и компиляторы, соответствующие заданному уровню полноты безопасности на протяжении всего жизненного цикла СБЗС-системы и способствующие выполнению процессов верификации, оценке, подтверждению соответствия и модификации ПО;
- спроектировано и реализовано ПО, удовлетворяющее установленным требованиям к безопасности ПО в соответствии с необходимым уровнем полноты безопасности, пригодное для анализа, верификации и способное к безопасной модификации;
- проведена проверка выполнения требований к безопасности ПО в отношении необходимых функций безопасности и полноты безопасности ПО.
Примечание - Методы/средства, рекомендуемые для проектирования и разработки ПО, приведены в таблице А.1 приложения А.
5.6.4.2 В зависимости от характера процесса разработки ПО ответственность за выполнение требований 5.6.4 может быть возложена на поставщика ПО, на пользователя или на обе стороны. Распределение ответственности должно быть определено во время планирования безопасности (см. 5.6.3).
5.6.4.3 В соответствии с требуемым уровнем полноты безопасности выбранный метод проектирования должен обладать характеристиками, которые облегчают:
- абстракцию, разделение на модули и другие характеристики, контролирующие уровень сложности;
- выражение:
- выполняемых функций;
- обмена данными между компонентами;
- информации, относящейся к последовательности и времени выполнения;
- ограничений на время выполнения;
- параллельного выполнения;
- структур данных и их свойств;
- проектных предположений и их зависимостей;
- понимание документации разработчиками и другими лицами, которые должны иметь дело с проектом;
- верификацию и оценку соответствия.
5.6.4.4 На стадии проектирования должны быть предусмотрены тестируемость и способность к безопасной модификации ПО для облегчения реализации этих возможностей в окончательной версии СБЗС-системы.
5.6.4.5 Выбранный метод проектирования должен обладать характеристиками, которые облегчают модификацию программного обеспечения. К числу таких характеристик относятся модульность, скрытие информации и инкапсуляция.
5.6.4.6 Представление проекта должно основываться на однозначно определенной или ограниченной до однозначно определенных свойств нотации.
5.6.4.7 В проекте должна быть минимизирована, насколько это возможно, та часть ПО, которая относится к безопасности.
5.6.4.8 Если ПО должно реализовать функции как относящиеся, так и не относящиеся к безопасности, оно в целом должно рассматриваться как относящееся к безопасности, если только в проекте не продемонстрирована достаточная независимость между этими функциями. Обоснование независимости должно быть документировано.
5.6.4.9 Если программное обеспечение должно реализовать функции безопасности, имеющие различный уровень полноты безопасности, то следует считать, что все ПО имеет наивысший уровень из этих уровней безопасности, если только в проекте не будет продемонстрирована достаточная независимость функций, имеющих различный уровень полноты безопасности. Обоснование независимости должно быть документировано.
5.6.4.10 Уровень полноты безопасности ПО должен быть не ниже, чем уровень полноты функции безопасности, к которой оно относится.
Примечание - Уровень полноты безопасности компонента ПО может быть ниже, чем уровень полноты функции безопасности, к которой он относится, если этот компонент используется в сочетании с другими компонентами АС, такими, что уровень полноты безопасности сочетания компонентов не меньше уровня полноты безопасности функции безопасности.
5.6.4.11 В состав проекта по мере возможности должны быть включены функции, выполняющие проверки и все диагностические тесты для обеспечения выполнения требований к полноте безопасности СБЗС-системы (как установлено в ГОСТ 53195.3*).
5.6.4.12 В состав проекта по мере возможности должны быть включены средства самоконтроля потоков управления и потоков данных, адекватные требуемому уровню полноты безопасности. При обнаружении ошибки должны быть выполнены соответствующие действия (см. таблицы А.2 и А.4 приложения А).
5.6.4.13 Если стандартное или ранее разработанное программное обеспечение должно использоваться как часть проекта (см. таблицы А.2 и А.4 приложения А), оно должно быть четко идентифицировано. Способность программного обеспечения удовлетворять требованиям, изложенным в спецификации требований к безопасности СБЗС ПО (см. 5.6), должна быть обоснована. Обоснование этой способности должно быть подкреплено данными по удовлетворительной работе ПО в схожем приложении или быть предметом тех же самых процедур верификации и подтверждения соответствия, которые подразумеваются для любого вновь разрабатываемого ПО. При этом должны быть оценены ограничения, связанные с условиями, в которых работало ПО (например, зависимость от операционной системы и компилятора).
Примечание - Такое обоснование может быть разработано при планировании безопасности (см. 5.4).
5.6.4.14 Подраздел 5.6.4 должен по мере возможности применяться к данным, включая любой язык генерации данных.
5.6.5 Требования к структуре ПО
5.6.5.1 Структура ПО должна определять основные компоненты и подсистемы ПО, их взаимосвязь, способ реализации необходимых характеристик, в том числе полноты безопасности.
Примечания
1 Примерами компонентов ПО являются операционные системы, базы данных, коммуникационные подсистемы, прикладные программы, инструментальные средства программирования и диагностики и т.п.
2 С точки зрения безопасности стадия разработки структуры программного обеспечения соответствует периоду разработки базовой стратегии безопасности для ПО.
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.