Приложение В (справочное). Методы и средства достижения полноты безопасности программного обеспечения

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

Методы и средства достижения полноты безопасности программного обеспечения

В.1 Общие положения

В настоящем приложении приведено краткое описание методов и средств достижения полноты безопасности ПО Э/Э/ПЭ СБЗС систем, на которые даны ссылки в ГОСТ 34332.4, дан их анализ, а также приведены ссылки на источники с подробным описанием данных методов и средств. Настоящее приложение не должно рассматриваться как полное или исчерпывающее.

В.2 Требования и детальное проектирование

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

Примечание - Соответствующие методы и средства приведены в Б.2 приложения Б.

В.2.1 Структурные методы

Цель - формулирование методов/средств, применительно к структурным методам.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблицы А.2 и А.4).

В.2.1.1 Общие положения

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

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

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

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

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

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

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

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

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

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

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

Настоящий краткий обзор описывает несколько структурных методов более подробно.

Подробное описание данного метода/средства приведено в [56].

В.2.1.2 Управляемое представление требований (CORE)

Цель - обеспечение того, чтобы все требования были определены и выражены.

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

Подробное описание данного метода/средства приведено в [56], [85].

В.2.1.3 Метод разработки системы по Джексону (JSD)

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

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

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

Подробное описание данного метода/средства приведено в [86], [87].

В.2.1.4 Метод Йордона для систем реального времени

Цель - спецификация и проектирование систем реального времени.

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

Сущностная модель состоит из двух частей:

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

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

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

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

Подробное описание данного метода/средства приведено в [88].

В.2.2 Диаграммы потоков данных

Цель - программная поддержка описания потока данных в виде диаграмм.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.5 и Б.7).

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

Диаграммы потоков данных состоят из трех компонентов:

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

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

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

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

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

Подробное описание данного метода/средства приведено в ГОСТ 19.701, [59], [60], [89].

В.2.3 Структурные диаграммы

Цель - представление структуры программы в виде схемы.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.5).

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

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

- прямоугольника с именем модуля;

- линии, соединяющей эти прямоугольники, формирующие структуру;

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

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

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

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

Подробное описание данного метода/средства приведено в [59], [60], [90].

В.2.4 Формальные методы

Цель - формулирование методов/средств, применимых для формальных методов.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблицы А.1, А.2, А.4 и приложение Б, таблица Б.5).

В.2.4.1 Общие положения

Цель - разработка программных средств, основанных на математических принципах. К этим средствам относятся методы формального проектирования и формального кодирования.

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

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

Ряд формальных методов CCS, CSP, HOL, LOTOS, OBJ, временная логика, VDM и Z описан в настоящего пункте. Другие методы, например, метод конечных автоматов и сети Петри (см. приложение В), в зависимости от корректности использования методами соответствующего математического аппарата, могут рассматриваться как формальные.

Подробное описание данного метода/средства приведено в [91]-[93].

В.2.4.2 Расчет взаимодействующих систем - CCS

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

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

Подробное описание данного метода/средства приведено в [94].

В.2.4.3 Взаимодействующие последовательные процессы - CSP

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

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

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

Теоретические положения метода CSP были непосредственно включены в архитектуру транспьютера INMOS, а язык OCCAM позволил непосредственно реализовывать на сетях транспьютеров системы, специфицированные в языке CSP.

Подробное описание данного метода/средства приведено в [95].

В.2.4.4 Логика высшего порядка - HOL

Цель - спецификация и верификация аппаратных средств.

Описание. Логика высшего порядка (HOL) представляет собой конкретную логическую нотацию и систему, которая ее автоматически поддерживает. Логическая нотация взята в основном из простой теории типов Черча, а машинная реализация основана на теории логики вычислимых функций (LCF).

Подробное описание данного метода/средства приведено в [96].

В.2.4.5 Язык упорядоченных во времени процессов LOTOS

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

Описание. Язык для спецификации процессов, упорядоченных во времени (LOTOS), основан на CCS с дополнительными возможностями из близких алгебраических теорий CSP и CIRCAL (теория цепей). В языке LOTOS преодолены недостатки CCS в управлении структурами данных и представлении значений выражений благодаря объединению его с аспектами языка абстрактных типов данных ACT ONE. Процесс описания аспектов в LOTOS может быть также использован для других формальных методов при описании абстрактных типов данных.

Подробное описание данного метода/средства приведено в [97].

В.2.4.6 Язык спецификаций OBJ

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

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

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

Как и все другие методы ADT, метод OBJ применим только к последовательным системам или к последовательным аспектам параллельных систем. Метод OBJ применяют для спецификации как малых, так и крупных промышленных применений.

Подробное описание данного метода/средства приведено в [98].

В.2.4.7 Временная логика

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

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

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

Подробное описание данного метода/средства приведено в [99].

В.2.4.8 Программы реального времени VDM, VDM++ - метод разработки Vienna

Цель - систематическая спецификация и реализация последовательных (VDM) и параллельных (VDM++) программ реального времени.

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

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

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

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

Объектно-ориентированное и параллельное для реального времени расширение VDM - VDM++ представляет собой язык формализованных спецификаций, основанный на языке VDM-SL, созданном в ИСО, и на объектно-ориентированном языке Smalltalk.

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

К средствам описания реального времени на языке VDM++ относятся:

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

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

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

Подробное описание данного метода/средства приведено в [100], [101].

В.2.4.9 Язык Z

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

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

Описание. Как и в VDM, в реализованном языке Z спецификацию состояний системы моделируют в терминах теоретико-множественных структур, в которых описаны инварианты (с использованием предикат), а операции над этими состояниями моделируют посредством определения их пред- и постусловий в терминах системных состояний. Операции допускается проверять на сохранение системных инвариантов для демонстрации их согласованности. Формальная часть спецификации подразделяется на схемы, которые обеспечивают возможность структурирования спецификаций посредством их усовершенствования.

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

В отличие от VDM язык Z представляет собой скорее нотацию, чем завершенный метод. Был разработан близкий метод (метод В), который может быть использован в сочетании с языком Z. Метод В основан на принципе пошагового уточнения.

Подробное описание данного метода/средства приведено в [102], [103].

В.2.5 Программирование с защитой

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.4).

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

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

- проверка диапазона значений переменных;

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

- проверка типа, размерности и диапазона значений параметров процедур при вводе процедур.

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

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

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

- проверку на достоверность физических значений входных и промежуточных переменных;

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

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

Некоторые из методов защиты программ, например, проверки последовательности потока управления, также справляются и с внешними отказами.

Подробное описание данного метода/средства приведено в [56].

В.2.6 Стандарты по проектированию и кодированию

В.2.6.1 Общие положения

Цель - упрощение верификации для поддержания группового объективного подхода и установления стандартного метода проектирования.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.4).

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

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

Подробное описание данного метода/средства приведено в [49].

В.2.6.2 Стандарты кодирования

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.1).

Описание. Приведенные в таблице В.1 принципы указывают, как связанные с безопасностью правила кодирования (для любого языка программирования) могут помочь в выполнении нормативных требований ГОСТ 34332.4 и в достижении информативных "требуемых свойств" (см. приложение Ж). Необходимо уделить внимание доступным инструментам поддержки.

В.2.6.3 Отказ от динамических переменных или динамических объектов

Цель - исключение:

- нежелательных или необнаруживаемых наложений в памяти;

- узких мест ресурсов в процессе (связанном с безопасностью) выполнения программы.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблица А.2 и приложение Б, таблица Б.1).

Таблица В.1 - Требования и рекомендации ГОСТ 34332.4 и рекомендации стандартов кодирования

Требования и рекомендации ГОСТ 34332.4	Рекомендации стандартов кодирования
Модульный подход (таблица А.2, пункт 7, таблица А.4, пункт 4)	Ограничение размера программного модуля (таблица Б.9, пункт 1) и управление сложностью ПО (таблица Б.9, пункт 2). Примеры: - определение "локальных" метрик: размера, метрик сложности и предельных размеров (для модулей); - определение "глобальных" метрик сложности и предельных размеров (для всей структуры модулей); - ограниченное число параметров/фиксированное число параметров под программы (таблица Б.9, пункт 4). Ограничение доступа/инкапсуляция информации (таблица Б.9, пункт 3), например, стимулы для того, чтобы использовать определенные функции языка. Полностью определенный интерфейс (таблица Б.9, пункт 6). Примеры: - точная спецификация сигнатуры функции; - программирование с проверкой ошибок (таблица А.2, пункт 3а) и верификация данных (7.9.2.7) с явной спецификацией предварительных условий и постусловий для функций, утверждений, инвариантов типов данных
Понятность кода: - содействие понятности кода (7.4.4.13); - читаемый, понятный и тестируемый код (7.4.6)	Соглашения о присвоении имен, продвигающие значащие, однозначные имена, например, предотвращение имен, которые можно перепутать (например, IO и I0). Символьные имена для числовых значений. Процедуры и руководства для документирования исходного кода (7.4.4.13). Например, в них: - объяснить, почему и зачем (а не только что) кодируется; - описать предостережения; - описать побочные эффекты. Где это возможно, в исходный код следует включать следующую информацию (7.4.4.13): - данные о юридическом лице [например, компания, автор(ы) и т.д.]; - описание кода; - входные и выходные данные; - предысторию управления конфигурацией. (См. также модульный подход.)
Верифицируемость и тестируемость: - обеспечение верификации и тестирования (7.4.4); - способствовать обнаружению ошибок при проектировании или программировании (7.4.4.10); - формальная верификация (таблица А.5, пункт 9); - формальное доказательство (таблица А.9, пункт 1)	Для инструментальных средств поддержки следует контролировать: - обертки для "критических" библиотечных функций для проверки пред- и постусловий; - стимулы для использования функций языка, которые могут выразить ограничения на использование определенных элементов данных или функций (например, констант); - для инструментов, поддерживающих верификацию: правила выполнения ограничений для выбранных инструментов (если это не вредит более существенным целям); - ограниченное использование рекурсии (таблица Б.1, пункт 6) и других форм циклических зависимостей. (См. также модульный подход.)
Статическая верификация соответствия специфицированному проекту (7.9.2.12)	Методические рекомендации по кодированию для реализации специфицированных в проекте концепций или ограничений. Например: - методические рекомендации по кодированию циклов с гарантируемым максимальным значением времени цикла (таблица А.2, пункт 13а); - методические рекомендации по кодированию архитектуры с временным распределением (таблица А.2, пункт 13б); - методические рекомендации по кодированию архитектуры, управляемой событиями, с гарантируемым максимальным временем ответа (таблица А.2, пункт 13в); - применение циклов со статически определенным максимальным числом итераций (за исключением бесконечного цикла, предусмотренного в проекте); - методические рекомендации по кодированию статического распределения ресурсов (таблица А.2, пункт 14) и предотвращение динамических объектов (таблица В.1, пункт 2); - методические рекомендации по кодированию статической синхронизации доступа к совместно используемым ресурсам (таблица А.2, пункт 15); - методические рекомендации по кодированию с соблюдением ограничений на использование прерываний (таблица Б.1, пункт 4); - методические рекомендации по кодированию, не использующему динамические переменные (таблица Б.1, пункт 3а); - проверка установки динамических переменных в неавтономном режиме (таблица Б.1, пункт 3б); - методические рекомендации по кодированию, обеспечивающему совместимость с другими используемыми языками программирования (7.4.4.10); - методические рекомендации по прослеживаемости в проекте
Подмножество языков (таблица A.3, пункт 3): - запрет опасных функций языка (7.4.4.13); - использование только определенных функций языка (7.4.4.10); - структурное программирование (таблица А.4, пункт 6); - строго типизированный язык программирования (таблица A.3, пункт 2); - отсутствие автоматического преобразования типов (таблица В.1, пункт 8)	Исключение функций языка, приводящих к неструктурированным проектам. Например: - ограниченное использование указателей (таблица Б.1, пункт 5); - ограниченное использование рекурсии (таблица В.1, пункт 6); - ограниченное использование С-подобных объединений; - ограниченное использование Ada-подобных или С++-подобных исключений; - неиспользование неструктурированного потока управления в программах на языках более высокого уровня (таблица Б.1, пункт 7); - использование одной точки входа/одной точки выхода в подпрограммах и функциях (таблица Б.9, пункт 5); - неиспользование автоматического преобразования типов; - ограниченное использование побочных эффектов, не очевидных из сигнатур функций (например, статических переменных). Недопущение никаких побочных эффектов при оценке (вычислении) условий и во всех формах утверждений. Ограниченное или только документально оформленное использование специфичных для компилятора функций. Ограниченное использование конструкций языка, которые могут ввести в заблуждение. Использование правил, которые должны применяться при использовании этих функций языка
Хорошая практика программирования (7.4.4.13)	Когда это применимо: - методические рекомендации по кодированию, обеспечивающие, в случае необходимости, оценивание выражений с плавающей точкой (запятой) в правильном порядке (например, "a-b+с" не всегда равно "а+с-b"), - в сравнениях с плавающей точкой (запятой) - использование только неравенств (меньше чем, меньше или равно, больше чем, больше или равно) вместо строгого равенства; - методические рекомендации, относящиеся к условной компиляции и "препроцессорной обработке"; - систематическая проверка условий возврата (успех/отказ). Документирование и по возможности автоматизация создания исполняемого кода (make-файлы). Предотвращение побочных эффектов, не очевидных из сигнатур функций. Когда такие побочные эффекты существуют, в соответствии с методическими рекомендациями их необходимо документально оформить. Заключение в скобки, когда приоритет операторов не абсолютно очевиден. Поиск и локализация предположительно невозможных ситуаций (например, ситуация "по умолчанию" в "переключателях" языка С). Использование "оберток" для критических модулей, в частности, для проверки пред- и постсостояний и состояний возврата. Соблюдение методических рекомендаций по кодированию в условиях известных ошибок компилятора и в пределах, установленных оценкой компилятора

Описание. В случае применения этого метода динамические переменные и динамические объекты получают устанавливаемые во время выполнения программы определенные и абсолютные адреса в памяти. Объем (размер) распределяемой памяти и ее адреса зависят от состояния системы в момент распределения памяти и не могут быть проверены компилятором или другим автономным инструментом.

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

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

В.2.6.4 Проверка создания динамических переменных или динамических объектов при выполнении программы

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.1).

Описание. В случае применения этих средств к динамическим переменным относят те переменные, которые имеют свои конкретные и абсолютные адреса в памяти, устанавливаемые во время выполнения программы (в этом смысле динамические переменные являются также атрибутами объектов).

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

Примечание - Альтернативным методом является демонстрация статического распределения памяти.

В.2.6.5 Ограниченное использование прерываний

Цель - сохранение верифицируемости и тестируемости ПО.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.1).

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

В.2.6.6 Ограниченное использование указателей

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.1).

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

В.2.6.7 Ограниченное использование рекурсий

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.1).

Описание. Если используют рекурсию, то должен быть определен четкий критерий, который делает глубину рекурсии предсказуемой.

В.2.7 Структурное программирование

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.4).

Описание. Для минимизации структурной сложности программы следует применять следующие принципы:

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

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

- обеспечивать небольшое число возможных путей через программные модули и возможно более простые отношения между входными и выходными параметрами;

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

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

- исключать использование сложных вычислений в ветвлении и цикле.

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

Подробное описание данного метода/средства приведено в [104]-[106].

В.2.8 Ограничение доступа/инкапсуляция информации

Цель - предотвращение непреднамеренного доступа к данным или процедурам и обеспечение тем самым качественной структуры ПО.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.9).

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

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

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

Подробное описание данного метода/средства приведено в [104], [105].

В.2.9 Модульный подход

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблица А.4 и приложение Б, таблица Б.9).

Описание. Модульный подход, или модуляризация, включает в себя несколько различных правил для этапов ЖЦ проекта ПО (проектирования, кодирования и эксплуатации). Эти правила могут быть различными в зависимости от реализуемых методов проектирования. Большинство методов подчиняются следующим правилам:

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

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

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

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

- подпрограммы должны быть выполнены только с одним входом и одним выходом;

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

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

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

Подробное описание данного метода/средства приведено в [58], [105].

В.2.10 Использование доверительных/проверенных элементов программного обеспечения

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблицы А.2, А.4 и приложение В, таблицы В.2, В.4).

Описание. Данный метод позволяет проверить наличие в программных компонентах систематических ошибок проектирования и/или эксплуатационных отказов.

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

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

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

Существуют два подхода, как обрести уверенность в том, что поведение уже существующих модулей точно известно:

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

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

В.2.10.1 Проверка в эксплуатации

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

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

- спецификация не менялась;

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

- продолжительность срока его эксплуатации не менее года;

- продолжительность эксплуатации соответствует УПБ или соответствующему числу запросов; для демонстрации частоты отказов, не связанных с безопасностью, менее чем:

- 10 ^-2 на один запрос (в год) с 95 %-ным уровнем доверия [необходимо 300 эксплуатационных прохождений (в год)];

- 10 ^-5 на один запрос (в год) с 95 %-ным уровнем доверия [необходимо 690000 эксплуатационных прохождений (в год)].

Примечание - Математический аппарат, обеспечивающий числовые оценки данного метода, приведен в приложении Г. Аналогичный метод и статистический подход изложены также в Б.5.4;

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

- его отказы не связаны с безопасностью.

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

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

- точная идентификация о каждой системе и ее элементах, включая номера версий (как для программных, так и для аппаратных средств);

- идентификация пользователей и продолжительность их работы;

- продолжительность эксплуатации системы;

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

- процедуры обнаружения и регистрации отказов и устранения сбоев.

В.2.10.2 Оценка совокупности доказательств подтверждения соответствия

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

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

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

Настоящий стандарт предъявляет особые требования к содержанию руководства по безопасности для применяемых изделий, см. ГОСТ 34332.3-2021 (приложение Г) и ГОСТ 34332.4-2021 (подпункты 7.4.2.12 и 7.4.2.13).

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

- проект модуля известен и документирован;

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

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

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

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

Подробное описание данного метода/средства приведено в [107]-[109].

В.2.11 Прослеживаемость

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

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

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

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

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

- от спецификации требований безопасности ПО к разработке ПО;

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

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

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

- от спецификации проекта ПО к плану верификации ПО (включая верификацию данных);

- от требований ГОСТ 34332.4-2021 (раздел 8), к плану оценки функциональной безопасности ПО.

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

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

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

- от детального проекта ПО к архитектуре ПО;

- от программного кода к детальному проекту ПО;

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

- от плана модификации ПО к требованиям безопасности ПО;

- от плана верификации ПО (включая верификацию данных) к спецификации проекта ПО.

Подробное описание данного метода/средства приведено в [85].

В.2.12 Проектирование программного обеспечения без сохранения состояния (или с ограниченными состояниями)

Цель - ограничить сложность поведения ПО.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

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

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

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

Подробное описание данного метода/средства приведено в [110].

В.2.13 Численный анализ в автономном режиме

Цель - гарантировать точность числовых вычислений.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.9).

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

Подробное описание данного метода/средства приведено в [111].

В.2.14 Диаграммы последовательности сообщений

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблица Б.7 и приложение В, таблица В.17).

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

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

Подробное описание данного метода/средства приведено в [112], [113].

В.3 Архитектурное проектирование

В.3.1 Обнаружение и диагностика сбоев

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

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

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

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

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

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

В.3.2 Коды обнаружения и исправления ошибок

Цель - обнаружение и исправление ошибок в чувствительной к ним информации.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

Описание. Для информации, состоящей из n битов, генерируется закодированный блок из k битов, который позволяет обнаруживать и исправлять r ошибок. Примерами могут служить код Хэмминга и полиномиальные коды.

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

Подробное описание данного метода/средства приведено в [114].

В.3.3 Программирование с проверкой ошибок

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.3-2021 (приложение А, таблица А.17) и в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

Пример -

assert < pre-condition>;

action 1;

...

action x;

assert < post-condition>;

Подробное описание данного метода/средства приведено в [115].

В.3.4 Методы контроля

Цель - защита от ошибок в ПО, не обнаруженных на этапах разработки спецификации и реализации, которые неблагоприятно влияют на безопасность.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

Описание. Различают два подхода реализации контроля:

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

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

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

АС и ПО средств внешнего контроля следует классифицировать и квалифицировать в соответствии с подходящим УПБ.

В.3.5 Многовариантное программирование

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

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

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

- если система находится в безопасном состоянии, можно потребовать полного согласия (все N результатов одинаковы); в противном случае используется выходное значение, которое заставит систему перейти в безопасное состояние. Для простых пошаговых систем сравнение может обеспечить безопасность. В этом случае безопасное действие может быть разбито по шагам, если какая-либо версия реализует пошаговые операции. Этот подход обычно используют только для двух версий (N = 2);

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

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

Подробное описание данного метода/средства приведено в [116]-[119].

В.3.6 Восстановление предыдущего состояния

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

Подробное описание данного метода/средства приведено в [120], [121].

В.3.7 Механизмы повторных попыток парирования сбоя

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

Подробное описание данного метода/средства приведено в [122].

В.3.8 Постепенное отключение функций

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

Данные соображения относятся в основном к АС, но они применимы также и к системе в целом, включая ПО. Данные соображения должны учитываться, начиная с самых ранних этапов проектирования.

Подробное описание данного метода/средства приведено в [123], [124].

В.3.9 Исправление ошибок методами искусственного интеллекта

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

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

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

Примечание - Предупреждение об исправлении ошибочных данных (см. В.3.2) и об отрицательных рекомендациях применения данного метода [см. ГОСТ 34332.4-2021 (таблица А.2, пункт 5)].

Подробное описание данного метода/средства приведено в [125]-[127].

В.3.10 Динамическая реконфигурация

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

Данный метод следует учитывать на первом этапе проектирования системы.

Подробное описание данного метода/средства приведено в [128].

В.3.11 Безопасность и работа в жестком реальном времени. Архитектура с временным распределением

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

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

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

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

Передача между узлами выполняется в соответствии с протоколом временного распределения ресурсов (ТТР/С) согласно статическому расписанию обмена, в рамках которого решается, когда передать сообщение и является ли полученное сообщение важным для конкретного электронного модуля. Доступ к шине реализуется по схеме с определенным периодическим расписанием в режиме множественного доступа с разделением времени (TDMA), связанной с глобальным временем.

Протокол ТТР/С гарантирует четыре базовые услуги (базовые службы) в сети узлов ТТА системы:

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

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

- контроль целостности данных при сбоях в узлах (служба целостности). Коммуникационный контроллер сообщает каждому "минимальному элементу замены" (SRU) о состоянии остальных SRU в кластере с временной задержкой меньше одного раунда TDMA;

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

Примечание - Существуют другие протоколы с временным распределением: FlexRay и TT-Ethernet (Интернет с временным распределением).

Подробное описание данного метода/средства приведено в [129]-[131].

В.3.12 Универсальный язык программирования (UML)

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.7).

Описание. Универсальный язык программирования (UML) - это набор требований и нотаций проектирования, которые предназначены обеспечить всестороннюю поддержку процессу разработки ПО. Некоторые части UML основаны на нотациях, впервые появившихся в других методах (таких как диаграмма последовательностей и диаграммы переходов), а другие нотации уникальны в UML. UML очень близок к объектно-ориентированному языку, хотя некоторые из нотаций могут не использоваться в объектно-ориентированном программировании. UML поддерживается многими коммерчески доступными инструментами CASE, многие из которых способны автоматически генерировать программные коды из моделей UML.

Нотации UML, которые обычно применяют для составления спецификации и проектирования СБС, следующие:

- диаграммы классов;

- прецеденты;

- диаграммы действий;

- диаграммы переходов (диаграммы состояний);

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

Другие нотации UML относятся к представлению проекта архитектуры ПО (структуры ПО), но в данном пункте не рассматриваются.

Диаграмма переходов описана в Б.2.3.2, а диаграмма последовательностей - в В.2.14. Остальные нотации описаны в следующих трех пунктах.

В.3.12.1 Диаграммы классов

Диаграммы классов определяют классы объектов, которые должны быть использованы в ПО. Они основаны на более ранних схемах атрибут - связь - сущность, но адаптированы к объектно-ориентированному проектированию. Каждый класс (из которого один или более экземпляров будут использоваться в качестве объектов во время выполнения) представлен прямоугольником, а различные отношения между классами показаны линиями или стрелками. К схеме могут быть добавлены операции или методы, предлагаемые каждым классом, и атрибуты данных каждого класса. Представляемые отношения состоят как из ссылочных отношений с указанием их кратности (экземпляр класса А может обратиться к одному или нескольким экземплярам класса В), так и из отношений специализации (класс X - уточнение класса Y) возможно, с дополнительными методами и атрибутами. Может быть изображено множественное наследование.

В.3.12.2 Прецеденты

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

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

В.3.12.3 Диаграммы действий

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

Подробное описание данного метода/средства приведено в [113].

В.4 Инструменты разработки и языки программирования

В.4.1 Строго типизированные языки программирования

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица A.3).

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

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

Строго типизированные языки обычно обеспечивают другие аспекты проверенной на практике техники ПО, например, легко анализируемые структуры управления (if... then... else..., do... while... и т.п.), которые приводят к четко структурированным программам.

Типичными примерами строго типизированных языков являются PASCAL, Ada и MODULA 2.

Подробное описание данного метода/средства приведено в [104].

В.4.2 Подмножество языка

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица A.3).

Цель - снижение вероятности внесения программных ошибок и повышение вероятности обнаружения оставшихся ошибок.

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

В.4.3 Сертифицированные средства и сертифицированные трансляторы

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица A.3).

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

В настоящее время регулярным процедурам сертификации подвергаются только компиляторы (трансляторы); сертификацию проводят национальными органами по сертификации, которая заключается в проверке компиляторов (трансляторов) на соответствие международным стандартам, например, для языков Ada или PASCAL.

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

Подробное описание данного метода/средства приведено в [132].

В.4.4 Инструментальные средства и трансляторы - повышение уверенности на основании опыта использования

Цель - исключение любых проблем, обусловленных ошибками транслятора, которые могут появиться во время разработки, верификации и эксплуатации программного пакета.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица A.3).

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

Если в трансляторе выявлены небольшие недостатки, то соответствующие языковые конструкции в проектах, связанных с безопасностью, не применяют.

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

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

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

В.4.4.1 Сравнение исходных программ и исполнимых кодов

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

Описание. Образ PROM обратно преобразуют в совокупность "объектных" модулей. Эти "объектные" модули преобразуют обратно в файлы ассемблера, которые затем, с помощью соответствующих методов, сравнивают с фактическими исходными файлами, используемыми первоначально для разработки PROM.

Основное преимущество данного метода состоит в том, что инструменты [компиляторы, редакторы связей (компоновщики) и т.п.], используемые для разработки образа PROM, не требуют подтверждения соответствия. Этим методом проверяют правильность преобразования исходного файла, используемого для конкретной СБС.

Подробное описание данного метода/средства приведено в [133].

В.4.5 Выбор подходящего языка программирования

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица A.3).

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

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

- блочную структуру организации программ;

- проверку времени трансляции;

- проверку во время работы программы типов и границ массивов.

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

- использование небольших и управляемых программных модулей;

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

- определение поддиапазонов переменных;

- любые другие типы конструкции, ограничивающие ошибки.

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

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

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

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

- безусловные переходы (за исключением вызовов подпрограмм);

- рекурсии;

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

- обработка прерываний на уровне исходного кода;

- множество входов или выходов в циклах, блоках или подпрограммах;

- неявная инициализация или объявление переменных;

- вариантные записи и эквивалентность;

- процедурная переменная в качестве параметра.

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

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

Рекомендации по конкретным языкам программирования приведены в таблице В.1.

Таблица В.1 - Рекомендации по конкретным языкам программирования

Язык программирования	УПБ 1	УПБ 2	УПБ 3	УПБ 4
1 Ada	ОР	ОР	Р	Р
2 Ada с подмножеством	ОР	ОР	ОР	ОР
3 Java	HP	HP	HP	HP
4 Java с подмножеством (без включения сборки мусора или с включением сборки мусора, которая не будет вызывать остановку прикладной программы в течение значительного промежутка времени). Руководящие указания по использованию объектно-ориентированных средств см. в приложении Ж	Р	Р	HP	HP
5 PASCAL (см. примечание 1)	ОР	ОР	Р	Р
6 PASCAL с подмножеством	ОР	ОР	ОР	ОР
7 FORTRAN 77	Р	Р	Р	Р
8 FORTRAN 77 с подмножеством	ОР	ОР	ОР	ОР
9 С	Р	- -	HP	HP
10 С с подмножеством и стандартом кодирования, а также использование инструментов статического анализа	ОР	ОР	ОР	ОР
11 С++ (Руководящие указания по использованию объектно-ориентированных средств см. в приложении Ж)	Р	- -	HP	HP
12 С++ с подмножеством и стандартом кодирования, а также использование инструментов статического анализа (Руководящие указания по использованию объектно-ориентированных средств см. в приложении Ж)	ОР	ОР	ОР	ОР
13 Ассемблер	Р	Р	- -	- -
14 Ассемблер с подмножеством и стандартом кодирования	Р	Р	Р	Р
15 Многоступенчатые диаграммы	Р	Р	Р	Р
16 Многоступенчатая диаграмма с определенным подмножеством языка	ОР	ОР	ОР	ОР
17 Диаграмма функциональных блоков	Р	Р	Р	Р
18 Диаграмма функциональных блоков с определенным подмножеством языка	ОР	ОР	ОР	ОР
19 Структурированный текст	Р	Р	Р	Р
20 Структурированный текст с определенным подмножеством языка	ОР	ОР	ОР	ОР
21 Последовательная функциональная диаграмма	Р	Р	Р	Р
22 Последовательная функциональная диаграмма с определенным подмножеством языка	ОР	ОР	ОР	ОР
23 Список команд	Р	- -	HP	HP
24 Список команд с определенным подмножеством языка	ОР	Р	Р	Р
Примечания 1 Пояснения к рекомендациям: Р - рекомендованный, ОР - особо рекомендованный, HP - нерекомендованный, "- -" - рекомендация отсутствует (см. ГОСТ 34332.4-2021, приложение А). 2 Системное программное обеспечение включает в себя операционную систему, драйверы, встроенные функции и программные модули, являющиеся частью системы. Программные средства обычно обеспечивают системой безопасности при поставке. Подмножество языка следует выбирать очень внимательно с тем, чтобы исключить сложные структуры, которые могут образоваться в результате ошибок реализации. Следует выполнять проверки для того, чтобы убедиться в правильном использовании подмножества языка программирования. 3 Прикладная программа представляет собой программу, разработанную для конкретного безопасного применения. Во многих случаях такая программа разрабатывается конечным пользователем либо подрядчиком, ориентированным на разработку прикладных программ. В тех случаях, когда ряд языков программирования поддерживает одни и те же рекомендации, разработчику следует выбрать тот, который повсеместно используется персоналом в конкретной промышленности или отрасли. Подмножество языка программирования следует выбирать с особым вниманием, чтобы исключить сложные структуры, которые могут привести к ошибкам реализации. 4 Если конкретный язык программирования не представлен в настоящей таблице, то это не означает, что он исключен. Такой конкретный язык программирования должен быть проверен на соответствие требованиям настоящего стандарта. 5 Существует ряд расширений языка PASCAL, включая свободно распространяемый PASCAL. Ссылки на PASCAL включают эти расширения. 6 Java имеет сборщик мусора времени выполнения. Подмножество Java может не иметь сборщика мусора. Некоторые реализации Java обеспечивают прогрессивную сборку мусора, которая восстанавливает свободную память в процессе выполнения программы и предотвращает выполнение остановки, когда исчерпана доступная память. Приложения жесткого реального времени не должны использовать любые средства сборки мусора. 7 Если применение языка Java требует использования интерпретатора времени выполнения для промежуточного кода Java, то такой интерпретатор следует рассматривать, как часть ПО, связанного с безопасностью, и с учетом требований ГОСТ 34332.4. 8 Информационные сведения о пунктах 15-24 см. в [43].

Подробное описание данных методов/средств приведено в [40], [49], [104], [134]-[142].

В.4.6 Автоматическая генерация программного обеспечения

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.2).

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

Подробное описание данного метода/средства приведено в [143], [144].

В.4.7 Управление тестированием и средства автоматизации

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.5).

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

Подробное описание данного метода/средства приведено в [145].

В.5 Верификация и модификация

В.5.1 Вероятностное тестирование

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблицы А.5, А.7 и приложение В, таблицы В.15, В.17).

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

- вероятность ошибки при запросе;

- вероятность ошибки в течение определенного периода времени;

- вероятность последствий ошибки.

Из этих показателей могут быть получены другие показатели, например:

- вероятность безошибочной работы;

- вероятность живучести;

- доступность;

- MTBF или частота отказов;

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

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

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

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

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

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

Подробное описание данного метода/средства приведено в [146]-[149].

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

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблицы А.5 и А.8).

Описание. В процессе всего проектирования разрабатывают подробную документацию, в состав которой входят:

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

- решения и их разумные обоснования;

- описание проблем и их решений.

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

Подробное описание данного метода/средства приведено в [150].

В.5.3 Тестирование интерфейса

Цель - обнаружение ошибок в интерфейсах подпрограмм.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.5).

Описание. Возможны несколько уровней детализации или полноты тестирования. К наиболее важным уровням относится тестирование:

- всех интерфейсных переменных с их предельными значениями;

- всех отдельных интерфейсных переменных с их предельными значениями с другими интерфейсными переменными с их нормальными значениями;

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

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

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

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

В.5.4 Анализ граничных значений

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.2, Б.3 и Б.8).

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

- нулевой делитель;

- знаки пробела ASCII;

- пустой стек или элемент списка;

- заполненная матрица;

- ввод нулевой таблицы.

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

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

Подробное описание данного метода/средства приведено в [58].

В.5.5 Предположение ошибок

Цель - исключение ошибок программирования.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.2 и Б.8).

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

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

Подробное описание данного метода/средства приведено в [58].

В.5.6 Введение ошибок

Цель - подтверждение адекватности набора тестовых примеров.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.2 и Б.4).

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

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

Подробное описание данного метода/средства приведено в [151].

В.5.7 Разделение входных данных на классы эквивалентности

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.2 и Б.3).

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

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

Существуют следующие основные возможности разбиения входных данных:

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

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

Подробное описание данного метода/средства приведено в [58]-[60].

В.5.8 Структурное тестирование

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.2).

Описание. На основе анализа программы выбирают набор входных данных так, чтобы мог быть проанализирован достаточно большой (часто с заранее заданным значением) процент программных кодов. Меры охвата программы, в зависимости от степени требуемой строгости, могут быть различными. В любом случае целью должно быть 100 % выбранной метрики охвата; если невозможно достигнуть 100 % охвата, то причины, почему 100 % охвата не может быть достигнуто, должны быть документально оформлены в отчете о тестировании (например, если возникает аппаратная проблема, желательно ввести только код защиты). В ГОСТ 34332.4-2021 (рекомендации к таблице Б.2) специально упомянуты широко поддерживаемые инструментами тестирования первые четыре метода, приведенные в перечислении ниже. Могут быть также применены следующие методы:

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

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

- операторы - гарантирует, что все операторы в коде были выполнены по крайней мере однажды;

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

- составные условия - анализируют каждое условие в составном условном переходе (связанное оператором И/ИЛИ). См. MCDC (охват условного модифицированного решения, документ DO178B);

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

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

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

Подробное описание данного метода/средства приведено в [58]-[60].

В.5.9 Анализ потока управления

Цель - обнаружение низкокачественных и потенциально некорректных структур программ.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.8).

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

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

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

Подробное описание данного метода/средства приведено в [60].

В.5.10 Анализ потока данных

Цель - обнаружение низкокачественных и потенциально некорректных структур программ.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.8).

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

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

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

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

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

Подробное описание данного метода/средства приведено в [60], [152].

В.5.11 Тестирование на символьном уровне

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.8).

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

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

Подробное описание данного метода/средства приведено в [153], [154].

В.5.12 Формальное доказательство (верификация)

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблицы А.5 и А.9).

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

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

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

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

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

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

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

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

Ряд формальных методов, применяющихся на практике, описаны в В.2.4: например, CCS, CSP, HOL, LOTOS, OBJ, временная логика, VDM и Z.

В.5.12.1 Проверка модели

Проверка модели - это метод для формальной верификации реактивных и конкурентных систем. Задавая конечное состояние структуры, которая описывает поведение системы, проверяют свойство, записанное в виде формулы во временной логике, соответствует ли оно структуре. Для автоматического и исчерпывающего прохода всех состояний структуры используют эффективные алгоритмы (например, SPIN, SMV и UPPAAL). Если свойство не удовлетворяется, то генерируется контрпример. Эта процедура показывает, как свойства нарушаются в структуре, и содержит очень полезную информацию для исследования системы. Применение метода проверки модели позволяет обнаружить глубоко скрытые (подводные) ошибки, которые могут быть не обнаружены при обычном контроле и тестировании.

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

Подробное описание данного метода/средства приведено в [155]-[158].

В.5.13 Метрики сложности программного обеспечения

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблица А.9 и приложение В, таблица В.19).

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

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

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

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

- число входов и выходов на программный модуль. Сведение к минимуму числа точек входов/выходов является ключевой особенностью методов структурного проектирования и программирования.

Подробное описание данного метода/средства приведено в [159].

В.5.14 Формальные проверки

Цель - обнаружение ошибок в модуле ПО.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.8).

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

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

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

Подробное описание данного метода/средства приведено в [58]-[60], [160].

В.5.15 Сквозной контроль (программного обеспечения)

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.8).

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

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

Подробное описание данного метода/средства приведено в [58]-[60].

В.5.16 Анализ проекта

Цель - выявление дефектов в проекте ПО.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение В, таблица В.8).

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

Анализ проекта является средством оценки соответствия состояния проекта входным требованиям, а также средством идентификации возможностей для его дальнейшего усовершенствования. Даже если разработка проекта на этапах ЖЦ выполняется успешно, и основные конкретные проектные требования удовлетворены, то анализ проекта должен быть выполнен для того, чтобы исследовать все интерфейсные аспекты; гарантировать, что проект может быть верифицирован, удостовериться, что проект удовлетворяет проектным требованиям; гарантировать, что проект в наибольшей степени удовлетворяет требованиям безопасности. Такой анализ предназначен для проверки результатов работы разработчиков и должен рассматриваться как действия по подтверждению и совершенствованию этих результатов.

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

Подробное описание данного метода/средства приведено в [55], [58]-[60].

В.5.17 Макетирование/анимация

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.3 и Б.5).

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

Подробное описание данного метода/средства приведено в [56].

В.5.18 Моделирование процесса

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблица А.7; приложение Б, таблица Б.3 и приложение В, таблицы В.7 и В.13).

Описание. Создание системы только для целей тестирования, имитирующей поведение управляемого оборудования (УО).

Имитация может быть осуществлена только программными средствами либо сочетанием ПО и АС. Она должна:

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

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

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

Когда тестируется ПО, то моделируются заданные АС с их входными и выходными данными.

Подробное описание данного метода/средства приведено в [161].

В.5.19 Требования к реализации

Цель - установление демонстрируемых требований к функционированию системы ПО.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.6).

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

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

- критерии успешности результата, который следует получить;

- возможность получения меры критерия успешности;

- потенциальную точность таких результатов измерения;

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

- этапы проектирования, на которых могут быть получены эти результаты измерений.

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

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

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

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

- использование (по возможности) применения одного измерения для нескольких требований к характеристикам.

Подробное описание данного метода/средства приведено в [56].

В.5.20 Моделирование реализации

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

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение Б, таблицы Б.2 и Б.5).

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

- создания модели процессов системы и их взаимодействий;

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

- определения распределения запросов к системе при средних и наихудших условиях;

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

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

Перед детальным моделированием может быть использована более простая проверка "бюджета ресурсов", при которой суммируют требования к ресурсам для всех процессов. Если сумма этих требований к системе превышает возможности спроектированной системы, проект считают не реализуемым. Даже в случае, если проект проходит эту простую проверку, моделирование выполнения может показать, что имеются слишком большие задержки и времена откликов происходят из-за недостатка ресурсов. Для исключения такой ситуации инженеры часто проектируют системы, в которых используется только часть (например 50 %) общих ресурсов для уменьшения вероятности нехватки ресурсов.

Подробное описание данного метода/средства приведено в [56].

В.5.21 Проверка на критические нагрузки/стресс-тестирование

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.6).

Описание. Существует множество тестов для проверки на критические нагрузки или стресс-тестирование, например:

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

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

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

- имеющие решающее влияние устройства настраивают на свои максимальные скорости или самые малые скорости соответственно;

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

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

В.5.22 Ограничения на время ответа и объем памяти

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение Б, таблица Б.6).

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

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

В.5.23 Анализ влияния

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.8).

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

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

- повторная проверка только изменений программного модуля;

- повторная проверка всех подвергнувшихся воздействию программных модулей;

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

Подробное описание данного метода/средства приведено в [162].

В.5.24 Управление конфигурацией программного обеспечения

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.8).

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

Подробное описание данного метода/средства приведено в [59], [60], [163].

В.5.25 Регрессионное подтверждение соответствия

Цель - гарантирование того, что обоснованные выводы сделаны из регрессионного тестирования.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.8).

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

Подробное описание данного метода/средства приведено в [145].

В.5.26 Анимация спецификации и проектирования

Цель - осуществление верификации ПО посредством систематической проверки спецификации.

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.9).

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

Подробное описание данного метода/средства приведено в [164].

В.5.27 Тестирование, основанное на модели (генерация тестов)

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.5).

Описание. В методе тестирования, основанном на модели (МВТ), использует подход "черного ящика", в котором общие задачи тестирования, такие как генерация тестовой комбинации (TCG) и оценка результатов тестирования, основаны на модели тестируемой (прикладной) системы (SUT). Как правило, но не всегда, данные о системе и поведение пользователя смоделированы с использованием методов конечных автоматов, марковских процессов, таблиц решений и т.п. Кроме того, тестирование, основанное на модели, может быть объединено с измерением тестового охвата на уровне исходного кода, а функциональные модели могут быть основаны на существующем исходном коде.

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

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

Модель является абстрактным частичным представлением требуемого поведения тестируемой системы. Из этой модели формируют примеры тестов, создавая абстрактную тестовую комбинацию. Из этой абстрактной тестовой комбинации выделяют контрольные примеры и проверяют систему. Кроме того, эти контрольные примеры могут быть также использованы для проверки и модели системы. Метод тестирования, основанный на модели, с генерацией тестовой комбинации основан на использовании формальных методов и тесно связан с ними, поэтому рекомендации по его применению аналогичны рекомендациям по УПБ: для высоких уровней полноты безопасности (УПБ): для более высоких УПБ - "ОР" (особо рекомендованный), для низких УПБ - применение не требуется "- -".

В общем случае метод состоит из набора следующих действий:

- создание модели (из системных требований);

- генерация ожидаемых входов;

- генерация ожидаемых выходов;

- выполнение тестов;

- сравнение фактических результатов с ожидаемыми выходами;

- выбор дальнейших действий (изменение модели, генерация дальнейших тестов, оценка надежности/качества ПО).

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

- таблицы решений;

- конечные автоматы;

- формальные грамматики;

- цепи Маркова;

- диаграммы состояний;

- доказательство теорем;

- логическое программирование с ограничениями;

- модель проверки;

- моделирование на символьном уровне;

- использование модели потока событий;

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

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

Подробное описание данного метода/средства приведено в [165]-[173].

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

Примечание - Соответствующие методы и средства см. также в Б.6.

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

Цель - обеспечение ясных и согласующихся спецификаций и анализа сложных логических комбинаций и их отношений.

Примечание - Ссылки на данный метод/средство приведены в ГОСТ 34332.4-2021 (приложение А, таблица А.10 и приложение Б, таблица Б.7).

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

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

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

В.6.2 Исследование опасности и работоспособности программного обеспечения (CHAZOP, FMEA)

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

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

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

Метод HAZOP создавался для производственных процессов и требует модификации при его применении к ПО. Были предложены различные производные методы (Computer HAZOPs - "CHAZOPs"), которые сопровождались новыми руководящими материалами и/или реализовывали способы систематического охвата системной и программной архитектур.

Подробное описание данного метода/средства приведено в [109], [174], [175].

В.6.3 Анализ отказов по общей причине

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.10).

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

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

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

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

Подробное описание данного метода/средства приведено в [176].

В.6.4 Структурные схемы надежности

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

Примечание - Ссылка на данный метод/средство приведена в ГОСТ 34332.4-2021 (приложение А, таблица А.10).

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

Подробное описание данного метода/средства приведено в [75], [77].