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

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

Методы/средства для достижения полноты безопасности программного обеспечения (см. ГОСТ Р 53195.4)

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

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

Более подробное описание некоторых методов/средств приведено в [99-103].

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы A.2 и A.4).

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

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

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

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

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

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

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

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

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

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

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

Настоящий раздел содержит подробное описание пяти структурных методов: "Представление требований", "Разработка системы по Джексону", MASCOT, "Yourdon для систем реального времени" и "Методология структурного анализа и проектирования (SADT)".

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

В.2.1.2 CORE - контролируемое представление требований

Цель: обеспечение представления и формулирования всех требований.

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

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

В.2.1.3 Разработка системы по Джексону - JSD

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

Описание: метод JSD (Jackson Structured Development), разработанный Майклом Джексоном в середине 80-х годов, предлагает стиль разработки программных систем, отличный от стиля, принятого в методах SA/SD или OMT. В методе JSD не делается различий между этапом анализа требований к системе и этапом ее разработки. Оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы. При этом этапе решается вопрос "Что должно быть сделано?". Вопрос "Как это должно быть сделано?" решается на следующем этапе - этапе реализации системы. Метод JSD часто применяют для проектирования систем реального времени. В нем использована система графических обозначений, хотя сам метод менее ориентирован на графику, чем методы SA/SD и OMT.

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

- разработку действий и объектов;

- разработку структуры объектов;

- разработку исходной модели;

- разработку функций;

- разработку ограничений;

- реализацию системы.

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

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

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

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

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

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

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

Тем не менее метод JSD может успешно применяться для проектирования и реализации следующих типов прикладных программных систем:

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

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

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

Метод JSD плохо приспособлен для решения следующих задач:

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

- разработка баз данных, так как это слишком сложная задача для метода JSD. Подробное описание метода/средства приведено в [111-113].

В.2.1.4 Модульный метод построения, эксплуатации и тестирования программных средств MASCOT

Цель: обеспечение проектирования и реализации систем реального времени.

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

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

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

В.2.1.5 Метод Йордона (Yourdon) для систем реального времени

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [106].

В.2.1.6 Методология структурного анализа и проектирования - SADT

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

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

Правила SADT включают в себя:

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

- связность диаграмм (номеров блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков действия и линий);

- разделение входов и управлений (правило определения роли данных);

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

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

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки действия и линии (рисунок В.1). Место соединения линии с блоком действия определяет тип интерфейса. Линии обозначают следующее:

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

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

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

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

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

На рисунке В.2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока действия на "родительской" диаграмме.

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

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

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

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

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

Для того чтобы указать положение любой диаграммы или блока действия в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок действия 1 на диаграмме А2. Аналогично А2 детализирует блок действия 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке В.7 показано типичное дерево диаграмм.

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

Таблица В.1 - Типы связанности

Тип связанности	Уровень значимости
Случайная	0
Логическая	1
	2
Процедурная	3
Коммуникационная	4
Последовательная	5
Функциональная	6

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

Случайная связанность (тип 0) - наименее желательная.

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

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

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

Процедурная связанность (тип 3) - процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке В.9.

Коммуникационная связанность (тип 4) - блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок В.10).

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

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

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

C = g(B) = g(f(A)),

где g - функция, реализуемая блоком действия A;

f - функция, реализуемая блоком действия B.

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

Таблица В.2 - Характеристики связанностей

Уровень значимости	Тип связанности	Для функций	Для данных
0	Случайная	Случайная	Случайная
1	Логическая	Функции одного и того же множества или типа (например, "редактировать все входы")	Данные одного и того же множества или типа
2		Функции одного и того же периода времени (например, "операции инициализации")	Данные, используемые в каком-либо интервале
3	Процедурная	Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора")	Данные, используемые во время одной и той же фазы или итерации
3	Процедурная	Функции, использующие одни и те же данные	Данные, на которые воздействует одна и та же деятельность
4	Коммуникационная	Функции, выполняющие последовательные преобразования одних и тех же данных	Данные, преобразуемые последовательными функциями
5	Последовательная	Функции, объединяемые для выполнения одной функции	Данные, связанные с одной функцией
6	Функциональная	Внутренняя функция является аргументом внешней функции	Данные для внешней функции связаны с внутренней функцией

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

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

Более подробное описание данного метода/средства приведено в [115, 116].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы Б.5 и Б.7).

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [117, 118].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.5).

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [116].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы A.1, A.2, A.4 и Б.5).

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

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

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

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

Примечание - Приведенное выше описание содержится также в Б.2.2.

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

Более подробное описание данного метода/средства приведено в [119].

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

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

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

Более подробное описание данного метода/средства приведено в [120].

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [123].

В.2.4.5 LOTOS

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

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

Более подробное описание данного метода/средства приведено в [124].

В.2.4.6 Язык OBJ

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

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

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

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

Более подробное описание данного метода/средства приведено в [125, 126].

В.2.4.7 логика

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

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

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

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

В.2.4.8 VDM, VDM++ - метод разработки Vienna

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

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [130].

В.2.4.9 Z-метод

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

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

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

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

Более подробное описание данного метода/средства приведено в [131].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.4).

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

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

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

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [132-136].

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

Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.4 (таблица A.4).

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

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

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

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

Более подробное описание данного метода/средства приведено в [137].

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

Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).

Цель: упрощение верификации разработанного кода.

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

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

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

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

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

- распечатывание программного кода (формирование листинга);

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

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

Примечание - Более подробная информация по этим вопросам приведена в В.2.6.3 - В.2.6.7.

Более подробное описание данного метода/средства приведено в [102, 137-142].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).

Цель: исключение динамических и переменных объектов во избежание:

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

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

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).

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

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

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.4).

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [102, 137, 138, 141, 143-149].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.9).

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

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

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

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

Более подробное описание данного метода/средства приведено в [150, 151].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы A.4 и Б.9).

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [70, 138, 152].

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

Примечания

1 На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.4).

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

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

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

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

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

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

- имеется по меньшей мере один год предыстории работы;

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

- отказов на запрос (в год) с уверенностью 95% при требуемом числе эксплуатационных прогонов (в год) 30;

- отказов на запрос (в год) с уверенностью 99,9% при требуемом числе эксплуатационных прогонов (в год) 690 000;

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [148, 150, 153].

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

Обнаружение сбоев основывается на принципах избыточности (в основном при обнаружении сбоев АС - см. ГОСТ Р 53195.3, приложение A) и разнообразия (программные сбои). Для определения корректности результатов требуется некоторый вид голосования. Могут быть применены определенные специальные методы, к которым относятся: программирование утверждений, метод программирования N-версий и так называемая "подушка безопасности" (см. В.3.4 настоящего приложения); а для АС - применение дополнительных сенсоров, контуров регулирования, кодов, обнаруживающих ошибки, и др.

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

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

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

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

Более подробное описание данного метода/средства приведено в [153].

В.3.2 Обнаружение и исправление ошибок

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

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

Более подробное описание данного метода/средства приведено в [154].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица A.18) и в ГОСТ Р 53195.4 (таблица A.2).

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

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

Пример

      assert <pre-condition>;

              action 1;

...

              action x;

      assert <post-condition>.

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

В.3.4 Методы "подушки безопасности"

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

АС и ПО "подушки безопасности" следует классифицировать и квалифицировать в соответствии с подходящим уровнем полноты безопасности SIL.

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [160-162].

В.3.6 Блоки восстановления

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

Более подробное описание данного метода/средства приведено в [163, 164].

В.3.8 Прямое восстановление функций

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

Более подробное описание данного метода/средства приведено в [165].

В.3.9 Методы повторных попыток восстановления неисправностей

Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53185.4 (таблица A.2).

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

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

Более подробное описание данного метода/средства приведено в [165].

В.3.10 Сохранение достигнутых состояний

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

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

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

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

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

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

Более подробное описание данного метода/средства приведено в [166-168].

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

Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

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

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

Примечание - Должны быть учтены предупреждения об исправлении ошибочных данных, приведенные в В.3.2, и об отрицательных рекомендациях применения этого метода, приведенные в ГОСТ Р 53195.4 (таблица A.2, пункт 5).

Более подробное описание данного метода/средства приведено в [169].

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

Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица A.2).

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

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

Этот метод должен рассматриваться на первом этапе проектирования системы.

Более подробное описание данного метода/средства приведено в [169].

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

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

Примечание - Ссылка на данные методы/средства приведена в ГОСТ Р 53195.4 (таблица А.3).

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

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

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

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

Типичными примерами строго типизированных языков являются C ++, Delphi, Java, ML, Pascal, ADA, Modula 2.

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [173].

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

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

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

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

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

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

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

В.4.4 Инструментальные средства, заслуживающие доверия на основании опыта использования

Примечание - Ссылка на данные методы/средства приведена в ГОСТ Р 53195.4 (таблица А.3).

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [176-178].

В.4.6 Библиотека проверенных/верифицированных модулей и компонентов

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [179, 180].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- рекурсии;

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

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

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

- инициализация или декларация неявных переменных;

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

- процедурные параметры.

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

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

Рекомендации по применению некоторых языков программирования приведены в таблице В.3. Обозначения рангов применимости языков программирования следующие:

КР (HR) - крайне рекомендуемый для данного уровня полноты безопасности. Если его не используют, то на этапе планирования должно быть дано подробное обоснование отказа от его применения, согласованное с экспертом;

Р (R) - рекомендуемый для данного уровня полноты безопасности. Степень обязательности его применения ниже, чем в случае рекомендации КР (HR);

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

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

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

Наименование, обозначение языка программирования	Ранг применимости языка для
Наименование, обозначение языка программирования	SIL1	SIL2	SIL3	SIL4
1 ADA	КР (HR)	КР (HR)	Р (R)	Р (R)
2 ADA с подмножеством	КР (HR)	КР (HR)	КР (HR)	КР (HR)
3 MODULA-2	КР (HR)	КР (HR)	Р (R)	Р (R)
4 MODULA с подмножеством	КР (HR)	КР (HR)	КР (HR)	КР (HR)
5 PASCAL	КР (HR)	КР (HR)	Р (R)	Р (R)
6 PASCAL с подмножеством	КР (HR)	КР (HR)	КР (HR)	КР (HR)
7 FORTRAN 77	Р (R)	Р (R)	Р (R)	Р (R)
8 FORTRAN 77 с подмножеством	КР (HR)	КР (HR)	КР (HR)	КР (HR)
9 С	Р (R)	--	НР (NR)	НР (NR)
10 Язык С с подмножеством и стандартом кодирования, а также использование инструментов статического анализа	КР (HR)	КР (HR)	КР (HR)	КР (HR)
11 PL/M	Р (R)	--	НР (NR)	НР (NR)
12 PL/M с подмножеством и стандартом кодирования	КЗ (HR)	Р (R)	Р (R)	Р (R)
13 Ассемблер	Р (R)	Р (R)	--	--
14 Ассемблер с подмножеством и стандартом кодирования	Р (R)	Р (R)	Р (R)	Р (R)
15 Многоступенчатые диаграммы	Р (R)	Р (R)	Р (R)	Р (R)
16 Многоступенчатая диаграмма с определенным подмножеством языка	КР (HR)	КР (HR)	КР (HR)	КР (HR)
17 Диаграмма функциональных блоков	Р (R)	Р (R)	Р (R)	Р (R)
18 Диаграмма функциональных блоков с определенным подмножеством языка	КР (HR)	КР (HR)	КР (HR)	КР (HR)
19 Структурированный текст	Р (R)	Р (R)	Р (R)	Р (R)
20 Структурированный текст с определенным подмножеством языка	КР (HR)	КР (HR)	КР (HR)	КР (HR)
21 Последовательная функциональная диаграмма	Р (R)	Р (R)	Р (R)	Р (R)
22 Последовательная функциональная диаграмма с определенным подмножеством языка	КР (HR)	КР (HR)	КР (HR)	КР (HR)
23 Список команд	Р (R)	--	НР (NR)	НР (NR)
24 Список команд с определенным подмножеством языка	КР (HR)	Р (R)	Р (R)	Р (R)
Примечания 1 Системное программное обеспечение включает в себя операционную систему, драйверы, встроенные функции и программные модули, являющиеся частью системы. ПО обычно обеспечивается поставщиком СБЗС-систем (подсистем). Подмножество языка следует выбирать очень внимательно, с тем чтобы исключить сложные структуры, которые могут образоваться в результате ошибок реализации. Следует проводить проверки, чтобы убедиться в правильном использовании подмножества языка программирования. 2 Прикладная программа представляет собой программу, разработанную для конкретного применения СБЗС-системы. Во многих случаях такая программа разрабатывается конечным пользователем либо подрядчиком, ориентированным на разработку прикладных программ. В тех случаях, когда ряд языков программирования поддерживают одни и те же рекомендации, разработчику следует выбрать тот язык, который повсеместно используется персоналом в конкретной промышленности или отрасли. Подмножество языка программирования следует выбирать с особым вниманием, чтобы исключить сложные структуры, которые могут привести к ошибкам реализации. 3 Если конкретный язык программирования не представлен в настоящей таблице, то это не означает, что он исключен. Этот конкретный язык программирования должен соответствовать требованиям настоящего стандарта. 4 О пунктах 15-24 см. ГОСТ Р 53195.4.

Более подробное описание данного метода/средства приведено в [181].

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

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

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

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

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

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

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

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

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

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

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

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

- среднее время наработки на отказ (MTBF) или частота отказов;

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [182, 183].

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

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

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

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

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

- решения и их обоснования;

- проблемы и их решения.

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

Более подробное описание данного метода/средства приведено в [184].

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [185].

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

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [186].

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [187].

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [186-189].

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [190-194].

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

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [195-200].

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [201, 202].

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [201-203].

В.5.11 Выявление скрытых схем исполнения

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

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

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

Паразитные схемы разделяют на следующие категории:

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [204, 205].

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

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

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

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

Более подробное описание данного метода/средства приведено в [206, 207].

В.5.13 Формальное доказательство

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [207-210].

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [211-213].

В.5.15 Инспекция программ

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

Цель: обнаружение ошибок на всех этапах разработки программ.

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

Более подробное описание данного метода/средства приведено в [214, 215].

В.5.16 Сквозной контроль/анализ проекта

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [200, 216, 217].

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

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

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

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

Более подробное описание данного метода/средства приведено в [218-220].

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

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

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

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

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

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

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

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

По завершении тестирования ПО созданная система может тестировать АС с их входами и выходами. Более подробное описание данного метода/средства приведено в [221, 222].

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

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

Цель: установление демонстрируемых требований к рабочим характеристикам системы ПО.

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

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

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [222-224].

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

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [222, 225, 226].

В.5.21 Проверка на критические и напряженные нагрузки

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

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [227, 228].

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [227, 229-232].

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

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

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

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [200, 233].

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

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

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

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

Более подробное описание данного метода/средства приведено в [234, 235].

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

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

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

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

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

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

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

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

В.6.2 Исследование опасности и работоспособности (HAZOP)

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [236, 237].

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

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

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

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

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

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

- общее управление качеством;

- анализ проектов;

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

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

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

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

Более подробное описание данного метода/средства приведено в [238, 239].

В.6.4 Модели Маркова

Цель: оценка надежности, безопасности и доступности систем.

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

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

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

Более подробное описание данного метода/средства приведено в [240-244].

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

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

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

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

Более подробное описание данного метода/средства приведено в [245, 246].

В.6.6 Моделирование методом Монте-Карло

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

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

Описание: моделирование методом Монте-Карло используется для решения двух классов задач:

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

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

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

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

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

Более подробное описание данного метода/средства приведено в [247, 248].

<< Приложение Б (справочное). Методы/средства для исключения систематических отказов СБЗС-систем		Приложение >> Г (справочное). Методы оценки. Вероятностный подход к определению полноты безопасности предварительно разработанных программных...
	Содержание Национальный стандарт РФ ГОСТ Р 53195.5-2010 "Безопасность функциональная связанных с безопасностью зданий и сооружений систем....

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

Откройте актуальную версию документа прямо сейчас