МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ

(МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION. METROLOGY AND CERTIFICATION

(ISC)

МЕЖГОСУДАРСТВЕННЫЙ

СТАНДАРТ

БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ СИСТЕМ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ ЗДАНИЙ И СООРУЖЕНИЙ

Часть 4

Требования к программному обеспечению

(IEC 61508-3:2010, NEQ)

(IEC 61508-4:2010, NEQ)

(ISO/IEC Guide 51:2014, NEQ)

Издание официальное

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1    ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия» (ФГУП «СТАНДАРТИНФОРМ») совместно с Международной ассоциацией «Системсервис» (МА «Системсервис»)

2    ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3    ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 30 апреля 2021 г. No 139-П)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004 - 97	Код страны по МК(ИСО 3166)004- 97	Сокращенное наименование национального органа по стандартизации
Армения	AM	ЗАО «Национальный орган по стандартизации и метрополии» Республики Армения
Беларусь	BY	Госстандарт Республики Беларусь
Киргизия	KG	Кыргызстандарт
Россия	RU	Росстандарт
Таджикистан	TJ	Таджикстандарт
Узбекистан	UZ	Узстандарт

4    Приказом Федерального агентства по техническому регулированию и метрологии от 28 мая 2021 г. No 477-ст межгосударственный стандарт ГОСТ 34332.4-2021 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2022 г.

5    В настоящем стандарте учтены основные нормативные положения следующих международных документов:

IEC 61508-3:2010 «Функциональная безопасность электрических, электронных, программируемых электронных систем, связанных с безопасностью. Часть 3. Требования к программному обеспечению» («Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 3: Requirements for software», NEQ);

IEC 61508-4:2010 «Функциональная безопасность электрических/электронных/программируемых электронных систем, связанных с безопасностью. Часть 4. Термины и сокращения» («Functional safety of electncal/electronic/programmabte electronic safety-related systems — Part 4: Definitions and abbreviations». NEQ):

ISO/IEC Guide 51:2014 «Аспекты безопасности. Руководящие указания по их включению в стандарты» («Safety aspects — Guidelines for their inclusion in standards». NEQ)

6    ВВЕДЕН ВПЕРВЫЕ

7    Настоящий стандарт подготовлен на основе применения ГОСТ Р 53195.4-2010¹ >

Приказом Федерального агентства по техническому регулированию и метрологии от 28 мая 2021 г. N? 477-ст ГОСТ Р 53195.4-2010 отменен с 1 января 2022 г.

вт сервисы для программируемого устройства, в отличие от прикладного программного обеспечения, которое по запрограммированным специфицированным функциям выполняет задачу безопасности управляемого оборудования.

3.1.13    сродство поддержки программного обоспочония в автономном режиме (software offline support tool): Программное средство, не имеющее непосредственного доступа к системе, связанной с безопасностью, в процессе ее функционирования.

Примечания

1    Средства поддержки программного обеспечения в автономном режиме могут быть разделены на три класса: Т1, Т2 и ТЗ. Средство поддержки класса Т1 не генерирует тех выходов, которые могут прямо или косвенно способствовать исполнению кода (включая данные) системы, связанной с безопасностью. Примерами средств поддержки класса Т1 служат текстовый редактор, требования или средства поддержки проектирования без возможности автоматического создания кода, а также инструменты управления конфигурацией.

2    Средство поддержки класса Т2 поддерживает тестирование либо проверку проекта или исполняемого кода, в которых ошибки в инструменте хотя не позволяют выявить дефекты, но и не могут напрямую создавать ошибки в исполняемом программном коде. Примерами средств поддержки класса Т2 служат генератор тестовых программ, средства измерения тестового охвата и средства статического анализа.

3    Средство поддержки класса ТЗ генерирует программы, которые явно или неявно включаются в рабочую программу системы, связанной с безопасностью. Примерами средств поддержки класса ТЗ служат оптимизирующий компилятор с неочевидной связью между исходным кодом программы и сгенерированным объектным кодом, а также компилятор, который включает исполнимый пакет программ в рабочую программу.

3.1.14    средство поддержки программного обеспечения в режиме реального времени

(software on-line support tool): Программное средство, имеющее непосредственный доступ к системе, связанной с безопасностью, в процессе ее функционирования.

3.1.15    стойкость к систематическим отказам: ССО (systematic capability): Мера уверенности (выраженная в диапазоне ССО 1 — ССО 4) в том. что систематическая полнота безопасности элемента соответствует требованиям заданного значения уровня полноты безопасности для определенной функции безопасности элемента, если этот элемент применен в соответствии с указаниями, определенными для этого элемента в соответствующем руководстве по безопасности.

Примечания

1    ССО определяется с учетом требований по предотвращению систематических отказов и управлению ими (см. ГОСТ 34332.3 и (4J).

2    Механизм систематического отказа зависит от природы элемента. Например, для элемента, представляющего ПО. должны быть рассмотрены только механизмы ошибок в программах. Для элемента, включающего в себя аппаратные средства (АС) и ПО. должны быть рассмотрены механизмы систематических отказов как для АС. так и для ПО.

3    Стойкость к систематическим отказам элемента ССО N при выполнении определенной функции безопасности означает, что элемент соответствует уровню полноты безопасности N для систематических отказов, если этот элемент применен в соответствии с указаниями для данного элемента в соответствующем руководстве по безопасности.

3.1.16    существующее ранее программное обеспечение (pre-existingsoftware): Компонент программного обеспечения, используемый в настоящее время, не разрабатываемый специально для выполняемого проекта либо для системы, связанной с безопасностью.

Примечание — ПО могло быть коммерчески доступным продуктом или, возможно, было разработано для ранее выпущенных изделия или системы. Существующее ранее ПО могло быть (или не могло быть) создано в соответствии с требованиями настоящего стандарта.

3.1.17    тестовая программа (test harness): Программный продукт, позволяющий имитировать ту среду, в которой будет действовать разрабатываемое программное обеспечение или аппаратное средство путем передачи тестовых данных в программу и регистрации ответа.

3.1.18    уровень полноты безопасности программного обеспечения; УПБ ПО (software safety integrity level): Стойкость к систематическим отказам элемента программного обеспечения, являющегося частью подсистемы или системы, связанной с безопасностью.

Примечание — УПБ характеризует функцию безопасности всей системы, но не любую из ее отдельных подсистем либо элементов, которые реализуют эту функцию безопасности. Поэтому ПО. как и любой его элемент, не имеет собственного УПБ. Однако фраза «программное обеспечение с УПБ N» означает, что «обоснована уверенность (выраженная значениями от 1 до 4) в том. что функция безопасности, реализуемая элементом (ПО), не будет приводить к сбою из-за соответствующих механизмов систематических отказов, если этот элемент

(ПО) применяется согласно указаниям, определенным в руководстве по безопасности, разработанном для такого элемента».

3.1.19    функциональный блок (functional unit). Объект аппаратного средства и/или программного обеспечения, выполняющий определенную задачу.

3.1.20    язык с ограниченной варьируемостью (limited variability language): Текстовый или графический язык программирования, предназначенный для коммерческих и промышленных программируемых электронных логических контроллеров, диапазон возможностей которого ограничен применением этих устройств.

Пример — К языкам с ограниченной варьируемостью, которые используют для представления прикладных программ для систем на основе программируемых логических контроллеров, относятся:

-    многоступенчатые схемы: графический язык, состоящий из набора символов для входов (представляющих поведение, характерное для таких устройств, как контакты, которые в нормальном состоянии замкнуты или разомкнуты), соединенных с помощью линий (указывающих направление тока), с символами, обозначающими выходы (представляющими поведение, свойственное реле);

-    булева алгебра: низкоуровневый язык, основанный на булевых операторах, таких как И, ИЛИ и НЕ, с возможностью добавления некоторых мнемонических инструкций;

-    функциональные блок-диаграммы: в дополнение к булевым операторам допускают использование более сложных функций, таких как операции с файлами, считывание и запись блоков данных, команд для сдвиговых регистров и устройств, задающих последовательность:

-    последовательные функциональные схемы: графическое представление многостадийной программы. состоящее из взаимосвязанных шагов, действий и ориентированных связей с промежуточными состояниями.

3.2 Сокращения

В настоящем стандарте использованы следующие сокращения:

АС — аппаратное(ые) средство(а);

ЖЦ — жизненный цикл:

КСБ — комплексная система безопасности:

ПЛК — программируемый логический контроллер:

ПО — программное обеспечение;

ПЭ — программируемая(ое, ый) электронная{ое, ый) — в отношении системы, средства, модуля, элемента;

СБ — свяэаиная(ое. ый) с безопасностью — в отношении системы, средства, устройства, модуля, элемента;

СБЗС система — система, связанная с безопасностью здания(ий), сооружения(ий);

СБ ПО — связанное с безопасностью программное обеспечение;

УО — управляемое оборудование;

УПБ — уровень полноты безопасности:

УПБ ПО — уровень полноты безопасности программного обеспечения.

4    Общие требования

Для обеспечения соответствия настоящему стандарту следует выполнять требования, установленные в ГОСТ 34332.2-2017 (подраздел 5.1).

5    Требования к документации

Цели и требования, предъявляемые к документации, — по ГОСТ 34332.2-2017 (подраздел 5.2).

6    Требования к управлению программным обеспечением Э/Э/ПЭ СБЗС систем

6.1 Цели настоящего раздела

Цели настоящего раздела — по ГОСТ 34332.2-2017 (подраздел 6.1).

6.2 Требования

6.2.1    В дополнение к требованиям, установленным в ГОСТ 34332.2-2017 (подраздел 6.2). следует выполнять перечисленные ниже требования.

6.2.2    Планирование функциональной безопасности СБ ПО осуществляют таким образом, чтобы определять стратегию поставок, разработки, интеграции, верификации, подтверждения соответствия и модификации СБ ПО в такой мере, в какой этого требует УПБ функций, реализуемых Э/Э/ПЭ СБЗС системой.

Примечание — Философия данного подхода состоит в использовании планирования функциональной безопасности в качестве возможности для приспособления настоящего стандарта для учета требуемой полноты безопасности для каждой функции безопасности, реализуемой Э/Э/ПЭ СБЗС системой.

6.2.3    Система управления конфигурацией ПО должка быть организована таким образом, чтобы:

-    использовать административные и технические средства контроля на протяжении ЖЦ СБ ПО для управления изменениями в программах и тем самым гарантировать непрерывное выполнение указанных в спецификациях требований к СБ ПО;

-    гарантировать выполнение операций, необходимых для того, чтобы продемонстрировать достижение заданной стойкости к систематическим отказам СБ ПО;

-    осуществлять тщательную поддержку с использованием уникальной идентификации всех элементов конфигурации, которые необходимы для обеспечения требований полноты безопасности Э/Э/ ПЭ СБЗС системы. В элементы конфигурации включают, как минимум, следующее:

-    анализ системы безопасности и требования к системе безопасности.

-    спецификацию ПО и проектную документацию.

-    исходный текст программ.

-    план и результаты тестирования.

-    документацию о проверках,

-    ранее разработанные программные элементы и пакеты, которые должны быть включены в Э/Э/ПЭ СБЗС систему.

-    все инструментальные средства и системы разработки, которые использовались при создании. тестировании или выполнении иных действий с ПО Э/Э/ПЭ СБЗС системы.

-    использовать процедуры контроля над внесением изменений для того, чтобы:

-    предотвращать несанкционированные модификации.

-    документально оформлять запросы на выполнение модификаций.

-    анализировать влияние предлагаемых модификаций и утверждать/не утверждать модификации.

-    подробно документально оформлять модификации и выдавать полномочия на выполнение всех утвержденных модификаций.

-    устанавливать основные параметры конфигурации системы для этапов разработки ПО и документально оформлять тестирование (частичное) интеграции системы.

-    гарантировать объединение и встраивание всех подсистем ПО (включая переработку более ранних версий).

Примечания

1    Для осуществления руководства и применения административных и технических средств контроля необходимы наличие полномочий и принятие управленческих решений.

2    С одной стороны, анализ влияния может включать в себя неформальную оценку. С другой стороны, анализ влияния может включать в себя строгий формальный анализ возможного неблагоприятного воздействия всех предложенных изменений, которые могут быть неправильно поняты или неверно осуществлены. Руководство по анализу влияния приведено в ГОСТ 34332.5;

-    гарантировать осуществление соответствующих мер по корректной загрузке прошедших подтверждение соответствия элементов СБ ПО и данных в систему во время ее выполнения.

Примечание — Допускается рассматривать отдельные целевые системы, а также общие системы. Для СБ ПО, кроме приложений, может понадобиться безопасный метод загрузки, например для встроенных программ программируемых устройств.

-    документально оформлять перечисленную ниже информацию для обеспечения возможности последующего аудита функциональной безопасности: состояния конфигурации, текущего состояния системы, обоснования (с учетом результатов анализа влияния) и утверждения всех модификаций, подробного описания всех модификаций.

-    строго документально оформлять каждую версию СБ ПО. обеспечивать хранение всех версий ПО и всей относящейся к ним документации, а также версий данных для предоставления возможности сопровождения и выполнения модификаций на протяжении всего периода использования разработанного программного продукта.

Примечание — Дополнительная информация по управлению конфигурацией приведена в ГОСТ 34332.5.

7 Требования к жизненному циклу связанного с безопасностью программного обеспечения

7.1    Общие положения

7.1.1    Цель

Целью требований, излагаемых в настоящем подразделе, является разделение процесса разработки СБ ПО на этапы и процессы (см. рисунки 2—5).

7.1.2    Требования

7.1.2.1    В соответствии с ГОСТ 34332.2-2017 (раздел 6) при планировании Э/Э/ПЭ СБЗС системы должен быть выбран и специфицирован ЖЦ для разработки ПО этой системы.

7.1.2.2    Может быть использована любая модель ЖЦ ПО Э/Э/ПЭ СБЗС системы при условии, что она соответствует всем целям и требованиям настоящего подраздела.

7.1.2.3    Каждая стадия ЖЦ СБ ПО может быть разделена на элементарные процессы. Для каждой стадии должны быть определены область применения, входные данные и выходные данные.

Примечание — На рисунках 3 и 4 представлены модели части ЖЦ проектирования и реализации Э/Э/ПЭ СБЗС системы и ПО ПЭ СБЗС системы соответственно.

7.1.2.4    Для рассмотрения ЖЦ сложных систем обеспечения безопасности объекта, включая КСБ, с учетом АС и ПО данных систем на стадиях проектирования и реализации может быть применена подробная V-образная модель.

Примечания

1    V-образная модель стадий проектирования и реализации КСБ. состоящей из ряда Э/Э/ПЭ СБЗС систем, представлена на рисунке 5. а на рисунке 6 — V-образная модель стадий проектирования и реализации СБ ПО для КСБ. содержащих ряд ПЭ СБЗС систем. На рисунках отражены итерационные процессы.

2    Модель стадий ЖЦ СБ ПО. которая соответствует требованиям настоящего раздела, может быть соответственно настроена для конкретных потребностей проекта или организации. Полный список стадий ЖЦ. приведенный в разделе 7. относится к большим заново разрабатываемым системам. Для небольших систем может оказаться целесообразным объединить стадии проектирования системы СБ ПО и проектирования архитектуры ПО.

3    Характеристики систем, управляемых данными, описаны в приложении Ж (например, языки программирования с полной или ограниченной изменчивостью, степень конфигурации данных) и могут быть использованы для настройки ЖЦ СБ ПО.

7.1.2.5    Любая настройка ЖЦ СБ ПО должна быть обоснована функциональной безопасностью.

7.1.2.6    Процедуры обеспечения качества и безопасности должны быть интегрированы в процессы ЖЦ СБ ПО.

7.1.2.7    Для каждой стадии ЖЦ следует использовать соответствующие методы и средства.

Примечания

1    Рекомендации по выбору методов и средств, а также ссылки на ГОСТ 34332.5 приведены в приложениях

А и Б.

2    В ГОСТ 34332.5 приведены рекомендации по выбору конкретного метода для обеспечения свойств, требуемых для достижения систематической полноты безопасности. Методы и средства, выбранные в соответствии с этими рекомендациями, сами по себе не гарантируют достижения необходимой полноты безопасности.

3    Достижение систематической полноты безопасности СБ ПО зависит от выбора методов с учетом следующих фахторов:

-    согласованность и взаимодополняющий характер выбранных методов, языков и инструментов для всего цикла разработки:

-    уровень восприятия разработчиками используемых ими методов, языков и инструментальных средств;

-    в какой степени методы, языки и инструментальные средства отвечают тем задачам, с которыми сталкиваются разработчики в процессе разработки.

Рисунок 4 — Часть ЖЦ ПО ПЭ СБЗС системы

7.1.2.9 Если на какой-либо стадии ЖЦ СБ ПО возникает необходимость внести изменение, относящееся к более ранней стадии ЖЦ. то. во-первых, используя анализ влияния, следует определить, какие модули и элементы СБ ПО будут изменены и. во-вторых, какие действия на более ранней стадии ЖЦ Э/Э/ПЭ СБЗС системы должны быть выполнены повторно.

Примечание — С одной стороны, анализ влияния может представлять собой неформальную оценку. С другой стороны, он может включать в себя строгий формальный анализ предполагаемых неблагоприятных последствий потенциальных изменений, которые, возможно, были не до конца продуманы или не должным образом реализованы. Руководящие указания по анализу влияния приведены в ГОСТ 34332.5-2021 (пункт Б.5.23).

7.2 Спецификация требований к связанному с безопасностью программному

обеспечению

Примечание — Спецификацию требований к СБ ПО формируют на стадии проектирования ПО (см. блок 6 на рисунке 4) после распределения требований безопасности в отношении Э/Э/ПЭ СБЗС систем, систем на основе неэлектрических технологий (в случав их применения) и прочих средств уменьшения риска (см. блок 5 на рисунке 4).

7.2.1    Цели

7.2.1.1    Во-первых, следует определить требования к СБ ПО как требования к функциям безопасности СБ ПО и требования к стойкости к систематическим отказам СБ ПО.

7.2.1.2    Во-вторых, должны быть установлены требования к функциям безопасности ПО каждой Э/Э/ПЭ СБЗС системы, которые необходимы для реализации данных функций.

7.2.1.3    И в-третьих, следует сформировать требования к стойкости относительно систематических отказов СБ ПО. которые необходимы для достижения УПБ. установленного для каждой функции безопасности, реализуемой Э/Э/ПЭ СБЗС системой.

7.2.2 Требования

Примечания

1    В большинстве случаев требования данного пункта выполняются комбинацией базового встраиваемого ПО и программных модулей, которые разработаны специально для конкретного применения. Именно комбинация этих двух видов ПО позволяет достигать характеристик, описанных в подразделах, приведенных ниже. Точная граница между базовым и прикладным ПО зависит от выбранной архитектуры программной системы (см. 7.4.3).

2    При выборе соответствующих методов и средств (см. приложения А и Б) для осуществления требований настоящего пункта необходимо рассмотреть следующие свойства [см. приложение В относительно интерпретации данных свойств и ГОСТ 34332.5-2021 (приложение Е). в котором приведены их неформальные определения) спецификации требований к ПО Э/Э/ПЭ СБЗС системы:

а)    полнота охвата потребностей безопасности ПО;

б)    корректность охвата потребностей безопасности ПО;

в)    отсутствие ошибок в самой спецификации, включая отсутствие неоднозначности;

г)    четкость требований к системе;

д)    отсутствие неблагоприятного взаимовлияния функций, не связанных с безопасностью, и функций, связанных с безопасностью, реализуемых ПО Э/Э/ПЭ СБЗС системы;

е)    способность обеспечения проведения оценки и подтверждения соответствия ПО.

3    Уровень безопасности, которому должно соответствовать СБ ПО. представлен набором функций безопасности и соответствующими требованиями к полноте безопасности, определенными для функций ПО в проекте Э/Э/ПЭ СБЗС системы. Полный набор требований к Э/Э/ПЭ СБЗС системе гораздо шире, так как включает в себя также функции безопасности, которые не выполняются ПО. Полнота спецификации требований к ПО Э/Э/ПЭ СБЗС системы решающим образом зависит от эффективности более ранних стадий ЖЦ системы.

7.2.2.1 Требования к СБ ПО приведены в требованиях к Э/Э/ПЭ СБЗС системе по ГОСТ 34332.3-2021 (подраздел 8.2).

7.222 Спецификация требований к СБ ПО должна быть выработана на основе заданных требований к функциональной безопасности Э/Э/ПЭ СБЗС системы по ГОСТ 34332.3 и других требований к планированию безопасности (см. раздел 6). Эта информация должна быть доступна для разработчика СБ ПО.

Примечания

1 Это требование означает, что должно быть тесное взаимодействие между разработчиком Э/Э/ПЭ системы и разработчиком СБ ПО (см. ГОСТ 34332.3 и настоящий стандарт). По мере того как требования к безопасности и архитектура СБ ПО (см. 7.4.3) становятся более определенными, может усиливаться влияние на архитектуру АС Э/Э/ПЭ СБЗС системы, и по этой причине становится значимым конструктивное сотрудничество между разработчиками АС и ПО (см. рисунок 2).

2 В проект ПО может быть включено действующее, зарекомендовавшее себя ПО. Разрабатываемое ПО может быть создано без учета спецификации требований к формируемой системе. В 7.4.2.12 представлены требования к функционирующему ПО, соответствующему спецификации требований к СБ ПО Э/Э/ПЭ СБЗС системы.

7.2.2.3    Спецификация требований к СБ ПО должна быть достаточно подробной для обеспечения стадий проектирования и реализации необходимой информации с целью достижения требуемой полноты безопасности (включая требования к независимости, см. ГОСТ 34332.3) и выполнения оценки уровня функциональной безопасности.

Примечание — Уровень детальности спецификации может быть изменен в зависимости от сложности применения. Соответствующая спецификация функционального поведения СБ ПО гложет включать в свой состав требования к точности, синхронизации и быстродействию, емкости, устойчивости, допустимой перегрузке и другим свойствам Э/Э/ПЭ СБЗС системы, характеризующим конкретное применение.

7.2.2.4    Для решения проблемы независимости должен быть выполнен соответствующий анализ отказов СБ ПО по общей причине. Если выявлены вероятные механизмы отказа, то должны быть приняты эффективные меры защиты.

Примечание — В приложении Е приведены методы достижения одного аспекта независимости ПО.

72.2.5    Разработчик СБ ПО должен ознакомиться с информацией согласно 72.2.2 для того, чтобы убедиться в том. что требования определены адекватным образом. В частности, разработчик СБ ПО должен учесть:

-    функции безопасности;

-    конфигурацию или архитектуру системы:

-    требования к полноте безопасности АС (программируемой электроники, датчиков и исполнительных устройств);

-    требования к стойкости к систематическим отказам СБ ПО;

-    быстродействие и время отклика;

-    синхронизуемость времен взаимодействия Э/Э/ПЭ СБЗС систем и их составляющих:

-    интерфейсы оборудования и оператора, включая объективно прогнозируемые нарушения.

Примечание — Необходимо рассмотреть совместимость с любыми действующими способами применения ПО.

7.22.6    В специфицированных требованиях к СБ ПО должны быть подробно описаны все соответствующие режимы работы УО Э/Э/ПЭ СБЗС системы и любых АС или систем, подсоединенных к Э/Э/ ПЭ СБЗС системе в том случае, если отсутствует их адекватное определение в требованиях к безопасности. специфицированных для Э/Э/ПЭ СБЗС системы.

7.22.7    В спецификации требований к СБ ПО должны быть определены и документально оформлены все связанные с безопасностью ограничения и иные ограничения, относящиеся к взаимодействию между АС и ПО.

7.22.6 В той степени, в которой это требуется при описании проекта архитектуры АС Э/Э/ПЭ системы, и с учетом возможного увеличения ее сложности в спецификации требований к СБ ПО должны быть учтены:

-    самоконтроль ПО (например, по ГОСТ 34332.5);

-    мониторинг ПЭ аппаратуры, датчиков и исполнительных устройств:

-    периодическое тестирование функций безопасности во время выполнения программы:

-    предоставление возможности тестирования функций безопасности во время работы УО;

-    функции ПО для выполнения контрольных испытаний и всех диагностических тестов для обеспечения соблюдения требований полноты безопасности Э/Э/ПЭ СБЗС системы.

Примечание — Увеличение сложности, которое может возникнуть вследствие вышеупомянутых соображений. может потребовать пересмотра архитектуры Э/Э/ПЭ СБЗС системы.

7.2.2.9    Если Э/Э/ПЭ СБЗС система должка выполнять функции, не относящиеся к безопасности, эти функции должны быть четко указаны в спецификации требований к СБ ПО.

Примечание — Требования относительно отсутствия взаимовлияния функций, связанных и не связанных с безопасностью, приведены в 7.4.2.8 и 7.4.2.Э.

7.2.2.10    В спецификации требований к СБ ПО должны быть указаны необходимые характеристики безопасности программной продукции, а не ее проекта, как это определяется при планировании

системы безопасности (см. ГОСТ 34332.3-2021 (раздел 6)]. С учетом 7.2.2.1—7.2.2.9 в зависимости от конкретных обстоятельств должны быть определены следующие положения:

требования к функциям ПО Э/Э/ПЭ СБЗС системы:

а)    функции, которые позволяют УО достигать или поддерживать безопасное состояние.

б)    функции, связанные с обнаружением, оповещением и обработкой ошибок АС программируемой электроники,

в)    функции, связанные с обнаружением, оповещением и обработкой ошибок датчиков и исполнительных устройств,

г)    функции, связанные с обнаружением, оповещением и обработкой ошибок в самом СБ ПО (самоконтроль ПО).

д)    функции, связанные с периодическим тестированием функций безопасности в режиме реального времени (в предопределенной операционной среде),

е)    функции, связанные с периодическим тестированием функций безопасности в автономном режиме (т. е. в тех условиях, в которых функция безопасности УО не выполняется).

ж)    функции, обеспечивающие модификацию программируемой электроники Э/Э/ПЭ СБЗС системы,

и)    интерфейсы функций, не связанных с безопасностью.

к)    интерфейсы между ПО и ПЭ системой,

л)    быстродействие и время отклика АС системы,

м)    синхронизуемость времен взаимодействия Э/Э/ПЭ СБЗС систем и их составляющих.

Примечание — В интерфейсы должны быть включены средства программирования в автономном и неавтономном режимах;

н)    средства коммуникации, связанные с безопасностью [см. ГОСТ 34332.3-2021 (пункт 8.3.15)]:

требования к стойкости к систематическим отказам СБ ПО:

а)    уровеиь(уровни) полноты безопасности для каждой функции безопасности по первому перечислению.

б)    требования независимости между функциями.

7.2.2.11    Если требования к СБ ПО выражены или выполнены в виде конфигурации данных, то эти данные должны быть:

-    согласованы с требованиями к Э/Э/ПЭ СБЗС системе;

-    выражены значениями из допустимого диапазона и санкционированными комбинациями реализующих их параметров;

-    определены способом, который совместим с базовым ПО (например, последовательность выполнения. время выполнения, структуры данных и т. д.).

Примечания

1    Эти требования к прикладным данным относятся, в частности, к применениям, управляемым данными. Они характеризуются следующим образом; исходный код уже существует, а главная цель разработки состоит в том. что конфигурация данных правильно задает поведение, требуемое от применения. Между элементами данных могут быть сложные зависимости, и достоверность данных может меняться с течением времени.

2    Указания по системам, управляемым данными, приведены в приложении Ж.

7.2.2.12    Если данные определяют интерфейс между ПО и внешними системами, то в дополнение к ГОСТ 34332.3-2021 (пункт 8.3.15) необходимо рассмотреть следующие факторы и характеристики:

-    согласованность во времени при определении данных:

-    недостоверные, находящиеся вне определенного диапазона или несвоевременные значения;

-    время отклика и пропускная способность, включая условия максимальной загрузки;

-    время выполнения в наиболве/наименее приемлемых случаях и зависание;

-    переполнение и недостаточная емкость хранилища данных.

7.2.2.13    Параметры эксплуатации должны быть защищены;

-    от недостоверных, находящихся вне определенного диапазона или несвоевременных значений:

-    несанкционированных изменений,

-    искажений

Примечания

1 Следует рассмотреть защиту от несанкционированных изменений как программных, так и нвпрограммных механизмов. Необходимо отметить, что эффективная защита от несанкционированных изменений ПО гложет от-

Информация о введении в действие (прекращении действия) настоящего стандарта и uat/e-нений к нему на территории указанных выше государств публикуется в указателях национальных стандартов, издаваемых в этих государствах, а также в сети Интернет на сайтах соответствующих национальных органов по стандартизации.

В случае пересмотра, изменения или отмены наспюящего стандарта соответствующая информация будет опубликована на официальном инторнот-сайтв Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге «Межгосударственные стандарты»

©Стандартинформ. оформление, 2021

В Российской Федерации настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

рицагельно отразиться на безопасности, например в том случав, если изменения необходимо выполнить быстро и в напряженных условиях.

2 Несмотря на то что человек может быть частью СБ системы, относящейся к безопасности [см. ГОСТ 34332.2-2017 (раздел 1)]. требования, обусловленные человеческим фактором и связанные с проектированием Э/ЭЛ1Э СБЗС систем, в настоящем стандарте подробно не рассматриваются. Однако при необходимости должны быть изучены следующие соображения:

-    в информационной системе оператора следует использовать общепринятые пиктографические представления и терминологию. Они должны быть четкими, понятными и лишенными ненужных деталей и/или аспектов;

-    информация об УО. выведенная оператору на экран, должна быть подробной, достоверной и отображающей физическое состояние УО.

-    если на экране дисплея оператору отражена информация о выполняющихся в УО процессах и/или если оператор выполняет определенные действия, последствия которых невозможно сразу заметить, то выведенная на экран в автоматическом режиме информация должна быть представлена таким образом, чтобы отображалось то состояние, в котором находится данная система, или та последовательность действий, в соответствии с которой указано, какое состояние последовательности достигнуто, какие операции могут быть выполнены и какими могут быть возможные последствия.

7.3 Планирование подтверждения соответствия безопасности системы для аспектов

программного обеспечения

Примечания

1    Эта стадия относится к блоку 9 на рисунке 3.

2    Подтверждение соответствия для ПО обычно не может быть выполнено отдельно от используемых АС и системной среды.

7.3.1    Цель

Целью требований настоящего подраздела является разработка плана подтверждения соответствия связанных с безопасностью программных аспектов безопасности.

7.3.2    Требования

7.3.2.1    В ходе планирования должны быть определены процедурные и технические шаги, которые необходимо выполнить для демонстрации того, что ПО соответствует требованиям безопасности.

7.3.2.2    В плане подтверждения соответствия программных аспектов безопасности системы должно быть отражено следующее:

а)    точная дата, когда должно происходить подтверждение соответствия;

б)    перечень лиц, осуществляющих подтверждение соответствия;

в)    идентификация соответствующих режимов работы УО. включая:

1)    подготовку к использованию, в том числе установку (загрузку) и настройку.

2)    работу в режиме запуска и обучения, в автоматическом, ручном, полуавтоматическом и стационарном режимах.

3)    переустановку, выключение, сопровождение.

4)    разумно прогнозируемые ненормальные условия и ошибки оператора.

г)    идентификация СБ ПО. для которого должна быть проведена процедура подтверждения соответствия, для каждого режима работы УО до момента его ввода в эксплуатацию;

д)    техническая стратегия для подтверждения соответствия (например, аналитические методы, статистическое тестирование и т. л.):

е)    методыУсредства и процедуры в соответствии с перечислением д), которые должны быть использованы для подтверждения того, что каждая функция безопасности соответствует установленным требованиям к функциям безопасности и требованиям к стойкости к систематическим отказам СБ ПО;

ж)    условия, в которых должны происходить процедуры подтверждения соответствия (например, при тестировании может потребоваться использование калиброванных инструментов и оборудования);

и)    критерии прохождения/непрохождения подтверждения соответствия;

к)    политика и процедуры, используемые для оценки результатов подтверждения соответствия, в частности при оценке отказов.

Примечание — Эти требования основаны на общих требованиях ГОСТ 34332.2-2017 (подраздел 7.10).

7.3.2.3    Подтверждение соответствия служит обоснованием выбранной стратегии. В техническую стратегию для подтверждения соответствия СБ ПО должна быть включена следующая информация о выборе;

-    ручных или автоматических методов или и тех и других;

Содержание

1    Область применения .................................................................1

2    Нормативные ссылки.................................................................3

3    Термины, определения и сокращения ...................................................3

4    Общие требования...................................................................6

5    Требования к документации............................................................6

6    Требования к управлению программным обеспечением Э/Э/ПЭ СБЗС систем ..................6

7    Требования к жизненному циклу связанного с безопасностью программного обеспечения ........8

8    Оценка функциональной безопасности .................................................34

Приложение А (обязательное) Руководство по выбору методов и средств......................36

Приложение Б (обязательное) Подробные таблицы........................................44

Приложение В (справочное) Свойства стойкости к систематическим отказам пограммного

обеспечения............................................................49

Приложение Г (обязательное) Руководство по безопасности для применяемых изделий.

Дополнительные требования к элементам программного обеспечения ...........81

Приложение Д (справочное) Взаимосвязь между ГОСТ 34332.3 и настоящим стандартом ........83

Приложение Е (справочное) Методы, не допускающие взаимодействия между элементами

программного обеспечения на одном компьютере ............................85

Приложение Ж (справочное) Руководство по адаптации жизненного цикла систем, управляемых

данными ..............................................................90

Библиография........................................................................93

Введение

Современные здания и сооружения (объекты капитального строительства) — это сложные системы. в состав которых входят система строительных конструкций и ряд инженерных систем в разных сочетаниях, в том числе для жизнеобеспечения, реализации технологических процессов, энерго- и ресурсосбережения. обеспечения безопасности, и другие системы. Эти системы взаимодействуют друг с другом, с внешней и внутренней средами и представляют собой единое целое, выполняя определенные функции назначения.

Объекты капитального строительства тесно саяэаны с особенностями конкретной местности. Рабочие характеристики зданий, сооружений и входящих в них систем могут быть реализованы, проверены и использованы только в том месте, в котором объекты построены и системы установлены.

Безопасность зданий и сооружений обеспечивается применением совокупности мер. мероприятий и средств снижения риска причинения вреда до приемлемого уровня риска и его поддержания в течение периода эксплуатации или использования этих объектов. К средствам снижения риска относятся системы, связанные с безопасностью зданий и сооружений (далее — СБЗС системы). К данным системам относятся системы, неполный перечень которых представлен в ГОСТ 34332.1-2017 (приложение А. раздел А.З). Среди СБЗС систем наиболее распространенными являются системы, содержащие электрические, и/или электронные, и/или программируемые электронные (Э/Э/ПЭ) компоненты. Такие системы, именуемые Э/Э/ПЭ СБЗС системами, в течение многих лет применяют для выполнения функций безопасности. Кроме них и вместе с ними используют системы, основанные на неэлектрических (гидравлических, пневматических) технологиях, а также прочие средства уменьшения риска. Для решения задач безопасности зданий и сооружений во всех больших объемах применяют программируемые электронные СБЗС системы (далее — ПЭ СБЗС системы).

Следующими по важности после характеристик назначения являются характеристики безопасности систем. Наиболее существенной среди характеристик безопасности систем признана их функциональная безопасность.

Настоящий стандарт устанавливает основные требования к функциональной безопасности программного обеспечения (ПО) ПЭ СБЗС систем и к ПО. используемому для разработки таких систем в рамках области применения ГОСТ 34332.1 — ГОСТ Р 34332.3. Настоящий стандарт ориентирован на обеспечение соблюдения требований безопасности и антитеррористической защищенности зданий и сооружений, в том числе объектов транспортных инфраструктур, установленных техническими регламентами Таможенного союза 11}—[3]. и на развитие базовых требований этих технических регламентов.

Настоящий стандарт распространяется на ПО Э/Э/ПЭ СБЗС систем и ПО составляющих этих систем, включая сенсоры, исполнительные устройства и интерфейс «человек—машина». Он рассчитан на любой диапазон сложности Э/Э/ПЭ СБЗС систем и ориентирован на комплексное обеспечение безопасности зданий и сооружений гражданского и промышленного строительства, включая объекты инфраструктур промышленности и энергетики, транспорта и связи, гидротехнических и мелиоративных сооружений, включая линейные объекты.

Настоящий стандарт входит в комплекс стандартов с наименованием «Безопасность функциональная систем, связанных с безопасностью зданий и сооружений» и является четвертым стандартом этого комплекса — «Часть 4. Требования к программному обеспечению». Другие стандарты, входящие в этот комплекс:

-    часть 1. Основные положения,

-    часть 2. Общие требования;

-    часть 3. Требования к системам:

-    часть 5. Меры по снижению риска, методы оценки.

-    часть 6. Прочие средства уменьшения риска, системы мониторинга,

-    часть 7. Порядок применения ГОСТ 34332. примеры расчетов.

Структура комплекса ГОСТ 34332 приведена на рисунке 1.

Рисунок 1 — Структура комплекса ГОСТ 34332

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ СИСТЕМ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ ЗДАНИЙ

И СООРУЖЕНИЙ

Часть 4

Требования к программному обеспечению

Functional safety of building/construction safety-related systems. Part 4. Requirements for software

Дата введения — 2022—01—01

1 Область применения

1.1 Настоящий стандарт:

-    применяется совместно с ГОСТ 34332.1 — ГОСТ 34332.3 и ГОСТ 34332.5;

-    распространяется на программное обеспечение (ПО) электрических, электронных, программируемых электронных (Э/Э/ПЭ), связанных с безопасностью зданий и сооружений системы (далее — Э/Э/ ПЭ СБЗС системы), включая комплексные системы безопасности (КСБ). устанавливаемые или установленные во вновь возводимых или реконструируемых зданиях и сооружениях (далее — объекты) всех отраслей экономики независимо от форм собственности и ведомственной принадлежности, включая жилые, общественные и производственные здания и сооружения, в том числе на Э/ЭЯ1Э СБЗС системы объектов инфраструктуры перерабатывающей промышленности, энергетики, транспорта, гидротехнических и мелиоративных сооружений, включая линейные объекты, для обеспечения их безопасности и антитеррористической защищенности:

-    распространяется на любое ПО. являющееся частью Э/Э/ПЭ СБЗС системы, либо на ПО, используемое для разработки Э/Э/ПЭ СБЗС систем в области применения ГОСТ 34332.1 — ГОСТ 34332.3. Такое ПО. связанное с его безопасностью (СБ ПО), включает в себя операционные системы, системное ПО, программы, применяемые в коммуникационных сетях, интерфейсы пользователей и обслуживающего персонала, встроенные программно-аппаратные средства, а также прикладные программы;

-    устанавливает требования к тем действиям и процедурам, которые должны быть выполнены на стадиях проектирования, планирования и реализации СБ ПО.

Примечания

1    Под реализацией СБ ПО понимается его установка на аппаратных средствах (АС), программируемых электронных (ПЭ) СБЗС системах (далее — ПЭ СБЗС системы), включая комплексные системы безопасности (КСБ), интеграцию, наладку, оценку и подтверждение соответствия, в том числе на объекте.

2    Области применения настоящего стандарта и ГОСТ 34332.3 тесно взаимосвязаны. Эту взаимосвязь (см. рисунок 2) следует учитывать при применении настоящего стандарта:

Издание официальное

Рисунок 2 — Взаимосвязь областей применения настоящего стандарта и ГОСТ 34332.3

-    устанавливает конкретные требования к инструментальным средствам поддержки, используемым для разрабатываемых и конфигурируемых Э/Э/ПЭ СБЗС систем, включая КСБ. в соответствии с ГОСТ 34332.2 и ГОСТ 34332.3.

Примечания

1    СБ ПО. применяемое при разработке концепции безопасности объекта (здания, сооружения), определении назначения и области применения Э/Э/ПЭ СБЗС систем, систем снижения риска на основе неэлектрических технологий и прочих средств уменьшения риска, при анализе опасностей и риска, подлежащих компенсации Э/Э/ ПЭ СБЗС системами и другими прочими средствами уменьшения риска, при определении требований к функциям безопасности и распределении функций безопасности по Э/Э/ПЭ СБЗС системам, относят ко всем Э/Э/ПЭ СБЗС системам, включая КСБ [см. ГОСТ 34332.2-2017 (рисунок 1, блоки 1—5)].

2    После распределения функций безопасности по конкретным Э/Э/ПЭ СБЗС системам в настоящем стандарте подробно рассмотрены требования к СБ ПО части этих систем, а именно ПЭ СБЗС системам, на стадии их проектирования и реализации;

-    предусматривает определение функции безопасности и стойкости к систематическим отказам СБ ПО.

Примечания

1    Описание части работы в отношении спецификации Э/Э/ПЭ СБЗС систем, выполненной по ГОСТ 34332.3-2021 (подраздел 8.2). не следует повторять в настоящем стандарте.

2    Определение функций безопасности и стойкости к систематическим отказам СБ ПО представляет собой итеративную процедуру.

3    Структура документации установлена в ГОСТ 34332.2-2017 (раздел 5 и приложение А). В структуре документации могут быть учтены процедуры, используемые в компаниях, а также практика, сложившаяся в отдельных областях применения систем;

-    устанавливает требования к стадиям части жизненного цикла (ЖЦ) ПО ПЭ СБЗС системы и к действиям, которые следует предпринимать в процессе проектирования и разработки СБ ПО. Эти

требования включают в себя применение методов и средств, ранжированных по уровням требуемой стойкости к систематическим отказам и предназначенных для предотвращения ошибок и управления ошибками и отказами в СБ ПО;

-    устанавливает требования к информации, относящейся к вопросам подтверждения соответствия аспектов ПО Э/Э/ПЭ СБЗС системы, которая должна быть предоставлена организации, осуществляющей интеграцию программируемой электроники в Э/Э/ПЭ СБЗС систему и интеграцию Э/Э/ПЭ СБЗС систем в КСБ;

-    устанавливает;

-    требования к подготовке предоставления информации и проведения процедур, касающихся СБ ПО. которое необходимо пользователям для эксплуатации и технического обслуживания Э/Э/ПЭ СБЗС систем,

-    требования, предъявляемые к организациям, выполняющим модификацию СБ ПО, включая требования ГОСТ 34332.2 и ГОСТ 34332.3, требования к инструментальным средствам поддержки, таким как средства разработки и проектирования, трансляции, тестирования и отладки, управления конфигурацией.

1.2    Настоящий стандарт не распространяется на ПО Э/Э/ПЭ СБЗС системы, которая является единственной системой, способной осуществить необходимое снижение риска на объекте, и требуемая полнота безопасности этой системы ниже, чем определено уровнем полноты безопасности (УПБ) УПБ 1 — наиболее низким уровнем полноты безопасности. Настоящий стандарт не применяется к ПО медицинского оборудования.

1.3    Общая структура ГОСТ 34332.1 — ГОСТ 34332.7 и роль настоящего стандарта в достижении функциональной безопасности Э/Э/ПЭ СБЗС систем показана на рисунке 1.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты;

ГОСТ 34332.1-2017 Безопасность функциональная систем, связанных с безопасностью зданий и сооружений. Часть 1. Основные положения

ГОСТ 34332.2-2017 Безопасность функциональная систем, связанных с безопасностью зданий и сооружений. Часть 2. Общие требования

ГОСТ 34332.3-2021 Безопасность функциональная систем, связанных с безопасностью зданий и сооружений. Часть 3. Требования к системам

ГОСТ 34332.5-2021 Безопасность функциональная систем, связанных с безопасностью зданий и сооружений. Часть 5. Меры по снижению риска, методы оценки

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов на официальном интернет-сайте Межгосударственного совета по стандартизации. метрологии и сертификации (wv.4v.easc. by) или по указателям национальных стандартов, издаваемым в государствах, указанных в предисловии, или на официальных сайгах соответствующих национальных органов по стандартизации. Если на документ дана недатированная ссылка, то следует использовать документ, действующий на текущий момент, с учетом всех внесенных в него изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то следует использовать указанную версию этого документа. Если после принятия настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение применяется без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины, определения и сокращения

3.1    Термины и определения

3.1    В настоящем стандарте применены термины по ГОСТ 34332.1 — ГОСТ 34332.3, а также следующие термины с соответствующими определениями:

3.1.1    анимация (animation); Имитация работы программного обеспечения (или отдельной его части), предназначенная для отображения существенных аспектов поведения программируемой электронной системы, связанной с безопасностью зданий и сооружений.

Примечания

1    Анимация применима, например, к спецификации требований для представления проекта системы на достаточно высоком уровне в соответствующем формате.

2    Анимация позволяет оценить специфическое поведение системы при задании параметров и данных, близких к реальным.

3.1.2    данные (data): Информация, представленная в виде, удобном для передачи, интерпретации либо при обработке компьютером.

Примечание — Данные могут быть представлены в виде статической информации (например, совокупности заданных значений либо представления географической информации) или команды для задания последовательности выполнения предварительно созданных функций.

3.1.3    динамическое тестирование (dynamic testing): Работа программного обеспечения и/или аппаратного средства, выполняемая под контролем и планомерно для демонстрации наличия/отсут-ствия установленного функционала.

Примечание — При динамическом тестировании в отличие от статистического анализа требуется выполнение программ.

3.1.4    жизненный цикл программного обеспечения; ЖЦ ПО (software lifecycle): Период времени. включающий в себя стадии разработки: требований к программному обеспечению, программного обеспечения, кодирования, тестирования, интеграции, установки, а также стадию модификации.

3.1.5    избыточность (redundancy): Наличие средств в дополнение к средствам или данным, достаточным для выполнения требуемой операции или предоставления информации.

Пример — Примерами избыточности являются дублирование функциональных компонентов и добавление избыточных битов, в том числе битов четности.

3.1.6    инструментальные средства поддержки программного обеспечения (инструментальные средства поддержки ПО): Средства разработки, проектирования, кодирования, тестирования, отладки. управления конфигурацией программного обеспечения.

3.1.7    полнота безопасности программного обеспечения (полнота безопасности ПО) (software safety integrity): Количественная характеристика, определяющая вероятность того, что программное обеспечение программируемой электронной системы будет выполнять заданные функции безопасности при указанных условиях в точение установленного периода времени.

3.1.8    прикладное программное обеспечение (application software): Часть программного обеспечения программируемой электронной системы, которая по специфицированным функциям выполняет задачу, связанную с безопасностью управляемого оборудования, но не обеспечивает функционирования и не предоставляет сервисы для программируемого устройства.

3.1.9    программируемая электроника; ПЭ (programmable electronic, РЕ): Средство, которое основано на использовании компьютерных технологий и может включать в себя аппаратное средство и программное обеспечение, а также устройства ввода и/или вывода.

Примечания

1    Данный термин включает в себя микроэлектронные устройства, основанные на одном или нескольких центральных процессорах и связанных с ними устройствах памяти и т. п.

2    К программируемым электронным устройствам относятся: микропроцессоры, микроконтроллеры, программируемые контроллеры, специализированные интегральные схемы, программируемые логические контроллеры. другие устройства на основе компьютерных технологий (например, микропроцессорные датчики, преобразователи. устройства привода).

3.1.10    программное обеспечение; ПО (software): Продукт интеллектуальной деятельности, включающий в свой состав программы, процедуры, данные, правила и ассоциированную информацию, имеющую отношение к работе системы обработки данных.

Примечание — Программное обеспечение является независимым от носителя записи, на котором оно записано.

3.1.11    связанное с безопасностью программное обеспечение; СБ ПО (safety-related software): Программное обеспечение, которое используется для реализации функций безопасности в системах, связанных с безопасностью.

3.1.12    системное программное обеспечение (system software): Часть программного обеспечения программируемой электронной системы, которая обеспечивает функционирование и предоставля-