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

(введен в действие Приказом Росстандарта от 28.05.2021 № 477-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р 53195.4-2010"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-53195-4-2010" "ГОСТ Р 53195.4-2010. Национальный стандарт Российской Федерации. Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к... (утв. и "
  n1["ГОСТ 34332.4-2021"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-34332-4-2021" "ГОСТ 34332.4-2021. Межгосударственный стандарт. Безопасность функциональная систем, связанных с безопасностью зданий и сооружений. Часть 4. Требования к программному обеспечению (в"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

Введен в действие

БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ СИСТЕМ,

13.220

Предисловие

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

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

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

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

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

4 Приказом Федерального агентства по техническому регулированию и метрологии от 28 мая 2021 г. № 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 electrical/electronic/programmable 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 <1>

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

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

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

Введение

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

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

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

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

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

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

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

• часть 1. Основные положения;
• часть 2. Общие требования;
• часть 3. Требования к системам;
• часть 5. Меры по снижению риска, методы оценки;
• часть 6. Прочие средства уменьшения риска, системы мониторинга;
• часть 7. Порядок применения ГОСТ 34332, примеры расчетов.

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

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

1.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 Определение функций безопасности и стойкости к систематическим отказам СБ ПО представляет собой итеративную процедуру.

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

• требования, предъявляемые к организациям, выполняющим модификацию СБ ПО, включая требования ГОСТ 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. Меры по снижению риска, методы оценки

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации (www.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, PE): Средство, которое основано на использовании компьютерных технологий и может включать в себя аппаратное средство и программное обеспечение, а также устройства ввода и/или вывода.

Примечания

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

Примечания

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

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

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

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).

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

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

Рисунок 5 — V-образная модель стадий разработки и реализации ЖЦ КСБ

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

Рисунок 6 — V-образная модель стадий разработки и реализации ЖЦ СБ ПО КСБ

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

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

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

Примечания

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

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

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

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

7.1.2.8 Результаты процессов ЖЦ программного СБ ПО должны быть документально оформлены (см. раздел 5).

Примечание — В ГОСТ 34332.2-2017 (раздел 5) рассмотрено документальное оформление результатов стадий ЖЦ Э/Э/ПЭ СБЗС системы. При разработке некоторых Э/Э/ПЭ СБЗС систем результаты определенных стадий ЖЦ системы могут быть оформлены в виде отдельных документов, тогда как результаты других стадий могут быть объединены в один документ. Существенным является требование, чтобы результаты стадии ЖЦ Э/Э/ПЭ СБЗС системы соответствовали ее предназначению.

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.2.10 В спецификации требований к СБ ПО должны быть указаны необходимые характеристики безопасности программной продукции, а не ее проекта, как это определяется при планировании системы безопасности [см. ГОСТ 34332.3-2021 (раздел 6)]. С учетом 7.2.2.1 - 7.2.2.9 в зависимости от конкретных обстоятельств должны быть определены следующие положения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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 Подтверждение соответствия служит обоснованием выбранной стратегии. В техническую стратегию для подтверждения соответствия СБ ПО должна быть включена следующая информация о выборе:

• ручных или автоматических методов или и тех и других;
• статических или динамических методов или и тех и других;
• аналитических или статистических методов или и тех и других:
• критериев приемки на основе объективных факторов или экспертной оценки или и того и другого.

7.3.2.4 В рамках процедуры подтверждения соответствия аспектов СБ ПО, если этого требует УПБ [см. ГОСТ 34332.2-2017 (раздел 8)], область применения и содержание плана подтверждения соответствия безопасности системы, аспектов ПО должны быть изучены экспертом или третьей стороной, представляющей эксперта. В эту процедуру включают также заявление о присутствии эксперта при испытаниях.

7.3.2.5 В критерии прохождения/непрохождения при завершении подтверждения соответствия СБ ПО включают:

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

Последовательность выполнения требований относительно проектирования и разработки ПО приведена в 7.4.1.1 - 7.4.1.6.

7.4 Проектирование и разработка программного обеспечения

Примечание — Эта стадия относится к блокам 6 и 7 на рисунке 3.

7.4.1 Цели

7.4.1.1 Создание такой архитектуры ПО, которая соответствовала бы заданным требованиям к СБ ПО с необходимым УПБ.

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

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

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

7.4.1.5 Проверка выполнения требований к СБ ПО (в отношении необходимых функций безопасности и стойкости к систематическим отказам ПО).

7.4.1.6 Гарантирование в той мере, в которой это уместно, того, что конфигурирование данных программируемой электроники СБЗС системы соответствует указанным в настоящем подразделе требованиям стойкости к систематическим отказам ПО.

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

7.4.2.1 В зависимости от технологии процесса разработки ПО ответственными за соответствие требованиям 7.4 могут быть следующие лица: только поставщик СБ ПО (например, поставщик), только пользователь, имеющий непосредственное отношение к решаемым задачам (например, разработчик прикладных программ), или и поставщик, и пользователь. Распределение ответственности должно быть определено во время планирования системы безопасности (см. раздел 6).

Примечание — Характеристики системы и архитектуры ПО, для которых необходима определенность при выборе подразделения, ответственного за соответствие требованиям 7.4, приведены в 7.4.3.

7.4.2.2 В соответствии с определенным УПБ и конкретными техническими требованиями к функции безопасности выбирают метод проектирования с теми характеристиками, которые способствуют:

абстрактному представлению, разделению на модули и другие характеристики, контролирующие уровень сложности;

выражению:

а) выполняемых функций,

б) обмена данными между элементами,

в) информации, относящейся к последовательности и времени выполнения программ,

г) ограничений синхронизации,

д) параллельного и синхронизированного доступа к совместно используемым ресурсам,

е) структур данных и их свойств,

ж) проектных предположений и их зависимостей,

и) обработки исключений,

к) проектных предположений (предварительных условий, постусловий, инвариантов),

л) комментариев;

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

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

верификации и оценке соответствия.

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

7.4.2.4 Выбор метода проектирования определен характеристиками, облегчающими модификацию ПО. К числу таких характеристик относят модульность, скрытие информации и инкапсуляцию.

7.4.2.5 Представление проекта следует основывать на той нотации, которая является однозначно определенной или ограничена до однозначно определенных свойств.

7.4.2.6 В проект, по мере возможности, включают ту часть ПО, которая связана с безопасностью.

7.4.2.7 В проект ПО включают (соразмерно требуемому УПБ) средства самоконтроля потоков управления и потоков данных. При обнаружении отказа должны быть выполнены соответствующие действия.

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

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

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

7.4.2.10 Если стойкость к систематическим отказам элемента ПО ниже, чем требуется для УПБ функции безопасности, к которой он относится, то этот элемент следует использовать в сочетании с другими элементами, что будет гарантировать стойкость к систематическим отказам и соответствовать УПБ функции безопасности.

7.4.2.11 Если функция безопасности реализована с использованием комбинации элементов ПО, для которых известны их значения стойкости к систематическим отказам, то к такой комбинации элементов следует применять требования стойкости к систематическим отказам, представленные в ГОСТ 34332.3-2021 (пункт 8.3.3).

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

Пример — В управлении скоростью наполнения емкости жидкостью функция безопасности предотвращения нежелательного ускорения наполнения полностью реализуется на двух процессорах. Функция безопасности элемента, реализуемая основным контроллером, управляет клапаном подачи воды в режиме запрос/ответ. Функция безопасности элемента, реализуемая другим процессором, выполняет разного рода контроль [см. ГОСТ 34332.5-2021 (приложение В, пункт В.3.4)] и аварийный останов подачи жидкости в случае необходимости во избежание переполнения емкости. Применение комбинации этих двух процессоров способствует тому, что выполнение в полном объеме функции безопасности «предотвращение нежелательного ускорения подачи жидкости» будет обеспечено.

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

• требованиям одного из следующих способов обеспечения соответствия:
• способ 1с: разработка, отвечающая установленным требованиям, а именно требованиям настоящего стандарта для предотвращения и управления систематическими отказами в ПО;
• способ 2с: проверка при эксплуатации данного элемента. Необходимо предоставить свидетельства относительно проверки элемента при его эксплуатации [см. ГОСТ 34332.3-2021 (пункт 8.3.14)];
• способ 3с: оценка разработки, соответствующей требованиям. Должно быть документально подтверждено соблюдение требований 7.4.2.13.

Примечания

1 Способы 1с, 2с и 3с соответствуют способам, описанным в ГОСТ 34332.3-2021 (пункт 8.3.2.3) для элементов ПО. Они приведены в настоящем пункте исключительно для того, чтобы минимизировать обращение к ГОСТ 34332.3.

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

3 Требования к действующим элементам ПО применяют также к библиотеке времени выполнения операций или интерпретатору;

• должно быть представлено руководство по безопасности [см. ГОСТ 34332.3-2021 (приложение Г) и приложение Г], которое дает достаточно точное и полное описание элемента для обеспечения оценки полноты конкретной функции безопасности, полностью или частично зависящей от действующего элемента ПО.

Примечания

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

2 Обоснование элемента ПО может быть разработано при планировании безопасности (см. раздел 6).

7.4.2.13 Согласно способу 3с существующий ранее элемент ПО должен соответствовать следующим требованиям:

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

б) в обоснование для использования элемента ПО должны быть включены свидетельства о том, что были рассмотрены требуемые свойства системы безопасности, определенные в 7.2.2, 7.4.3 - 7.4.7, 7.5.2, 7.7.2, 7.8.2, 7.9.2 и разделе 8 с учетом требований приложения В;

в) в документально оформленном проекте элемента должны быть подробно представлены свидетельства соответствия спецификации требований и требуемой стойкости к систематическим отказам (см. 7.4.3, 7.4.5, 7.4.6 и таблицы А.2 и А.4 приложения А);

г) при соблюдении требований по перечислениям а), б) должна быть учтена интеграция ПО и АС (см. 7.5 и таблицу А.6 приложения А);

д) должно быть представлено доказательство того, что для элемента ПО выполнены процедуры проверки и подтверждения соответствия с использованием систематического подхода с документально оформленным тестированием и анализом всех частей проекта элемента и кода (см. 7.4.7, 7.4, 7.5, 7.7, 7.9 и таблицы А.5 - А.7 и А.9 приложения А, а также связанные с ними таблицы приложения Б).

Примечание — Для удовлетворения требованиям тестирования может быть использован положительный опыт применения вероятностных методов и метода «черного ящика» (см. таблицы А.7 приложения А и Б.3 приложения Б);

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

Примечание — Способы, соответствующие данному требованию, включают в себя:

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

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

Примечание - Соответствующие меры ослабления включают в себя:

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

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

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

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

Примечание — Руководящие указания по системам, управляемым данными, приведены в приложении Ж;

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

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

Примечания

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

2 В некоторых отраслях промышленности архитектура ПО может называться «описание функций или спецификация функций проекта» (хотя эти документы могут также включать в себя вопросы, относящиеся к АС).

3 В некоторых случаях пользовательского прикладного программирования, в частности в языках, используемых в ПЛК, архитектура определяется поставщиком как стандартная характеристика ПЛК. Однако в соответствии с требованиями настоящего стандарта к поставщику может быть предъявлено требование гарантировать пользователю соответствие поставляемого продукта требованиям 7.4. Пользователь приспосабливает ПЛК, используя стандартные возможности программирования, например многозвенные логические схемы. При этом требования 7.4.3 - 7.4.8 также действуют. Требование определения и документирования архитектуры следует рассматривать как требование к той информации, которую пользователь может использовать при выборе ПЛК (или эквивалентного ему устройства) для применения.

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

5 Хотя стандарты комплекса ГОСТ 34332 устанавливают численные целевые показатели отказов для функций безопасности, выполняемых Э/Э/ПЭ СБЗС системами, систематическая полнота безопасности, как правило, не определяется количественно. Полноту безопасности ПО определяют как стойкость к систематическим отказам со шкалой уверенности от 1 до 4. Для целей настоящего стандарта принято, что программная ошибка может быть безопасной или опасной в зависимости от специфики использования ПО. Архитектура системы/ПО должна быть выбрана такой, чтобы опасные отказы элемента были ограничены каким-либо архитектурным ограничением, а в выбранных методах разработки эти ограничения были учтены. Согласно требованиям настоящего стандарта методы разработки и подтверждения соответствия жестко регламентированы, что согласовано с требуемой стойкостью к систематическим отказам.

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

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

7.4.3.1 В зависимости от характера разработки ПО ответственность за соответствие требованиям 7.4.4 могут нести несколько сторон. Распределение ответственности должно быть документально оформлено во время планирования СБЗС системы [см. ГОСТ 34332.2-2017 (раздел 6)].

7.4.3.2 Проект архитектуры ПО должен быть создан поставщиком ПО и/или разработчиком ПО. Описание архитектуры должно быть подробным и соответствовать следующим требованиям:

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

а) проводилась ли верификация и если проводилась, то при каких условиях,

б) связан ли каждый из этих компонентов/подсистем с безопасностью или не связан,

в) существует ли стойкость к систематическим отказам для компонента/подсистемы ПО;

• определять все взаимодействия между ПО и АС, а также оценивать и детализировать их значение.

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

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

7.4.3.3 Любые изменения, которые может потребоваться внести в спецификацию требований к ПЭ СБЗС системе (см. 7.4.3.2), должны быть согласованы с разработчиком ПЭ СБЗС системы и документально оформлены.

Примечание — Итерационное взаимодействие между архитектурой АС и ПО является неизбежным (см. рисунки 5 и 6), поэтому существует необходимость в обсуждении с разработчиком АС таких вопросов, как спецификация тестирования интеграции программируемой электроники и ПО (см. 7.5).

7.4.4 Требования к инструментальным средствам поддержки, включая языки программирования

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

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

7.4.4.1 ПО инструментальных средств поддержки, работающее в неавтономном режиме, должно быть рассмотрено как элемент ПО ПЭ СБЗС системы.

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

Примечания

1 Требования к ЖЦ СБ ПО приведены в 7.1.2.

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

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

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

4 Инструментальные средства поддержки, работающие в автономном режиме, должны быть выбраны как совместимые с потребностями применения ПЭ СБЗС системы и интегрированного комплекса инструментальных средств.

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

6 Необходимо уделить внимание компетентности пользователей выбранных инструментальных средств. Требования к их компетентности приведены в ГОСТ 34332.2-2017 (раздел 6).

7.4.4.3 Выбор инструментальных средств поддержки, работающих в автономном режиме, должен быть обоснован.

7.4.4.4 Все инструментальные средства поддержки классов Т2 и Т3, работающие в автономном режиме, должны сопровождаться спецификацией или документацией на выбранное средство, в которой четко определено поведение инструментального средства и представлены любые инструкции или ограничения при его использовании. Требования к ЖЦ разработки ПО приведены в 7.1.2, а для категорий ПО инструментальных средств поддержки, работающих в автономном режиме, - 7.4.4.2.

Примечание — Такая «спецификация или документация на инструментальное средство» не является руководством по безопасности применяемого элемента [см. ГОСТ 34332.3-2021 (приложение Г) и приложение Г] непосредственно для самого инструментального средства. Руководство по безопасности для применяемого элемента касается функционирующего элемента, который включен в исполняемую СБ систему. Если последний элемент сгенерирован инструментальным средством класса Т3 и затем включен в исполняемую СБ систему, то любая соответствующая информация (например, если в документации для оптимизирующего компилятора указано, что порядок оценки параметров функции не гарантируется) из спецификации или документации на инструментальное средство должна быть включена в руководство по безопасности для применяемого элемента, что позволяет провести оценку полноты конкретной функции безопасности, которая полностью или частично зависит от элемента, включенного в исполняемую СБ систему.

7.4.4.5 Для определения уровня доверия к инструментальным средствам и возможных механизмов отказа инструментальных средств, которые могут повлиять на применяемое ПО, должна быть выполнена оценка инструментальных средств классов Т2 и Т3 поддержки ПО в автономном режиме. Если механизмы отказа идентифицированы, то должны быть использованы соответствующие меры по их ослаблению.

Примечания

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

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

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

Примечания

1 Знание предыстории использования может способствовать подтверждению с высокой степенью доверия относительно готовности инструментального средства к работе. При этом также должны быть учтены записи ошибок/несоответствий, когда инструментальное средство используют для разработки в новой среде.

2 Свидетельство для инструментального средства класса Т3 может быть применено также к инструментальным средствам класса Т2 для оценки правильности их результатов.

7.4.4.7 Результаты подтверждения соответствия инструментальных средств должны быть документально оформлены и содержать:

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

7.4.4.8 Если свидетельство соответствия по 7.4.4.6 недоступно, то должны быть приняты эффективные меры для управления отказами рассматриваемой ПЭ СБЗС системы, которые являются следствием ошибок при работе инструментального средства.

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

7.4.4.9 Должна быть проверена совместимость инструментальных средств в интегрированном комплексе инструментальных средств.

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

7.4.4.10 В той степени, в которой этого требует УПБ, представление ПО или проекта (включая язык программирования) должно быть выбрано таким, чтобы оно:

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

Примечания

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

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

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

7.4.4.11 Если требования по 7.4.4.10 не могут быть выполнены в полном объеме, то необходимо обосновать пригодность языка для реализации данной цели, а также использовать все доступные дополнительные меры, направленные на устранение любых идентифицированных недостатков языка.

7.4.4.12 Языки программирования для разработки всего ПО ПЭ СБЗС системы следует использовать в соответствии со стандартами составления программ для таких языков.

Примечание — Руководящие указания по использованию стандартов кодирования для ПО ПЭ СБЗС системы приведены в ГОСТ 34332.5.

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

• юридическое лицо [например, компания, автор(ы) и т.д.];
• описание;
• входные и выходные данные;
• историю управления конфигурацией.

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

7.4.4.15 Если средства поддержки ПО в автономном режиме классов Т2 и Т3 генерируют элементы для базовой конфигурации, то управление конфигурацией должно быть таким, чтобы гарантировать, что информация об инструментальных средствах записана в базовой конфигурации. В частности, в состав информации о средствах поддержки ПО включают:

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

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

7.4.4.16 Управление конфигурацией должно быть осуществлено таким образом, чтобы гарантировать, что инструментальные средства в классах Т2 и Т3 использованы исключительно квалифицированным специалистом.

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

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

7.4.4.18 Каждая новая версия средства поддержки ПО в автономном режиме должна быть квалифицирована. Эта квалификация может опираться на доказательства, представленные для более ранней версии, при наличии достаточных доказательств того, что:

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

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

7.4.4.19 В зависимости от характера разработки ПО ответственность за соответствие требованиям 7.4.4 могут нести несколько сторон. Распределение ответственности должно быть документально оформлено во время планирования системы безопасности [см. ГОСТ 34332.2-2017 (раздел 6)].

7.4.5 Требования к детальному проектированию и разработке системы ПО

Примечания

1 Под детальным проектированием понимается разделение основных элементов архитектуры на систему программных модулей, проектирование отдельных программных модулей и их программирование. В небольших по объему приложениях проектирование программных систем и архитектуры может быть объединено.

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

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

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

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

7.4.5.1 В зависимости от характера разработки СБ ПО ответственность за соответствие требованиям 7.4.4 могут нести несколько сторон. Распределение ответственности должно быть документально оформлено во время планирования системы безопасности [см. ГОСТ 34332.2-2017 (раздел 6)].

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

7.4.5.3 СБ ПО следует разрабатывать таким образом, чтобы достигались модульность, тестируемость и способность к модификации СБЗС системы.

7.4.5.4 Дальнейшее уточнение характеристик проекта для КСБ, Э/Э/ПЭ СБЗС системы, каждого главного элемента/подсистемы в описании проекта архитектуры ПО должно быть основано на декомпозиции системы на программные модули (т.е. на спецификации проекта программной системы). Необходимо специфицировать проект каждого программного модуля и проверки этих модулей.

Примечания

1 Информация о действующих элементах ПО приведена в 7.4.2.

2 Верификация элементов ПО состоит из тестирования и анализа.

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

7.4.6 Требования к реализации исходных текстов программ

Примечание — В соответствии с необходимым УПБ исходный код должен обладать следующими свойствами (конкретные методы представлены в приложениях А и Б; руководящие указания по интерпретации свойств — в приложении В):

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

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

Примечание — Просмотр кода относится к процессам верификации (см. 7.9). Просмотр кода может быть выполнен с помощью следующего контроля кода (в порядке возрастания строгости): пользователем ПО; сквозным контролем ПО [см. ГОСТ 34332.5-2021 (пункт В.5.15 приложения В)] или формальной проверкой [см. ГОСТ 34332.5-2021 (пункт В.5.14 приложения В)].

7.4.7 Требования к тестированию программных модулей

Примечания

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

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

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

7.4.7.1 Каждый программный модуль должен быть проверен (протестирован) в соответствии со спецификацией, разработанной при проектировании ПО (см. 7.4.5).

Примечание - Верификация состоит из тестирования и анализа.

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

Примечания

1 Указанное выше не означает тестирования всех комбинаций входных и выходных данных. Достаточным может быть тестирование всех классов эквивалентности или структурное тестирование. Анализ граничных значений или потоков управления может сократить количество проверок до приемлемого уровня. Программы, используемые для анализа, могут способствовать достижению более эффективного выполнения требований. Перечисленные методы приведены в ГОСТ 34332.5-2021 (приложение В).

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

3 Хотя систематическая полнота безопасности обычно количественно не определяется, некоторые количественные статистические данные (например, статистическое тестирование, повышение надежности) являются приемлемыми, если удовлетворены все соответствующие условия для статистически достоверного доказательства [например, примеры в ГОСТ 34332.5-2021 (приложение Г)].

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

7.4.7.3 Результаты тестирования программных модулей должны быть документально оформлены.

7.4.7.4 Должны быть определены процедуры для коррекции при непрохождении теста.

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

Примечание — Проверка того, что интеграция СБ ПО является корректной, относится к процессам верификации (см. 7.9).

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

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

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

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

Примечания

1 Указанное выше не означает тестирования всех комбинаций входных и выходных данных. Достаточным может быть тестирование всех классов эквивалентности или структурное тестирование. Анализ граничных значений или потоков управления может сократить число проверок до приемлемого уровня. Программы, пригодные для анализа, могут помочь в достижении более быстрого выполнения требований. Перечисленные методы приведены в ГОСТ 34332.5-2021 (приложение В).

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

3 Хотя систематическая полнота безопасности обычно количественно не определяется, некоторые количественные статистические данные, например статистическое тестирование, повышение надежности, являются приемлемыми, если удовлетворены все соответствующие условия для статистически достоверного доказательства [например, см. ГОСТ 34332.5-2021 (приложение Г)].

7.4.8.4 Результаты проверки интеграции СБ ПО должны быть документально оформлены; в документации должны быть сформулированы результаты проверки и указано, были ли выполнены цели и критерии проверки. Если тестирование признано неудовлетворительным, должны быть определены причины этого.

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

7.5 Интеграция аппаратных средств и программного обеспечения

Примечания

1 Разработку интеграции АС и ПО осуществляют на стадиях разработки и проектирования (см. блоки 6 и 7 на рисунке 3).

2 Проверку корректности интеграции осуществляют на стадиях разработки и проектирования, а окончательную оценку и подтверждение соответствия — на стадии реализации (см. блок 13 на рисунке 3, а также см. рисунки 5 и 6).

7.5.1 Цели

7.5.1.1 Первой целью является обеспечение интеграции ПО с используемой ПЭ.

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

Примечания

1 Проверка корректности интеграции ПО с АС в Э/Э/ПЭ СБЗС систему относится к процессам верификации (см. 7.9).

2 В зависимости от характера применения эти проверки могут быть объединены с проверками по 7.4.8.

3 Окончательную оценку и подтверждение соответствия корректности интеграции ПО с АС в Э/Э/ПЭ СБЗС систему осуществляют на объекте (см. блок 13 на рисунке 3, а также см. рисунок 6). При этом оценку и подтверждение соответствия допускается проводить автономно и/или в составе КСБ (см. рисунок 5), в зависимости от сложности системы обеспечения безопасности объекта.

7.5.1.3 Третья цель заключается в обеспечении объединения Э/Э/ПЭ СБЗС в КСБ, проверки их совместимости и выполнении требований по защите объекта (здания или сооружения).

Примечания

1 Проверка корректности интеграции Э/Э/ПЭ СБЗС систем в Э/Э/ПЭ КСБ относится к процессам верификации (см. 7.9).

2 В зависимости от характера применения эти проверки могут быть объединены с проверками по 7.4.8.

3 Окончательную оценку и подтверждение соответствия корректности интеграции Э/Э/ПЭ СБЗС систем в КСБ осуществляют на объекте (см. блок 13 на рисунке 3, а также см. рисунок 5).

7.5.2 Требования

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

• полнота интеграции в соответствии со спецификациями проекта;
• корректность интеграции в соответствии со спецификациями проекта (удовлетворительное выполнение);
• воспроизводимость;
• точно определенная конфигурация интеграции.

7.5.2.1 Проверки интеграции должны быть определены на этапе проектирования и разработки (см. 7.4.3). Их целью является проверка совместимости ПО и АС в ПЭ, связанной с безопасностью.

Примечание - При разработке проверок интеграции может потребоваться тесная кооперация разработчика СБ ПО с разработчиком Э/Э/ПЭ СБЗС системы.

7.5.2.2 Спецификация тестов интеграции для программируемой электроники (ПО и АС в Э/Э/ПЭ СБЗС систему и Э/Э/ПЭ СБЗС систем в КСБ) должна быть выбрана такой, чтобы определять:

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

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

7.5.2.4 В тестах интеграции программируемой электроники (АС и ПО) различают следующие процессы;

а) включение АС и ПО в целевое ПЭ оборудование;

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

в) интеграцию УО и Э/Э/ПЭ СБЗС системы;

г) интеграцию Э/Э/ПЭ СБЗС систем в КСБ.

Примечание — Процессы по перечислениям б) - г) рассмотрены в ГОСТ 34332.2 и ГОСТ 34332.3.

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

7.5.2.6 При тестировании интеграции программируемой электроники, связанной с безопасностью (АС и ПО), все изменения в интегрированной системе должны стать объектом анализа влияния, по результатам которого должно быть определено, какие программные модули были изменены, и должна быть установлена необходимость проведения повторной верификации.

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

7.5.2.8 Результаты проверки интеграции программируемой электроники (АС и ПО) должны быть документально оформлены. В документации должны быть сформулированы результаты проверки, а также указано, были ли выполнены цели и критерии проверки. Если тестирование было неудовлетворительным, должны быть описаны причины произошедшего. Все модификации или изменения, являющиеся результатом тестирования, должны быть объектом анализа влияния, по результатам которого должно быть определено, какие программные элементы/модули были изменены, и должна быть установлена необходимость повторной верификации и проектирования.

7.6 Процедуры эксплуатации и модификации программного обеспечения

Примечание - В настоящем стандарте процедуры эксплуатации и модификации ПО не рассматриваются.

7.6.1 Цели

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

7.6.2 Требования

Требования приведены в ГОСТ 34332.3-2021 (пункт 8.7.1) и в 7.8.

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

7.7 Подтверждение соответствия программных аспектов безопасности СБЗС системы

Примечания

1 Данная стадия относится к стадии разработки и проектирования ПО и Э/Э/ПЭ СБЗС систем (см. блоки 6 и 7 на рисунке 3).

2 Как правило, подтверждение соответствия ПО не может быть проведено отдельно от его АС и системного окружения.

7.7.1 Цели

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

7.7.2 Требования

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

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

7.7.2.1 Если для СБ ПО соответствие с требованиями установлено при планировании подтверждения соответствия для Э/Э/ПЭ СБЗС системы [см. ГОСТ 34332.5-2021 (подраздел 8.6)], то проводить повторное подтверждение соответствия не требуется.

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

7.7.2.3 В зависимости от характера разработки ПО ответственность за соответствие требованиям подраздела 7.7 могут нести несколько сторон. Распределение ответственности должно быть документально оформлено во время планирования безопасности системы [см. ГОСТ 34332.2-2017 (раздел 6)].

7.7.2.4 Результаты подтверждения соответствия программных аспектов безопасности Э/Э/ПЭ СБЗС системы должны быть документально оформлены.

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

• хронологический перечень операций подтверждения соответствия, который позволит восстановить последовательность действий.

Примечание - При записи результатов испытаний важно, чтобы последовательность действий могла быть восстановлена. Главное в этом требовании — восстановить последовательность действий, а не создать упорядоченный по времени/дате список документов;

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

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

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

7.7.2.7 При подтверждении соответствия программных аспектов безопасности Э/Э/ПЭ СБЗС системы необходимо выполнять следующие требования:

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

7.7.2.8 Инструментальные средства ПО следует выбирать в соответствии с 7.4.4.

7.7.2.9 К результатам подтверждения соответствия программных аспектов безопасности Э/Э/ПЭ СБЗС системы предъявляют следующие требования:

• проверки должны показать, что все заданные требования, предъявляемые к СБ ПО (см. подраздел 7.2), выполняются правильно и что программная система не выполняет непредусмотренных функций;
• тестовые примеры и их результаты должны быть документально оформлены для последующего анализа и независимой оценки соответствия согласно требованиям УПБ [см. ГОСТ 34332.2-2017 (раздел 8)];
• в документально оформленные результаты подтверждения соответствия программных аспектов безопасности Э/Э/ПЭ СБЗС системы должны быть включены либо утверждение о том, что программа получила подтверждение соответствия, либо причины, по которым она его не получила.

7.8 Модификация программного обеспечения

7.8.1 Цель

Целью требований настоящего подраздела является внесение корректировок, усовершенствований или изменений в принятое ПО, гарантирующих сохранение стойкости к систематическим отказам ПО.

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

7.8.2 Требования

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

• полнота модификации в соответствии с установленными требованиями;
• корректность модификации согласно требованиям к ней;
• отсутствие ошибок в проекте;
• предотвращение нежелательного поведения ПО;
• верифицируемость и тестируемость проекта;
• регрессионное тестирование и проведение проверок.

7.8.2.1 Перед выполнением какой-либо модификации ПО должны быть подготовлены процедуры модификации [см. ГОСТ 34332.2-2017 (подраздел 7.17)].

Примечание — Требования, перечисленные в 7.8.2.1 - 7.8.2.9, относятся в первую очередь к изменениям, выполняемым на стадии эксплуатации ПО. Требования по 7.8.2.1 - 7.8.2.9 также могут быть применены на стадии интеграции программируемой электроники, а также на стадиях установки и ввода в эксплуатацию всей системы безопасности [см. ГОСТ 34332.2-2017 (подраздел 7.12)].

7.8.2.2 Процесс модификации может быть начат только после появления запроса на санкционированную модификацию ПО в рамках процедур, определенных на этапе планирования системы без опасности (см. раздел 6), в котором приведена подробная информация:

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

• о предлагаемых изменениях;
• причинах изменений.

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

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

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

• необходимости анализа рисков;
• какие именно этапы ЖЦ ПО Э/Э/ПЭ СБЗС системы следует повторить.

7.8.2.4 Результаты анализа влияния, полученные в соответствии с 7.8.2.3, должны быть документально оформлены.

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

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

7.8.2.6 Планирование системы безопасности для модификации СБ ПО выполняют в соответствии с требованиями, представленными в ГОСТ 34332.2-2017 (раздел 6), в частности с требованиями:

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

Примечание - В зависимости от характера применения может оказаться необходимым участие экспертов в области данного применения.

7.8.2.7 Модификация должна быть проведена в соответствии с разработанным планом.

7.8.2.8 Все модификации должны быть подробно задокументированы, включая:

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

7.8.2.9 Информация о деталях всех проведенных модификаций должна быть документально оформлена. В документацию включают данные и результаты повторной верификации и повторного подтверждения соответствия.

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

7.9 Верификация программного обеспечения

7.9.1 Цель

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

Примечания

1 Настоящий подраздел учитывает базовые аспекты верификации, которые являются общими для нескольких стадий ЖЦ системы безопасности. Настоящий подраздел не предъявляет дополнительных требований к элементам проверки при верификации в 7.4.7 (проверка программных модулей), 7.4.8 (интеграция ПО) и подразделе 7.5 (интеграция программируемой электроники), которые представляют собой процессы верификации. Данный подраздел не требует также дополнительной верификации для процессов подтверждения соответствия ПО (см. подраздел 7.7), так как подтверждение соответствия в настоящем стандарте определено как демонстрация соответствия спецификации требований к системе безопасности. Проверку того, является ли корректной спецификация, проводят специалисты по предметным областям.

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

7.9.2 Требования

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

• полнота верификации в соответствии с предыдущей стадией;
• корректность верификации в соответствии с предыдущей стадией (удовлетворительное выполнение);
• воспроизводимость;
• верификация точно определенной конфигурации.

7.9.2.1 Верификацию ПО для каждой стадии ЖЦ ПО Э/Э/ПЭ СБЗС системы следует планировать (см. подраздел 7.4) одновременно с разработкой; вся информация, относящаяся к этому вопросу, должна быть документально оформлена.

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

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

7.9.2.3 Верификация ПО должна быть проведена в соответствии с планом.

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

• размер проекта;
• степень сложности;
• степень новизны проекта;
• степень новизны технологии.

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

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

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

а также перечень несоответствий.

Примечание - Например, несоответствия возможны в программных модулях, структурах данных и алгоритмах, неудовлетворительно адаптированных к поставленной задаче.

7.9.2.6 Вся существенная информация, относящаяся к стадии № ЖЦ ПО системы безопасности, необходимая для правильного выполнения следующей стадии N + 1, должна быть доступна и верифицирована. К выходной информации стадии № относятся:

а) информация об адекватности спецификации, описания проекта либо исходного текста про грамм, разработанных в процессе стадии N:

1. функциональность,

2. полнота безопасности, характеристики и другие требования к планированию системы безопасности (см. раздел 6),

3. требования понятности для коллектива разработчиков,

4. тестируемость для дальнейшей верификации,

5. безопасность модификации, допускающей дальнейшее развитие;

б) информация об адекватности планирования подтверждения соответствия и/или тестов, установленных для стадии N, определению и описанию проекта стадии N;

в) результаты проверки несовместимости между:

1. тестами, определенными для стадии N, и тестами для предыдущей стадии N — 1,

2. выходными данными стадии N.

7.9.2.7 В соответствии с выбором ЖЦ разработки ПО (см. подраздел 7.1) должна быть выполнена верификация:

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

б) архитектуры ПО;

в) проекта системы ПО;

г) проектов программных модулей;

д) исходных текстов программ;

е) данных:

1. тестирование программных модулей (см. 7.4 7),

2. тестирование интеграции ПО (см. 7.4.8),

3. тестирование интеграции программируемой электроники (см. подраздел 7.5),

4. подтверждение соответствия аспектов ПО системы безопасности (см. подраздел 7.7).

Примечание — Требования по перечислениям а) - д) представлены ниже.

7.9.2.8 При верификации требований к ПО системы безопасности (после определения требований к ПО системы безопасности и перед началом следующей стадии проектирования и разработки ПО) следует проверить:

а) соответствие спецификации требований к ПО системы безопасности относительно спецификации требований к Э/ЭУПЭ СБЗС системе [см. ГОСТ 34332.3-2017 (подраздел 8.2)] в отношении функциональности, полноты безопасности, характеристик и других требований к планированию системы безопасности;

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

в) наличие несовместимости между:

1. спецификацией требований к безопасности ПО и спецификацией требований к безопасности Э/Э/ПЭ СБЗС системы [см. ГОСТ 34332.3-2017 (подраздел 8.2)];

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

7.9.2.9 При верификации архитектуры ПО (после того, как выполнен проект архитектуры ПО) следует проверить:

а) соответствие проекта архитектуры ПО спецификации требований к безопасности ПО;

б) адекватность проверок интеграции, установленных в проекте архитектуры ПО;

в) адекватность атрибутов каждого основного элемента/подсистемы по отношению:

1. к реализуемости требуемых характеристик безопасности,

2. возможности проверки при последующей верификации,

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

4. безопасной модификации при дальнейшем развитии ПО;

г) наличие несовместимости между:

1. описанием проекта архитектуры ПО и спецификацией требований к ПО,

2. описанием проекта архитектуры ПО и тестами интеграции архитектуры ПО,

3. тестами интеграции проекта архитектуры ПО и планом подтверждения соответствия программных аспектов безопасности Э/Э/ПЭ СБЗС системы.

7.9.2.10 При верификации проекта системы ПО (после завершения проектирования системы ПО) следует проверить:

а) соответствие проекта системы ПО (см. 7.4.5) проекту архитектуры ПО;

б) соответствие тестов интеграции системы ПО (см. 7.4.5) проекту системы ПО (см. 7.4.5);

в) адекватность спецификации атрибутов каждого основного элемента проекта системы ПО (см. 7.4.5) по отношению:

1) к реализуемости требуемых характеристик системы безопасности,

2. возможности проверки при последующей верификации,

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

4. модификации системы безопасности, позволяющей выполнять дальнейшее развитие программы.

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

а) соответствие спецификации проекта программного модуля (см. 7.4.5) относительно спецификации проекта системы ПО (см. 7.4.5);

б) адекватность спецификации проверок каждого программного модуля (см. 7.4.5) относительно спецификации проекта программного модуля (см. 7.4.5);

в) адекватность атрибутов каждого программного модуля по отношению:

1. к реализуемости требуемых характеристик системы безопасности (см. спецификацию требований к ПО системы безопасности),

2. возможности проверки при последующей верификации,

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

4. модификации системы безопасности, позволяющей выполнять дальнейшее развитие программы;

г) наличие несовместимости между:

1. спецификацией проекта программного модуля (см. 7.4.5) и спецификацией проекта системы ПО (см. 7.4.5),

2. спецификацией проекта каждого программного модуля (см. 7.4.5) и спецификацией проверок этого программного модуля (см. 7.4.5),

3. спецификацией проверок программных модулей (см. 7.4.5) и спецификацией проверок интеграции системы ПО (см. 7.4.5).

7.9.2.12 В процессе верификации исходный текст должен пройти проверку статическими методами для того, чтобы гарантировать соответствие спецификации проекта программных модулей (см. 7.4.5) необходимым стандартам кодирования (см. 7.4.4) и плану подтверждения соответствия аспектов ПО безопасности Э/Э/ПЭ СБЗС системы.

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

7.9.2.13 При верификации данных должны быть проверены:

а) структуры данных;

б) прикладные данные:

1. на соответствие структурам данных,

2. полноту в отношении требований применения,

3. совместимость с системным ПО (например, для организации последовательности, управления во время выполнения и др.),

4. правильность значений данных;

в) все эксплуатационные параметры по отношению к требованиям применения;

г) все промышленные интерфейсы и соответствующее ПО [датчики и исполнительные устройства, а также автономные интерфейсы (см. 7.2.2.12)]:

1. на выявление предполагаемых отказов интерфейса,

2. устойчивость по отношению к предполагаемым отказам интерфейса;

д) все коммуникационные интерфейсы и соответствующее ПО на наличие адекватного уровня:

1. обнаружения ошибок,

2. защиты от повреждения,

3. подтверждения соответствия данных.

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

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

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

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

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

8.1 Цели и требования к оценке функциональной безопасности СБ ПО — по ГОСТ 34332.2-2017 (раздел 8).

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

8.3 При оценке функциональной безопасности могут быть использованы результаты процессов, приведенных в таблице А.10 приложения А.

Примечание — Выбор методов, приведенных в приложениях А и Б, не гарантирует, что будет достигнута необходимая полнота безопасности (см. 7.1.2.7). Лицо, проводящее оценку функциональной безопасности, должно также рассмотреть и оценить:

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

Приложение А (обязательное)

РУКОВОДСТВО ПО ВЫБОРУ МЕТОДОВ И СРЕДСТВ

Некоторые из подразделов настоящего стандарта имеют ассоциированные с ними таблицы, например: подраздел 7.2 (спецификация требований к ПО системы безопасности) соотносится с данными таблицы А.1. Более подробные таблицы, содержащиеся в приложении Б, раскрывают содержание некоторых элементов таблиц приложения А (в частности, таблица Б.2 детализирует содержание динамического анализа и тестирования на основе таблицы А.5).

Обзор методов и средств, упоминаемых в приложениях А и Б, приведен в ГОСТ 34332.5. Для каждого из них представлены рекомендации по УПБ, изменяющемуся от 1 до 4, которые обозначены следующим образом:

ОР — метод или средство, особо рекомендованный(ое) к применению для данного УПБ. Если метод или средство не используют, то на стадии (этапе) планирования СБ системы этому должно быть дано подробное объяснение со ссылкой на приложение В, и это объяснение должно быть согласовано с техническим экспертом;

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

«- -» — для данного метода или средства отсутствует рекомендация относительно его применения;

НР — метод или средство, не рекомендованный(ое) к применению для данного УПБ. Если метод или средство применяют, то на стадии (этапе) планирования системы безопасности этому должно быть дано подробное обоснование со ссылкой на приложение В, которое следует согласовать с техническим экспертом.

Методы и средства следует выбирать в соответствии с установленным УПБ. Альтернативные или эквивалентные методы и средства обозначают буквой, следующей за номером. Следует применять только один(но) из альтернативных или эквивалентных методов и средств.

Примечание — Данный подход действует в отношении методов/средств, приведенных в таблицах А.1 - А.4.

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

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

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

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

Таблица А.1

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

Проектирование и разработка программного обеспечения. Проектирование архитектуры ПО (см. 7.4.3)

1 Анализ влияния

В.5.23

ОР

ОР

ОР

3 Повторная верификация программных модулей, на которые оказывают влияние изменения в других модулях

6 Регистрация и анализ данных

В.5.2

ОР

ОР

ОР

ОР

7 Прямая прослеживаемость между спецификацией требований к ПО Э/Э/ПЭ СБЗС системы и планом модификации ПО (включая повторные верификацию и подтверждение соответствия)

В.2.11

ОР

8 Обратная прослеживаемость между планом модификации ПО (включая повторную верификацию и подтверждение соответствия) и спецификацией требований к ПО Э/Э/ПЭ СБЗС системы

ОР

ОР

<*> Выбор альтернативных методов/средств должен быть обоснован в соответствии со свойствами, приведенными в приложении В, предпочтительно для каждого применения. Альтернативные или эквивалентные методы/средства обозначаются буквами, следующими за номером. Следует применять только один (одно) из альтернативных или эквивалентных методов/средств.

УПБ 1

Р

Р

2 Таблицы решений (таблицы истинности)

Р

Р

6 Прямая прослеживаемость между требованиями раздела 6 и планом оценки функциональной безопасности ПО

В.2.11

Р

Р

ОР

ОР

<*> Соответствующие методы/средства следует выбирать в соответствии с УПБ.

Примечание — См. таблицу В.9 приложения В.

ПОДРОБНЫЕ ТАБЛИЦЫ

Стандарты для проектирования и кодирования (см. таблицу А.4 приложения А)

Таблица Б.2

(см. таблицы А.5 и А.9 приложения А)

Таблица Б.3

ОР

ОР

Р

ОР

<*> Методы/средства следует выбирать в соответствии с УПБ. Альтернативные или эквивалентные методы/средства обозначают буквами, следующими за номером. Следует выполнять только один (одно) из альтернативных или эквивалентных методов/средств. Выбор альтернативных методов/средств должен быть обоснован свойствами, приведенными в приложении В, предпочтительно для каждого применения.

Примечания

1 Если конкретный метод не перечислен в таблице, не следует считать, что он исключен из рассмотрения. Такой метод должен соответствовать требованиям настоящего стандарта.

2 Количественное значение вероятностей не требуется.

3 См. таблицу В.14 приложения В.

4 Ссылки (являющиеся справочными, а не обязательными) во второй графе таблицы указывают на подробные описания методов/средств, изложенных в приложениях B и C [5].

Примечание — См. таблицу В.17 приложения В.

Примечание — См. таблицу В.18 приложения В.

Приложение В (справочное)

СВОЙСТВА СТОЙКОСТИ К СИСТЕМАТИЧЕСКИМ ОТКАЗАМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В.1 Введение

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

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

В.1.1 Структура приложения В, связанная с приложениями А и Б

Выходные данные каждой стадии ЖЦ СБ ПО определены в таблице А.1 приложения А. Например, рассмотрена спецификация требований к безопасности ПО.

В таблице А.1 приложения А рекомендованы конкретные методы разработки спецификации требований к СБ ПО:

В.1.2 Свойства

В таблице В.1 также ранжированы неформальные шкалы эффективности R1/R2/R3 конкретных методов для достижения вышеперечисленных свойств.

По методу/средству 1а «Полуформальные методы» учитывают свойства следующим образом:

• В.1.2.1 - R1 «Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области»;
• В.1.2.2 - R1 «Дружественный или зависящий от предметной области метод спецификации и нотация, используемые специалистами в проблемной области»; R2 «Верификация спецификации согласно критериям охвата»;
• В.1.2.3 - R1 «Метод и нотация, которые помогают предотвратить или обнаружить внутреннюю несогласованность, неверное поведение или математически несовместимые выражения»; R2 «Проверка спецификации согласно критериям охвата»; R3 «Проверка спецификации, основанная на систематическом анализе и/или систематическом предотвращении определенных типов отказов внутри спецификации»;
• В.1.2.4 - R1 «Определяемая нотация, ограничивающая возможность для непонимания»; R2 «Применение пределов сложности в спецификации»;
• В.1.2.5 - «- -»;
• В.1.2.6 - R1 «Определяемая нотация, снижающая неоднозначность в спецификации».

При ранжировании по шкалам R1 — R3, а также по методу «- -» учитывают следующие свойства:

R1 — без объективных критериев приемки или с ограниченными объективными критериями приемки, например: тестирование методом «черного ящика», основанное на профессиональном суждении; полевые испытания;

R2 — с объективными критериями приемки, гарантирующими с высокой долей вероятности, что необходимое свойство достигнуто (исключения должны быть определены и обоснованы), например: тест или аналитические методы с метриками охвата, охват таблицами контрольных проверок;

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

Для каждого метода, обеспечивающего конкретное свойство, определяют одно из ранжированных значений R1/R2/R3 в зависимости от уровня строгости этого метода.

Пример - Метод 1а «Полуформальные методы» определяют по шкалам R1 «Определяемая нотация, ограничивающая возможность для непонимания»; R2 «Применение пределов сложности в спецификации».

В.2 Свойства для систематической полноты безопасности

Подробные свойства. Анализ отказов (см. таблицу В.4)