ФЕДЕРАЛЬНОЕ АГЕНТСТВО
БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ Часть 5 Меры по снижению риска, методы оценки
Предисловие Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения» Сведения о стандарте 1 РАЗРАБОТАН Университетом комплексных систем безопасности и инженерного обеспечения 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 439 «Средства автоматизации и системы управления» при поддержке Технического комитета по стандартизации ТК 465 «Строительство» 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 декабря 2010 г. № 821-ст 4 В настоящем стандарте использованы основные нормативные положения следующих международных стандартов: МЭК 61508-4:2010 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины, определения, сокращения» (IEC 61508-4:2010 «Functional safety of electrical/ electronic/ programmable electronic safety-related systems - Part 4: Definitions and abbreviations»); МЭК 61508-7:2010 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Обзор методов и средств (IEC 61508-7:2010 «Functional safety of electrical/ electronic/ programmable electronic safety-related systems - Part 7: Overview of techniques and measures»); Руководство ИСО/МЭК 51:1999 Аспекты безопасности. Руководящие указания по включению их в стандарты (ISO/IEC Guide 51:1999 «Safety aspects - Guidelines for their inclusion in standards») 5 ВВЕДЕН ВПЕРВЫЕ Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок - в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет Содержание Введение Современные здания и сооружения - объекты капитального строительства - представляют собой сложные системы, включающие в свой состав систему конструкций и ряд систем в разных сочетаниях, в том числе инженерные системы жизнеобеспечения, реализации технологических процесссов, энерго-, ресурсосбережения, безопасности и другие системы. Эти системы взаимодействуют друг с другом, с внешней и внутренней средами. Объекты капитального строительства жестко привязаны к местности. Рабочие характеристики зданий, сооружений и входящих в них систем могут быть реализованы, проверены и использованы только в том месте, в котором объекты построены и системы установлены. Безопасность зданий и сооружений обеспечивается применением совокупности мер, мероприятий и средств снижения риска причинения вреда до уровня приемлемого риска и поддержания его в течение периода эксплуатации или использования этих объектов. К средствам снижения риска относятся системы, связанные с безопасностью зданий и сооружений. Эти системы, состоящие из электрических и/или электронных компонентов, и/или программируемых электронных компонентов, в течение многих лет используются для выполнения функций безопасности. Для решения задач безопасности зданий и сооружений во все больших объемах используются программируемые электронные (компьютерные) системы. В настоящем стандарте установлены цели основных методов/средств, рекомендованных к применению в ГОСТ Р 53195.3 и ГОСТ Р 53195.4 для анализа и снижения риска, достижения и поддержания необходимого уровня функциональной безопасности аппаратных средств (АС) и программного обеспечения (ПО) электрических, электронных, программируемых электронных (Е/Е/РЕ) связанных с безопасностью зданий и сооружений систем (СБЗС-систем) на различных стадиях их жизненного цикла, а также для оценки соответствия систем требованиям безопасности в рамках области применения ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.4. В нем приведены краткие описания указанных методов/средств, а также даны ссылки на источники, содержащие их полные описания. Настоящий стандарт входит в комплекс стандартов с наименованием «Безопасность функциональная связанных с безопасностью зданий и сооружений систем» и является пятым стандартом этого комплекса «Часть 5. Меры по снижению риска, методы оценки». Другие стандарты, входящие в этот комплекс: Часть 1. Основные положения; Часть 2. Общие требования; Часть 3. Требования к системам; Часть 4. Требования к программному обеспечению; Часть 6. Внешние средства уменьшения риска, системы мониторинга; Часть 7. Порядок применения требований к системам и примеры расчетов. Структура комплекса стандартов приведена ниже. ГОСТ Р 53195.5-2010 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ Часть 5 Меры по снижению риска, методы оценки Functional safety of
building/erection safety-related systems. Дата введения -2012 - 01-01 1 Область примененияНастоящий стандарт распространяется на связанные с безопасностью зданий и сооружений системы (далее - СБЗС-системы), аппаратные средства (далее - АС) и/или программное обеспечение (далее - ПО), являющиеся частями СБЗС-системы либо используемые для разработки СБЗС-систем в рамках областей применения ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.4. Настоящий стандарт применяется совместно со стандартами ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.4. Настоящий стандарт устанавливает основные методы/средства, используемые для выполнения требований ГОСТ Р 53195.3 и ГОСТ Р 53195.4, и методы оценки соответствия. Настоящий стандарт содержит краткие описания методов/средств, рекомендуемых в ГОСТ Р 53195.3 и ГОСТ Р 53195.4 и применяемых на различных стадиях жизненных циклов СБЗС-систем, их АС и ПО для снижения рисков, а также ссылки на источники с полным описанием этих методов/средств. Примечание - Под «методами/средствами» в настоящем стандарте понимаются методы и/или средства. В большинстве методов/средств, описанных в приложениях А, Б, В и Г, метод состоит в применении того или иного аппаратного, программного или аппаратно-программного средства или средств, в применении логических или математических действий (которые выполняются с использованием средств информатики и математики). В отдельных случаях рассматриваются методы или средства в чистом виде. Настоящий стандарт не распространяется на одиночные СБЗС-системы, способные осуществить необходимое снижение риска и требуемая полнота безопасности которых ниже самого низкого уровня полноты безопасности (SIL1), определенного в таблицах 1 и 2 ГОСТ Р 53195.2. Он не распространяется также на здания и сооружения, оснащенные такими системами или не имеющие никаких связанных с безопасностью систем. 2 Нормативные ссылкиВ настоящем стандарте использованы нормативные ссылки на следующие стандарты: ГОСТ Р ИСО 9000-2005 Системы менеджмента качества. Основные положения и словарь ГОСТ Р ИСО 9001-2008 Системы менеджмента качества. Требования ГОСТ Р ИСО 10006-2005 Системы менеджмента качества. Руководство по менеджменту качества при проектировании ГОСТ Р ИСО/МЭК 16085-2007 Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения ГОСТ Р 51700-2000 Совместимость технических средств электромагнитная. Технические средства, подключаемые к симметричным линиям. Параметры асимметрии относительно земли. Схемы измерений ГОСТ Р 51904-2002 Программное обеспечение встроенных систем. Общие требования к разработке и документированию ГОСТ Р 53195.1-2008 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 1. Основные положения ГОСТ Р 53195.2-2008 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 2. Общие требования ГОСТ Р 53195.3-2009 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 3. Требования к системам ГОСТ Р 53195.4-2010 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению ГОСТ Р МЭК 61160-2006 Менеджмент риска. Формальный анализ проекта ГОСТ 27.310-95 Надежность в технике. Анализ видов, последствий и критичности отказов. Основные положения ГОСТ 13661-92 Совместимость технических средств электромагнитная. Пассивные помехоподавляющие фильтры и элементы. Методы измерения вносимого затухания ГОСТ 16962.2-90 Изделия электротехнические. Методы испытаний на стойкость к механическим внешним воздействующим факторам ГОСТ 30382-95 Совместимость технических средств электромагнитная. Дроссели помехоподавляющие. Общие технические условия Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодно издаваемому информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячно издаваемым информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку. 3 Термины и определенияВ настоящем стандарте применены термины по ГОСТ Р 53195.1, ГОСТ Р 53195.2, ГОСТ Р 53195.3 и ГОСТ Р 53195.4, а также приведенные ниже термины с определениями. 3.1 антивалентные сигналы (antivalent signals): Два сигнала с одинаковым информационным содержанием, передаваемые по каналам связи в инверсной форме (аналоговые сигналы - в противофазе, цифровые сигналы - с инверсией 0 в 1 или наоборот). 3.2 константная неисправность (stuck-at fault): Неисправность аппаратного средства, вызванная переходом элемента устройства в одно из неизменяемых состояний, например, при «залипании» контактов реле. 3.3 константный отказ (stuck-at failure): Отказ аппаратного средства и/или программного обеспечения, приводящий к переходу аппаратного средства в одно из неизменяемых состояний и/или выдаче на выходе неизменяемых данных или неизменяемой команды. 3.4 постепенный отказ (drift failure): Отказ аппаратного средства из-за постепенного выхода его характеристик за допустимые пределы. 3.5 самоустраняющийся отказ (transient failure): Отказ, обусловленный переходными процессами, устраняющийся по их завершении. 3.6 условная тревога (conditional alarm): Состояние, близкое к тревожному, но еще не влекущее опасных последствий. Примечание - Термин относится к СБЗС-системам, в которых предусмотрено ступенчатое реагирование на постепенно развивающиеся тревожные события. 3.7 чрезвычайное действие (emergency action): Действие, требующее выполнения при возникновении чрезвычайной ситуации для снижения риска причинения вреда. 4 Обозначения и сокращения
5 Меры (методы/средства) по снижению риска5.1.1 Основными мерами по снижению риска являются: - контроль случайных отказов АС Е/Е/РЕ СБЗС-систем; - исключение систематических отказов на различных стадиях жизненных циклов СБЗС-систем; - методы/средства, реализуемые на различных этапах стадий жизненного цикла для достижения полноты безопасности СБЗС ПО. 5.1.2 Методы/средства для контроля случайных отказов АС Е/Е/РЕ СБЗС-систем, их краткое описание, а также ссылки на источники с полным описанием приведены в приложении А. 5.1.3 Методы/средства для исключения систематических отказов на различных стадиях жизненных циклов СБЗС-систем, их краткие описания, а также ссылки на источники с полным описанием приведены в приложении Б. 5.1.4 Методы/средства для достижения полноты безопасности СБЗС ПО, реализуемые на различных этапах стадий жизненного цикла ПО, их краткое описание, а также ссылки на источники с полным описанием приведены в приложении В. 6 Методы оценки6.1 Методы оценки функциональной безопасности СБЗС ПО, их краткое описание, а также ссылки на источники с полным описанием приведены в разделе В.6 приложения В. 6.2 Методы оценки полноты безопасности предварительно разработанных программных средств, применяемых для СБЗС-систем, основанные на вероятностном подходе, приведены в приложении Г. Приложение А
|
Уровень значимости |
|
Случайная |
0 |
Логическая |
1 |
Временная |
2 |
Процедурная |
3 |
Коммуникационная |
4 |
Последовательная |
5 |
Функциональная |
6 |
Каждый тип связанности кратко определен и проиллюстрирован ниже с помощью типичного примера из SADT.
Случайная связанность (тип 0) - наименее желательная.
Случайная связанность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, при которой имена данных на SADT-линиях в одной диаграмме имеют малую связанность друг с другом. Крайний вариант этого случая показан на рисунке В.8.
Рисунок В.8 - Случайная связанность
Логическая связанность (тип 1) образуется тогда, когда данные и функции собираются вместе из-за того, что они попадают в общий класс или набор элементов, но необходимые функциональные отношения между ними не обнаруживаются.
Временная связанность (тип 2) возникает вследствие того, что связанные по времени элементы представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
Процедурная связанность (тип 3) - процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке В.9.
Рисунок В.9 - Процедурная связанность
Коммуникационная связанность (тип 4) - блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок В.10).
Последовательная связанность (тип 5) - выход одной функции служит входными данными для следующей функции. Связанность между элементами на диаграмме является более тесной, чем для рассмотренных выше типовых связанностей, поскольку моделируются причинно-следственные зависимости (рисунок В.11).
Функциональная связанность (тип 6) - при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связанности. Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие линии, как показано на рисунке В.12.
Рисунок В.12 - Функциональная связанность
В математических терминах необходимое условие для простейшего типа функциональной связанности, показанной на рисунке В.12, имеет следующий вид:
C = g(B) = g(f(A)),
где g - функция, реализуемая блоком действия А;
f - функция, реализуемая блоком действия В.
В таблице В.2 представлены все типы связанностей, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы связанностей, которые разработчики считают наиболее важными для получения диаграмм хорошего качества.
Таблица В.2 - Характеристики связанностей
Тип связанности |
Для функций |
Для данных |
|
0 |
Случайная |
Случайная |
Случайная |
1 |
Логическая |
Функции одного и того же множества или типа (например, «редактировать все входы») |
Данные одного и того же множества или типа |
2 |
Временная |
Функции одного и того же периода времени (например, «операции инициализации») |
Данные, используемые в каком-либо временном интервале |
3 |
Процедурная |
Функции, работающие в одной и той же фазе или итерации (например, «первый проход компилятора») |
Данные, используемые во время одной и той же фазы или итерации |
3 |
Процедурная |
Функции, использующие одни и те же данные |
Данные, на которые воздействует одна и та же деятельность |
4 |
Коммуникационная |
Функции, выполняющие последовательные преобразования одних и тех же данных |
Данные, преобразуемые последовательными функциями |
5 |
Последовательная |
Функции, объединяемые для выполнения одной функции |
Данные, связанные с одной функцией |
6 |
Функциональная |
Внутренняя функция является аргументом внешней функции |
Данные для внешней функции связаны с внутренней функцией |
Когда действия сильно связаны между собой многими отношениями, то целесообразно объединить эти действия в единую группу, поместить в один блок действия, не детализируя в дальнейшем его содержание. Основополагающий принцип группирования действий в блоки действия состоит в том, что образуемые в результате блоки действия должны соединяться между собой только небольшим числом отношений.
Декомпозиция моделей диаграмм реализуется до тех пор, пока не потеряет смысл дальнейшая детализация блоков действия. Этот процесс завершается, когда действия внутри блоков действия становятся неразделимыми или когда последующая детализация действий внутри блоков действия выходит за область анализа системы.
Более подробное описание данного метода/средства приведено в [115, 116].
В.2.2 Диаграммы потоков данных
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы Б.5 и Б.7).
Цель: программная поддержка описания потока данных в форме диаграмм.
Описание: диаграммы потоков данных описывают преобразование входных данных в выходные для каждого компонента диаграммы, представляющего различные преобразования. Диаграммы потоков данных состоят из трех компонентов:
- именованные стрелки - представляют поток данных, входящих и исходящих из блоков преобразования, с кратким описанием этих данных;
- именованные кружки (эллипсы) - представляют блоки преобразования с кратким описанием преобразований;
- операторы («and», «хоr») - используются для связи именованных стрелок.
Каждый кружок на диаграмме потока данных может рассматриваться как самостоятельный блок, который при появлении на его входах данных преобразует их в выходные. Одним из основных преимуществ диаграмм является то, что они показывают преобразования, не устанавливая, как они реализуются. Чистая диаграмма потоков данных не включает в себя управляющую информацию или информацию о последовательности процесса, ибо это реализуется в расширениях для реального времени, как в методе Yourdon для систем реального времени (см. В.2.1.5).
Создание диаграмм потока данных является наилучшим подходом при анализе систем от входов к выходам. Каждый кружок на диаграмме должен представлять разное преобразование - его выходы должны отличаться от его входов. Не существует правил определения общей структуры диаграммы, и создание диаграммы потока данных является одним из творческих аспектов создания проекта системы. Подобно всем проектам, это итеративная процедура, уточняющая начальную диаграмму для создания конечной диаграммы.
Более подробное описание данного метода/средства приведено в [117, 118].
В.2.3 Структурные диаграммы
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.5).
Цель: представление структуры программы в виде диаграммы.
Описание: структурные диаграммы дополняют диаграммы потоков данных. Они описывают программируемую систему и иерархию ее компонентов, а также отображают их графически в виде дерева. Они описывают способ реализации элементов диаграммы потоков данных в виде иерархии программных модулей.
Структурная схема показывает взаимоотношения между программными модулями, не указывая при этом порядок активизации этих модулей. Структурные диаграммы изображаются с использованием следующих четырех символов:
- прямоугольник с именем модуля;
- линия, соединяющая эти прямоугольники, формирующие структуру;
- стрелка, отмеченная кругом (без штриховки), с именем данных, передаваемых в направлении элементов структурной схемы и обратно (обычно такая стрелка изображается параллельно с линиями, соединяющими прямоугольники схемы);
- стрелка, отмеченная кругом (заштрихованным), с именем сигнала управления, проходящего в структурной схеме от одного модуля к другому, и эта стрелка также изображается параллельно линии, соединяющей два модуля.
Из любой нетривиальной диаграммы потока данных можно создать множество различных структурных схем.
Диаграммы потоков данных отображают взаимоотношение между информацией и функциями системы. Структурные схемы отображают способ реализации элементов системы. Оба метода представляют две действующие, хотя и различные, точки зрения на систему.
Более подробное описание данного метода/средства приведено в [116].
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы А.1, А.2, А.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].
B.2.4.7 Временная логика
Цель: непосредственное выражение требований к безопасности и эксплуатации, а также формальное представление сохранения этих качеств на последующих этапах разработки.
Описание: стандартная предикатная логика первого порядка не содержит концепций времени. Временная логика расширяет логику первого порядка добавлением модальных операторов (например, «с этого момента» и «случайно»). Эти операторы могут использоваться для уточнения суждений о системе. Например, свойства безопасности могут потребовать использовать оператор «с этого момента», тогда как может потребоваться, чтобы другие необходимые состояния системы были достигнуты «случайно» из некоторого другого начального состояния. Временные формулы интерпретируются последовательностями состояний (поведениями). Что такое «состояние», зависит от выбранного уровня описания. Оно может относиться ко всей системе, системным компонентам или компьютерной программе.
Задаваемые количественно (квонтифицированные) временные интервалы и ограничения во временной логике не обрабатываются явно. Абсолютное время обрабатываются путем образования дополнительных временных состояний как части описания состояния.
Более подробное описание данного метода/средства приведено в [127 - 129].
B.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 представляет собой скорее нотацию, чем завершенный метод. Однако был разработан близкий метод (названный В-методом), который может быть использован в сочетании с языком Z. Метод В основан на принципе пошагового уточнения.
Более подробное описание данного метода/средства приведено в [131].
В.2.5 Программирование с защитой
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.4).
Цель: создание программ, которые во время их исполнения выявляют аномальные потоки сигналов управления, потоки данных или значения данных и реагируют на них заранее определенным и подходящим способом.
Описание: в процессе разработки программ можно использовать много методов для проверки аномалий в сигналах управления или в данных. Эти методы/средства могут применяться систематически в процессе программирования системы с целью уменьшения вероятности ошибочной обработки данных.
Имеются два пересекающихся множества методов защиты. Внутренние методы/средства защиты от ошибок проектируются в программных средствах для преодоления недостатков их проектирования. Эти недостатки могут быть обусловлены ошибками при проектировании или кодировании либо ошибочными требованиями. Ниже перечислены некоторые из методов защиты:
- проверка диапазона значений переменных;
- по возможности проверка значений переменных на их достоверность;
- на входе процедур проверка типа, размерности и диапазона значений параметров процедур.
Эти три метода помогают гарантировать, что значения, которые обрабатываются в программах, допустимы с точки зрения как терминов программных функций, так и физических значений переменных.
Параметры только для считывания и параметры для считывания-записи должны быть разделены, и доступ к ним должен проверяться. Функции должны рассматривать все параметры как параметры только для считывания. Буквенные константы не должны быть доступны для записи. Это помогает обнаруживать случайные перезаписи или ошибочное использование переменных.
Устойчивые к ошибкам программные средства проектируются в «предположении», что ошибки существуют в собственной среде либо при использовании выходящих за номиналы или предполагаемых условий, и при этом ведут себя заранее определенным образом. В таком случае используются следующие методы:
- проверка на достоверность физических значений входных и промежуточных переменных;
- проверка влияния выходных переменных, предпочтительно путем прямого наблюдения соответствующих изменений состояния системы;
- проверка самими программными средствами своей конфигурации, включая наличие и доступность предполагаемых АС, а также завершенность самих программ - это особенно важно для поддержки полноты в процессе их эксплуатации.
Некоторые из методов защиты программ, такие как проверки последовательности потока управления, также справляются с внешними ошибками.
Более подробное описание данного метода/средства приведено в [132 - 136].
В.2.6 Стандарты по проектированию и кодированию
Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.4 (таблица А.4).
B.2.6.1 Общие положения
Цель: упрощение верификации для поддержания группового объективного подхода и установления стандартного метода проектирования.
Описание: в самом начале разработки между участниками создания системы должны быть согласованы необходимые правила. Они охватывают рассмотренные ниже методы проектирования и разработки (например, JSP, MASCOT, сети Петри и т. д.), а также соответствующие стандарты кодирования (см. В.2.6.2 настоящего приложения).
Эти правила создаются для облегчения разработки, верификации, оценки соответствия и эксплуатации. При этом должны учитываться доступные инструментальные средства, в частности для аналитиков, и развитие средств проектирования.
Более подробное описание данного метода/средства приведено в [137].
Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).
Цель: упрощение верификации разработанного кода.
Описание: до выполнения кодирования должны быть полностью согласованы подробные правила, которых следует придерживаться. К этим правилам обычно относят:
- наличие подробных сведений о модульности, например о виде интерфейса, о размерах программных модулей;
- использование инкапсуляции, наследования (ограниченного по глубине) и полиморфизма в случае объектно-ориентированных языков;
- исключение или ограниченное использование некоторых языковых конструкций, например, «goto», «equivalence», динамических объектов, динамических данных, структур динамических данных, рекурсии, указателей и т. п.;
- ограничение прерываний, допустимых при выполнении критичного для безопасности кода;
- распечатывание программного кода (формирование листинга);
- исключение безусловных переходов (например, «goto») в программах на языках высокого уровня.
Эти правила созданы для облегчения процессов тестирования программных модулей, верификации, оценки соответствия и обслуживания. При этом должны учитываться доступные инструментальные средства, в частности для аналитиков.
Примечание - Более подробная информация по этим вопросам приведена в В.2.6.3 - В.2.6.7.
Более подробное описание данного метода/средства приведено в [102, 137 - 142].
B.2.6.3 Отказ от динамических переменных или динамических объектов
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).
Цель: исключение динамических и переменных объектов во избежание:
- нежелательных или необнаруживаемых наложений в памяти;
- узких мест ресурсов в процессе (связанном с безопасностью) выполнения программы.
Описание: в случае применения этого подхода динамические переменные и динамические объекты оказываются переменными и объектами, которые имеют свои определенные и абсолютные адреса в памяти, устанавливаемые во время выполнения программы. Объем распределяемой памяти и ее адреса зависят от состояния системы в момент распределения памяти, а это означает, что они не могут быть проверены компилятором или любым другим автономным инструментом.
Так как число динамических переменных и объектов и существующее свободное пространство памяти для размещения новых динамических переменных или объектов зависят от состояния системы в момент размещения, то возможны сбои при размещении или при использовании переменных или объектов. Например, если объем свободной памяти для распределяемой переменной системы не достаточен, то содержимое другой переменной в памяти может быть нечаянно стерто. Если динамические переменные или объекты не используются, то появление этих сбоев исключено.
B.2.6.4 Проверка создания динамических переменных или динамических объектов при выполнении программы
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).
Цель: убедиться в том, что память, в которой должны быть размещены динамические переменные и объекты, свободна до ее загрузки, гарантируя при этом, что размещение в ней динамических переменных и объектов во время выполнения программы не повлияет на уже существующие в ней переменные, данные или коды.
Описание: в случае применения этих методов/средств к динамическим переменным относят переменные, имеющие свои определенные и абсолютные адреса в памяти, устанавливаемые во время выполнения программы (в этом смысле переменные являются также атрибутами экземпляров объектов).
Аппаратными либо программными средствами память проверяется на то, что она свободна до размещения в ней динамических переменных или объектов (например, для того, чтобы исключить переполнение стека). Если размещение не разрешается (например, если памяти по определенному адресу недостаточно), должны быть предприняты соответствующие действия. После использования динамических переменных или объектов (например, после выхода из подпрограммы) вся используемая ими память должна быть освобождена.
Примечание - Альтернативой служит статическая демонстрация того, что память будет адекватной во всех случаях.
B.2.6.5 Ограниченное использование прерываний
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).
Цель: сохранение верифицируемости и тестируемости ПО.
Описание: использование прерываний должно быть ограничено. Прерывания могут использоваться, если они упрощают систему. Использование программных средств для обработки прерываний должно быть запрещено в критических ситуациях для выполняемых функций (например, при критичности по времени, критичности изменения данных). Если прерывания все же используются, то непрерываемые фрагменты должны иметь определенное максимальное время вычисления, на основании которого определяется максимальное время, в течение которого прерывание запрещено. Использование прерываний и их маскирование должно четко документироваться.
B.2.6.6 Ограниченное использование указателей
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).
Цель: исключение проблем, связанных с доступом к данным без предварительной проверки типа и диапазона указателя; обеспечение возможности модульного тестирования и верификации программных средств; снижение тяжести последствий отказов.
Описание: в прикладных программных средствах указатель арифметических действий может быть использован на уровне исходного кода только в том случае, когда тип и диапазон значений указателя данных будут проверены перед доступом (для гарантирования того, что ссылка указателя находится внутри корректного адресного пространства). Связи между задачами в прикладных программах не должны осуществляться с помощью непосредственных ссылок между задачами. Обмен данными должен осуществляться через операционную систему.
B.2.6.7 Ограниченное использование рекурсий
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.1).
Цель: исключение использования вызовов неверифицируемых и нетестируемых подпрограмм. Описание: при использовании рекурсии должен быть установлен четкий критерий, обеспечивающий предсказуемость глубины рекурсии.
В.2.7 Структурное программирование
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.4).
Цель: проектирование и реализация программы с использованием практического анализа программы без ее выполнения. Программа может содержать только абсолютный минимум статистически нетестируемого поведения.
Описание: для минимизации структурной сложности следует применять следующие принципы и действия:
- разделять программу на подходящие небольшие программные модули, гарантируя при этом, что они являются минимально связанными, насколько возможно, и что все взаимодействия явные;
- составлять поток управления программными модулями с использованием структурированных конструкций, таких как последовательности, итерации и выбор;
- обеспечивать небольшое количество возможных путей через программные модули и как можно более простые отношения между входными и выходными параметрами;
- исключать сложные ветвления и, в частности, исключать безусловные переходы («goto») при использовании языков высокого уровня;
- по возможности, связывать ограничения на цикл и ветвление с входными параметрами;
- исключать использование сложных вычислений в ветвлении и цикле.
Свойства языков программирования, которые способствуют указанному выше подходу, следует использовать, предпочитая их другим свойствам, которые более эффективны, но за исключением тех случаев, когда эффективность приобретает абсолютный приоритет (например, для некоторых критичных к безопасности систем).
Более подробное описание данного метода/средства приведено в [102, 137, 138, 141, 143 - 149].
B.2.8 Ограничение доступа /инкапсуляция информации
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица Б.9).
Цель: предотвращение непреднамеренного доступа к данным или процедурам, и тем самым обеспечение качественной структуры программных средств.
Описание: общедоступные для всех программных компонентов данные могут быть случайно или некорректно модифицированы любым из этих компонентов. Любые изменения этих структур данных могут потребовать подробной проверки программного кода и серьезных исправлений.
Ограничение доступа представляет собой общий подход к минимизации указанных проблем. Ключевые структуры данных «скрыты», и с ними можно работать, только применив определенный набор процедур доступа. Это позволяет модифицировать внутренние структуры или добавлять новые процедуры, не оказывая влияния при этом на функциональное поведение остальных программных средств. Например, имя директории может иметь процедуры доступа «вставить», «удалить» и «найти». Процедуры доступа и структуры внутренних данных могут быть изменены (например, при использовании различных методов просмотра или для сохранения имен на жестком диске), не оказывая влияния на логическое поведение остальных программных средств, использующих эти процедуры.
В таком случае следует использовать концепцию абстрактных типов данных. Если непосредственная проверка не предусмотрена, может оказаться необходимой проверка того, что абстрагирование не было непреднамеренно разрушено.
Более подробное описание данного метода/средства приведено в [150, 151].
B.2.9 Модульный подход
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблицы А.4 и Б.9).
Цель: декомпозиция программной системы на небольшие ясные для понимания модули для упрощения системы.
Описание: модульный подход, или модуляризация, включает в себя несколько различных правил для стадий проектирования, кодирования и эксплуатации разработанных программных средств. Эти правила меняются в соответствии с реализуемым методом проектирования. Большинство же методов содержат следующие правила:
- программный модуль должен выполнять одну четко сформулированную задачу или функцию;
- связи между программными модулями должны быть ограничены и строго определены, уровень связанности каждого программного модуля должен быть высоким;
- совокупности подпрограмм должны строиться так, чтобы обеспечивать несколько уровней программных модулей;
- размеры подпрограмм следует ограничить некоторыми конкретными значениями, обычно от двух до четырех размеров экрана.
- подпрограммы должны иметь только один вход и один выход;
- программные модули должны взаимодействовать с другими программными модулями через свои интерфейсы, где используются глобальные или общие переменные, которые должны быть хорошо структурированы, доступ к ним должен быть контролируемым и их использование в каждом конкретном случае должно быть обосновано;
- все интерфейсы программных модулей должны быть полностью документированы;
- все интерфейсы программных модулей должны содержать только те параметры, которые необходимы для их функционирования.
Более подробное описание данного метода/средства приведено в [70, 138, 152].
В.2.10 Использование заслуживающих доверия/проверенных программных модулей и их компонентов
Примечания
1 На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.4).
2 Некоторые математические методы, обеспечивающие последующие численные оценки, приведены в приложении Г. Аналогичные средства и статистический подход изложены также в Б.5.4.
Цель: исключение вариантов проектирования компонентов программных модулей и АС, предусматривающих необходимость их интенсивных повторных проверок или перепроектирования для каждого нового применения; использование преимуществ проектов, которые не были формально или строго проверены, но для которых имеются продолжительные эксплуатационные предыстории.
Описание: применение таких модулей и компонентов гарантирует, что программные модули и компоненты достаточно свободны от систематических ошибок проектирования и/или эксплуатационных отказов. Использование заслуживающих доверия программных модулей и компонентов (то есть проверенных в эксплуатации) может быть достаточным в качестве единственной меры, гарантирующей достижение необходимого уровня полноты безопасности, лишь в редких случаях. Для сложных компонентов со многими возможными функциями (например, операционной системы) важно установить, какая из функций реально достаточно проверена при ее использовании. Например, в тех случаях, когда используется процедура самотестирования для обнаружения сбоев АС и когда в период эксплуатации никаких отказов АС не случилось, процедуру самотестирования на обнаружение сбоев нельзя рассматривать как проверенную на практике.
Компонент или программный модуль может быть в достаточной мере заслуживающим доверия, если он уже проверен для требуемого уровня полноты безопасности или если он соответствует следующим критериям:
- спецификация не изменялась;
- системы использовались в различных применениях;
- имеется по меньшей мере один год предыстории работы;
- время эксплуатации соответствует уровню полноты безопасности или соответствующему числу запросов; демонстрируются не связанные с безопасностью частоты отказов, меньшие чем:
- 10~2 отказов на запрос (в год) с уверенностью 95 % при требуемом числе эксплуатационных прогонов (в год) 30;
- 10~5 отказов на запрос (в год) с уверенностью 99,9 % при требуемом числе эксплуатационных прогонов (в год) 690 000;
- весь опыт эксплуатации должен быть соотнесен с известным профилем запросов функций программного модуля для гарантирования того, что увеличивающийся опыт эксплуатации действительно приводит к увеличению сведений о поведении программного модуля, связанного с соответствующим профилем запроса;
- отказы, не связанные с безопасностью.
Примечание - Отказ, который может быть некритичным для безопасности в одном контексте, может оказаться критичным для безопасности в другом контексте, и наоборот.
Чтобы обеспечить достоверность того, что компонент или программный модуль соответствует критерию, должно быть задокументировано следующее:
-точная идентификация каждой системы и ее компонентов, включая номера версий (как для ПО, так и для АС);
- идентификация пользователей и время применения;
- время эксплуатации;
- процедура выбора систем, применяемых пользователями, и случаев применения;
- процедуры обнаружения и регистрации отказов и устранения сбоев.
Более подробное описание данного метода/средства приведено в [148, 150, 153].
В.3 Структурное проектирование
В.3.1 Обнаружение и диагностика сбоев
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обнаружение сбоев в системе, которые могут привести к отказам, и тем самым обеспечение основы для мер по минимизации последовательностей ошибок.
Описание: обнаружение сбоев представляет собой действие по проверке системы на наличие ошибочных состояний (обусловленных сбоями в проверяемой системе или подсистеме), предпринимаемое для предотвращения появления неверных результатов. Система, действующая в сочетании с параллельными компонентами, останавливающая управление при обнаружении некорректности ее собственных результатов, называется самопроверяемой.
Обнаружение сбоев основывается на принципах избыточности (в основном при обнаружении сбоев АС - см. ГОСТ Р 53195.3, приложение А) и разнообразия (программные сбои). Для определения корректности результатов требуется некоторый вид голосования. Могут быть применены определенные специальные методы, к которым относятся: программирование утверждений, метод программирования N-версий и так называемая «подушка безопасности» (см. В.3.4 настоящего приложения); а для АС - применение дополнительных сенсоров, контуров регулирования, кодов, обнаруживающих ошибки, и др.
Обнаружение сбоев может обеспечиваться проверками в области значений или во временной области на различных уровнях, особенно на физическом уровне (температура, напряжение и т. п.), на логическом (коды, обнаруживающие ошибки), на функциональном (утверждения) или на внешнем (проверки достоверности) уровне. Результаты этих проверок могут быть сохранены и увязаны с влияющими данными для обеспечения возможности отслеживания отказов.
Сложные системы состоят из подсистем. Эффективность обнаружения сбоев, диагностики и компенсации сбоев зависит от сложности взаимодействия между подсистемами, которые влияют на распространение сбоев.
Диагностику сбоев следует применять на уровне самых малых подсистем, поскольку подсистемы меньших размеров допускают более детальную диагностику сбоев (обнаружение ошибочных состояний).
Интегрированные информационные системы (например, уровня предприятия) могут обычным способом передавать состояния безопасности системы, включая информацию диагностического тестирования, другим управляющим системам. При обнаружении некорректного поведения оно может быть выделено и использовано для запуска корректирующих действий до возникновения опасной ситуации. В конце концов, при появлении инцидента документирование таких отклонений может способствовать последующему анализу.
Более подробное описание данного метода/средства приведено в [153].
B.3.2 Обнаружение и исправление ошибок
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обнаружение и исправление ошибок в чувствительной к ним информации.
Описание: для информации, состоящей из п битов, генерируется закодированный блок из k битов, который позволяет обнаруживать и исправлять r ошибок. Примерами служат код Хэмминга и полиномиальные коды.
Следует заметить, что в системах, связанных с безопасностью, лучше уничтожить ошибочные данные, чем пытаться исправлять их, поскольку лишь заранее определенная часть ошибок может быть правильно исправлена.
Более подробное описание данного метода/средства приведено в [154].
B.3.3 Программирование с проверкой ошибок
Примечание -На этот метод/средство дана ссылка в ГОСТ Р 53195.3 (таблица А.18) и в ГОСТР 53195.4 (таблица А.2).
Цель: обнаружение ошибок, оставшихся при проектировании ПО в процессе выполнения программ для предотвращения критичных для безопасности отказов систем и продолжения выполнения программы с высокой надежностью.
Описание: в методе программирования утверждений заложена идея проверки предусловий (до выполнения последовательности операторов начальные условия проверяются на соответствие) и постусловий (проверяются результаты после выполнения последовательности операторов). Если предусловия или постусловия не соблюдаются, то выдается сообщение об ошибке.
Более подробное описание данного метода/средства приведено в [155 - 157].
B.3.4 Методы «подушки безопасности»
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: защита от необнаруженных на этапах спецификации и реализации ошибок в ПО, неблагоприятно влияющих на безопасность.
Описание: «подушка безопасности» представляет собой внешний монитор, реализованный на независимом компьютере в другой спецификации. Эта «подушка безопасности» касается исключительно гарантии того, чтобы главный компьютер выполнял безопасные, не обязательно корректирующие, действия. Она непрерывно контролирует главный компьютер. «Подушка безопасности» предотвращает вхождение системы в небезопасное состояние. Кроме того, если обнаружится, что главный компьютер вошел в потенциально опасное состояние, система должна возвратиться обратно в безопасное состояние с помощью либо «подушки безопасности», либо главного компьютера.
АС и ПО «подушки безопасности» следует классифицировать и квалифицировать в соответствии с подходящим уровнем полноты безопасности SIL.
Более подробное описание данного метода/средства приведено в [158 - 160].
B.3.5 Многовариантное программирование
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обнаружение и наложение маски при выполнении программ на не выявленные на этапах проектирования и реализации ошибки ПО для предотвращения критичных для безопасности отказов системы и для продолжения ее работы с высокой надежностью.
Описание: при многовариантном программировании заданная спецификация ПО проектируется и реализуется различными способами N раз. Одни и те же входные значения поступают в N версий, и результаты, выданные N версиями, сравниваются. Если определяется, что результат правильный, он поступает на выходы компьютера.
N версий могут выполняться параллельно на различных компьютерах, либо все версии могут выполняться на одном и том же компьютере, и результаты будут обработаны внутренним голосованием. Для этих N результатов в зависимости от применяемых требований могут быть использованы различные стратегии голосования следующим образом:
- если система находится в безопасном состоянии, можно потребовать полного согласия (все N согласны), в противном случае используется выходное значение, которое заставит систему перейти в безопасное состояние. Для простых пошаговых систем голосование может происходить в направлении безопасности. В этом случае безопасное действие может быть разбито по шагам, если какая-либо версия реализует пошаговые операции. Этот подход обычно используется только для двух версий (N = 2);
- для систем, находящихся в небезопасном состоянии, могут быть реализованы стратегии мажоритарного голосования. В тех случаях, когда отсутствует общее согласие, могут использоваться вероятностные подходы, с тем чтобы максимизировать вероятность выбора правильного значения, например принять среднее значение, временно зафиксировать выходы, пока не будет достигнуто согласие, и т. п.
Этот метод не устраняет ошибки, не выявленные при проектировании программ, а также не устраняет ошибки в интерпретации спецификации, однако он является средством для обнаружения и маскирования ошибок, прежде чем они смогут повлиять на безопасность.
Более подробное описание данного метода/средства приведено в [160 - 162].
B.3.6 Блоки восстановления
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: повышение вероятности выполнения программой своих заданных функций.
Описание: некоторые различные разделы программы, часто разработанные независимо, предназначены для выполнения одной и той же требуемой функции. Окончательная программа конструируется из таких разделов. Первый раздел, называемый первичным, выполняется первым. Далее происходит тестирование его результатов. Если тест проходит, результат принимается и передается последующим разделам программы. Если тест не проходит, то все побочные эффекты первого раздела сбрасываются и выполняется второй раздел, называемый первой альтернативой. За ним также следует тест, который выполняется, как и в первом случае. При необходимости могут быть предусмотрены вторая, третья и так далее альтернативы.
B.3.7 Восстановление предыдущего состояния
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обеспечение исправления функциональных операций при наличии одного или нескольких сбоев.
Описание: при обнаружении сбоя система возвращается в первоначальное внутреннее состояние, согласованность которого была подтверждена ранее. Этот метод предполагает частое сохранение внутреннего состояния в так называемых четко определенных контрольных точках. Метод может быть применен глобально (для всей базы данных) или частично (для изменений только между контрольными точками). По завершении операции система должна устранить изменения, которые произошли за это время, путем занесения в журнал (аудиторское отслеживание действий), компенсацией (все результаты этих изменений аннулируются) или внешним (ручным) способом.
Более подробное описание данного метода/средства приведено в [163, 164].
B.3.8 Прямое восстановление функций
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обеспечение исправления функциональных операций при наличии одного или нескольких сбоев.
Описание: при обнаружении сбоя текущее состояние системы обрабатывается для достижения состояния, которое через некоторое время будет согласовано. Эта концепция особенно подходит для систем реального времени с небольшой базой данных и с высокой скоростью изменения внутреннего состояния. Предполагается, что по меньшей мере часть системного состояния может влиять на окружение, и только на часть системных состояний влияет окружение.
Более подробное описание данного метода/средства приведено в [165].
B.3.9 Методы повторных попыток восстановления неисправностей
Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53185.4 (таблица А.2).
Цель: функциональное восстановление системы из состояния обнаруженного сбоя с помощью методов повторных попыток.
Описание: в случае обнаружения сбоя или ошибочного условия предпринимаются попытки восстановления ситуации путем повторного выполнения того же кода. Восстановление с помощью повторной попытки может быть полным в виде перезагрузки и повторного пуска процедуры, либо небольшим в виде перепланирования и повторного пуска задачи после выполнения блокировки по времени программы или управляющего действия задачи. Методы повторной попытки широко используются при коммуникационных сбоях или при восстановлении от ошибок, и условия повторной попытки могут быть отделены флажками от ошибки протокола связи (контрольная сумма и т. д.) или от подтверждающего ответа блокировки по времени коммуникации.
Более подробное описание данного метода/средства приведено в [165].
B.3.10 Сохранение достигнутых состояний
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: заставить программу безопасно прекратить работу, если она попытается выполнить неразрешенное действие.
Описание: все соответствующие подробные сведения о каждом выполнении программы документируются. При нормальной работе каждое выполнение программы сравнивается с ранее задокументированными сведениями. При обнаружении различий выполняются действия по безопасности.
Документация о выполнении может содержать последовательность индивидуальных шагов «от решения к решению», или последовательность отдельных обращений к массивам, записям или томам, либо к тому и другому.
Возможны различные методы хранения сведений о последовательностях шагов выполнения программы. Могут быть использованы методы хэш-кодирования для отображения этих последовательностей в виде одного большого числа или последовательности чисел. При нормальной работе перед выполнением выходной операции значения чисел, отображающих последовательности шагов выполнения программы, должны быть сопоставлены со значениями, сохраненными в памяти.
Поскольку возможные комбинации таких последовательностей шагов при выполнении одной программы получаются достаточно большими, может оказаться невозможным рассматривать программы как единое целое. В этом случае метод может быть применен на уровне программных модулей.
B.3.11 Постепенное отключение функций
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обеспечение возможности выполнения наиболее критичных системных функций, несмотря на отказы, путем игнорирования наименее критичных функций.
Описание: этот метод предоставляет приоритеты различным функциям, выполняемым системой. Проект гарантирует, что в случае недостаточности ресурсов для выполнения всех системных функций функции высшего приоритета будут выполнены в предпочтение функциям более низкого приоритета. Например, функции регистрации ошибки и события могут оказаться более низкого приоритета, чем системные функции управления, и в этом случае управление системой будет продолжаться, даже если аппаратные средства из-за регистрации ошибки окажутся неработоспособными. Более того, если аппаратные средства управления системой окажутся неисправными, а аппаратные средства регистрации ошибок останутся работоспособными, то аппаратные средства регистрации ошибок возьмут на себя функцию управления.
Эти соображения относятся в основном к аппаратным средствам, но они применимы также и ко всей СБЗС-системе. Они должны учитываться начиная с самых ранних этапов проектирования.
Более подробное описание данного метода/средства приведено в [166 - 168].
B.3.12 Исправление ошибок методами искусственного интеллекта
Примечание - На эти методы/средства дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обеспечение способности системы гибко реагировать на возможные опасности с использованием сочетания методов данных, модели процессов и анализа надежности СБЗС-системы.
Описание: прогнозирование ошибок (вычисление трендов), исправление ошибок, техническое обслуживание и контролирующие действия могут быть с большой эффективностью поддержаны системами, основанными на искусственном интеллекте, в различных каналах СБЗС-системы, поскольку правила ее поведения могут быть получены непосредственно из спецификации и проверены на соответствие им.
Для различных каналов связи системы прогнозирование ошибок (вычисление тенденций), исправление ошибок, обслуживание и контролирующие действия могут достаточно эффективным способом поддерживаться системами, основанными на методах искусственного интеллекта (AI). Это связано с тем, что правила для таких систем могут быть образованы непосредственно из спецификаций и проверены на соответствие. На основе этого подхода могут быть эффективно исключены некоторые общие ошибки, уже внесенные в спецификацию, путем косвенного изучения некоего уже имеющегося проекта и получения представления о возможных правилах поведения системы, особенно в случае применения комбинации моделей и методов в функциональной и описательной формах.
Методы выбираются таким образом, что ошибки могли быть устранены и влияние отказов могло быть минимизировано для получения требуемой полноты безопасности.
Примечание - Должны быть учтены предупреждения об исправлении ошибочных данных, приведенные в В.3.2, и об отрицательных рекомендациях применения этого метода, приведенные в ГОСТ Р 53195.4 (таблица А.2, пункт 5).
Более подробное описание данного метода/средства приведено в [169].
В.3.13 Динамическая реконфигурация
Примечание - На этот метод/средство дана ссылка в ГОСТ Р 53195.4 (таблица А.2).
Цель: обеспечение функционирования системы, несмотря на внутренний сбой.
Описание: логическая архитектура системы должна быть такой, чтобы ее можно было отобразить в подмножестве доступных ресурсов системы. Архитектура должна быть способна к обнаружению отказа на физическом уровне и далее к повторному преобразованию логической архитектуры в ограниченные функционирующие ресурсы. Несмотря на то что эта концепция, в основном, традиционно ограничена только восстановлением неисправных модулей АС, она применима также к сбоям в ПО при наличии достаточной «избыточности времени прогона» для повторного выполнения программы или наличии достаточных избыточных данных, которые обеспечивают незначительное влияние отдельного и изолированного отказа.
Этот метод должен рассматриваться на первом этапе проектирования системы.
Более подробное описание данного метода/средства приведено в [169].
В.4 Инструменты разработки и языки программирования
B.4.1 Строго типизированные языки программирования
Примечание - Ссылка на данные методы/средства приведена в ГОСТ Р 53195.4 (таблица А.3).
Цель: снижение вероятности ошибок путем использования языка, который обеспечивает высокий уровень проверки компилятором.
Описание: если скомпилирован строго типизированный язык программирования, то проводится много проверок по использованию типов переменных, например в вызовах процедур и доступе к внешним данным. Компиляция может оказаться безуспешной, и будет выдано сообщение об ошибке при любом использовании типа переменных, которое не соответствует заранее установленным правилам.
Подобные языки обычно позволяют определять установленные пользователем типы данных на основе типов данных базового языка (например, целое число, реальное число). Затем эти типы могут быть использованы также, как и базовый тип. Вводятся строгие проверки для гарантирования использования правильного типа. Эти проверки проводятся для всей программы, даже если она построена из отдельных скомпилированных модулей. Данные проверки гарантируют также, что число и тип аргументов конкретной процедуры соответствуют числу и типу аргументов при ее вызове, даже если к ней обращаются из отдельно скомпилированных программных модулей.
Строго типизированные языки обычно обеспечивают другие аспекты проверенной на практике техники проектирования ПО, например легко анализируемые структуры управления («if», «then», «else», «do», «while» и т. п.), которые приводят к четко структурированным программам.
Типичными примерами строго типизированных языков являются С ++, Delphi, Java, ML, Pascal, ADA, Modula 2.
Более подробное описание данного метода/средства приведено в [170 - 173].
B.4.2 Подмножество языка
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.3).
Цель: снижение вероятности внесения программных ошибок и повышение вероятности обнаружения оставшихся ошибок.
Описание: проводится исследование языка для определения программных конструкций, подверженных ошибкам либо сложных для анализа, например при использовании методов статического анализа. После этого определяется языковое подмножество, которое исключает такие конструкции.
Более подробное описание данного метода/средства приведено в [173].
B.4.3 Сертифицированные средства
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.3).
Цель: предоставление разработчику на различных этапах разработки ПО необходимых сертифицированных инструментальных средств для обеспечения конкретной степени уверенности в корректности результатов.
Описание: сертификацию инструментальных средств в общем случае допускается проводить независимо, как правило, в национальных органах по сертификации по независимому набору критериев, установленных обычно в национальных или международных стандартах. В идеальном случае инструментальные средства, применяемые на всех стадиях разработки (спецификация, проектирование, кодирование, тестирование и оценка соответствия), а также используемые в управлении конфигурацией, должны быть сертифицированы.
В настоящее время регулярным процедурам сертификации подвергаются только компиляторы (трансляторы); сертификация проводится национальными органами по сертификации. Она заключается в проверке компиляторов (трансляторов) на соответствие национальным (международным) стандартам, например, для языков ADA или Pascal и в подтверждении соответствия.
Важно отметить, что сертифицированные инструментальные средства и сертифицированные трансляторы обычно сертифицируются только на соответствие стандартам на определенный язык или процесс. Обычно они никак не сертифицируются на соответствие стандартам по безопасности.
Более подробное описание данного метода/средства приведено в [174, 175].
B.4.4 Инструментальные средства, заслуживающие доверия на основании опыта использования
Примечание - Ссылка на данные методы/средства приведена в ГОСТ Р 53195.4 (таблица А.3).
Цель: исключение проблем, обусловленных ошибками транслятора, которые могут появиться во время разработки, верификации и эксплуатации ПО.
Описание: транслятор используется в тех случаях, когда неправильное исполнение многих предыдущих проектов неочевидно. Если отсутствует опыт эксплуатации трансляторов или в них обнаружены любые известные серьезные ошибки, то от таких трансляторов следует отказаться при отсутствии других гарантий корректной работы транслятора (см. В.4.4.1).
Если в трансляторе выявлены небольшие недостатки, то соответствующие языковые конструкции фиксируются и в проектах СБЗС-систем не применяются.
Другим вариантом исключения проблем, обусловленных ошибками транслятора, является ограничение языка до конструкций, признанных общепринятыми.
Доказано, что недоработанные трансляторы служат серьезным препятствием в любой разработке ПО. Такие трансляторы в общем случае делают невозможной разработку ПО СБЗС-систем.
В настоящее время не существует методов подтверждения корректности всего транслятора или отдельных его частей.
B.4.5 Сравнение исходных программ и исполнимых кодов
Цель: удостовериться в том, что инструменты, используемые для создания образа PROM, не вносят в него никаких ошибок.
Описание: образ PROM преобразуется обратно в совокупность «объектных» модулей, а эти «объектные» модули преобразуются обратно в скомпонованные файлы языка, которые затем с помощью подходящих методов сравниваются с фактическими исходными файлами, первоначально использованными для разработки PROM.
Основное преимущество данного метода состоит в том, что инструменты (компиляторы, редакторы связей (компоновщики) и т. п.), используемые для разработки образа PROM, не требуют подтверждения соответствия. Этим методом проверяют правильность преобразования исходного файла, используемого для конкретной СБЗС-системы.
Более подробное описание данного метода/средства приведено в [176 - 178].
B.4.6 Библиотека проверенных/верифицированных модулей и компонентов
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.3).
Цель: исключение необходимости многократных повторных проверок или перепроектирования компонентов ПО и АС при каждом новом применении; содействие созданию проектов, которые не были формально или строго проверены, но относительно которых имеется значительная предыстория эксплуатации.
Описание: хорошо спроектированные и структурированные СБЗС-системы строятся из множества компонентов и модулей АС и ПО, которые четко различаются и которые взаимодействуют друг с другом строго специфицированным способом.
Различные СБЗС-системы, созданные для различных применений, могут содержать большое число одинаковых или очень схожих между собой программных модулей или компонентов. Создание библиотеки таких общеприменимых программных модулей позволяет использовать большую часть ресурсов, необходимых для подтверждения соответствия проекта, одновременно для нескольких применений.
Кроме того, использование подобных программных модулей для многих применений дает практическое подтверждение их успешной эксплуатации. Это практическое подтверждение увеличивает доверие пользователей к программным модулям.
Один из подходов, в соответствии с которым программному модулю можно доверять при его практическом использовании, описан в В.2.10.
Более подробное описание данного метода/средства приведено в [179, 180].
B.4.7 Выбор соответствующего языка программирования
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.3).
Цель: обеспечение в максимальной степени требований настоящего стандарта для специального защищающего программирования, строгой типизации, структурного программирования и, возможно, суждений. Выбранный язык программирования должен обеспечить легко верифицируемый код и простые процедуры разработки, верификации и эксплуатации ПО.
Описание: язык программирования должен быть полностью и однозначно определен. Язык должен быть ориентирован на пользователя или задачу, а не на процессор или платформу. Широко используемые языки программирования или их подмножества должны быть предпочтительнее языков специального применения.
Языки программирования также должны обеспечивать:
- блоковую структуру организации программ;
- проверку времени трансляции;
- проверку типа и границы массива во время выполнения программы. Язык программирования должен обеспечивать:
- использование небольших и управляемых программных модулей;
- ограничение доступа к данным в конкретных программных модулях;
- определение поддиапазонов переменных;
- любые другие виды конструкций, ограничивающих ошибки.
Если действия системы по обеспечению безопасности зависят от ограничений реального времени, то язык программирования должен обеспечивать также обработку исключений и/или прерываний.
Желательно, чтобы язык программирования обеспечивался соответствующим транслятором, подходящими библиотеками с заранее созданными программными модулями, отладчиком и инструментами для управления и разработки.
В настоящее время еще не ясно, будут ли объектно-ориентированные языки программирования предпочтительнее других общепринятых языков.
К свойствам, которые усложняют верификацию и поэтому должны быть исключены, относятся:
- безусловные переходы (за исключением вызовов подпрограмм);
- рекурсии;
- указатели, динамически распределяемые области памяти или любые типы динамических переменных или объектов;
- обработка прерываний на уровне исходного кода;
- множественность входов или выходов в циклах, блоках или подпрограммах;
- инициализация или декларация неявных переменных;
- вариантные записи и эквивалентность;
- процедурные параметры.
Языки программирования низкого уровня, в частности ассемблеры, обладают недостатками, связанными с их жесткой ориентацией на процессор машины или на определенную платформу.
Желательным свойством языка программирования является его пригодность к созданию программ, выполнение которых предсказуемо. Если используется подходящий конкретный язык программирования, то в нем должно существовать подмножество, которое гарантирует, что выполнение программы предсказуемо. Это подмножество не может быть (в общем случае) статически определено, несмотря на то что многие статические ограничения помогают гарантировать предсказуемое выполнение. Обычно это может потребовать демонстрацию того, что индексы массива находятся в установленных пределах и что числовое переполнение не может возникнуть, и т. п.
Рекомендации по применению некоторых языков программирования приведены в таблице В.3. Обозначения рангов применимости языков программирования следующие:
КР (HR) - крайне рекомендуемый для данного уровня полноты безопасности. Если его не используют, то на этапе планирования должно быть дано подробное обоснование отказа от его применения, согласованное с экспертом;
Р (R) - рекомендуемый для данного уровня полноты безопасности. Степень обязательности его применения ниже, чем в случае рекомендации КР (HR);
- - отсутствие рекомендаций по применению или неприменению;
HP (NR) - нерекомендуемый к применению для данного уровня полноты безопасности. Если его применяют, то на стадии планирования должно быть приведено подробное обоснование его применения, согласованное с экспертом.
Таблица В.3 - Рекомендации по применению языков программирования
Ранг применимости языка для |
||||
SIL1 |
SIL2 |
SIL3 |
SIL4 |
|
1 ADA |
КР (HR) |
КР (HR) |
P(R) |
P(R) |
2 ADA с подмножеством |
КР (HR) |
КР (HR) |
КР (HR) |
КР (HR) |
3 MODULA-2 |
КР (HR) |
КР (HR) |
P(R) |
P(R) |
4 MODULA с подмножеством |
КР (HR) |
КР (HR) |
КР (HR) |
КР (HR) |
5 PASCAL |
КР (HR) |
KP (HR) |
P(R) |
P(R) |
6 PASCAL с подмножеством |
КР (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
7 FORTRAN 77 |
P(R) |
P(R) |
P(R) |
P(R) |
8 FORTRAN 77 с подмножеством |
КР (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
9 С |
P(R) |
- |
HP (NR) |
HP(NR) |
10 Язык С с подмножеством и стандартом кодирования, а также использование инструментов статического анализа |
КР (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
11 PL/M |
P(R) |
- |
HP (NR) |
HP(NR) |
12 PL/M с подмножеством и стандартом кодирования |
КЗ (HR) |
P(R) |
P(R) |
P(R) |
13 Ассемблер |
P(R) |
P(R) |
- |
- |
14 Ассемблер с подмножеством и стандартом кодирования |
P(R) |
P(R) |
P(R) |
P(R) |
15 Многоступенчатые диаграммы |
P(R) |
P(R) |
P(R) |
P(R) |
16 Многоступенчатая диаграмма с определенным подмножеством языка |
КР (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
17 Диаграмма функциональных блоков |
P(R) |
P(R) |
P(R) |
P(R) |
18 Диаграмма функциональных блоков с определенным подмножеством языка |
КР (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
19 Структурированный текст |
P(R) |
P(R) |
P(R) |
P(R) |
20 Структурированный текст с определенным подмножеством языка |
КР (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
21 Последовательная функциональная диаграмма |
P(R) |
P(R) |
P(R) |
P(R) |
22 Последовательная функциональная диаграмма с определенным подмножеством языка |
KP (HR) |
KP (HR) |
KP (HR) |
KP (HR) |
23 Список команд |
P(R) |
- |
HP (NR) |
HP(NR) |
24 Список команд с определенным подмножеством языка |
KP (HR) |
P(R) |
P(R) |
P(R) |
Примечания 1 Системное программное обеспечение включает в себя операционную систему, драйверы, встроенные функции и программные модули, являющиеся частью системы. ПО обычно обеспечивается поставщиком СБЗС-систем (подсистем). Подмножество языка следует выбирать очень внимательно, с тем чтобы исключить сложные структуры, которые могут образоваться в результате ошибок реализации. Следует проводить проверки, чтобы убедиться в правильном использовании подмножества языка программирования. 2 Прикладная программа представляет собой программу, разработанную для конкретного применения СБЗС-системы. Во многих случаях такая программа разрабатывается конечным пользователем либо подрядчиком, ориентированным на разработку прикладных программ. В тех случаях, когда ряд языков программирования поддерживают одни и те же рекомендации, разработчику следует выбрать тот язык, который повсеместно используется персоналом в конкретной промышленности или отрасли. Подмножество языка программирования следует выбирать с особым вниманием, чтобы исключить сложные структуры, которые могут привести к ошибкам реализации. 3 Если конкретный язык программирования не представлен в настоящей таблице, то это не означает, что он исключен. Этот конкретный язык программирования должен соответствовать требованиям настоящего стандарта. 4 О пунктах 15 - 24 см. ГОСТ Р 53195.4. |
Более подробное описание данного метода/средства приведено в [181].
В.5 Верификация и модификация
B.5.1 Вероятностное тестирование
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы А.5, А.7 и А.9).
Цель: получение количественных показателей надежности исследуемой программы. Описание: количественные показатели могут быть получены с учетом относительных уровней доверия и значимости. В их состав входят:
- вероятность ошибки при запросе;
- вероятность ошибки в течение определенного периода времени;
- вероятность последствий ошибки.
Из этих показателей могут быть получены другие показатели, например:
- вероятность безошибочной работы;
- вероятность живучести; -доступность;
- среднее время наработки на отказ (MTBF) или частота отказов;
- вероятность безопасного исполнения.
Вероятностные показатели основываются либо на статистических испытаниях, либо на опыте эксплуатации. Как правило, число тестовых примеров или наблюдаемых практических примеров очень велико. Обычно тестирование в режиме запросов занимает значительно меньше времени, чем в непрерывном режиме работы.
Для формирования входных данных тестирования и управления выходными данными тестирования обычно используются инструменты автоматического тестирования. Крупные тесты прогоняются на больших центральных компьютерах с имитацией соответствующей периферии. Тестируемые данные выбираются с учетом как систематических, так и случайных ошибок АС. Например, общее управление тестированием гарантирует профиль тестируемых данных, тогда как случайный выбор тестируемых данных может управлять отдельными тестовыми примерами более детально.
Индивидуальные средства для тестирования, выполнение тестирования и управление тестированием определяются детализированными целями тестирования. Другие важные условия задаются математическими предпосылками, которые должны быть соблюдены, если оценка тестирования удовлетворяет заданным целям тестирования.
Из опыта эксплуатации также могут быть получены вероятностные представления поведения любого тестируемого объекта. Если соблюдаются одинаковые условия, то к оценкам результатов тестирования может быть применен одинаковый математический аппарат.
При использовании этих методов достаточно сложно продемонстрировать на практике сверхвысокие уровни надежности.
Более подробное описание данного метода/средства приведено в [182, 183].
B.5.2 Регистрация и анализ данных
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы А.5 и А.8).
Цель: документирование всех данных, решений и разумного обоснования программных проектов для обеспечения верификации, оценки, подтверждения соответствия и эксплуатации.
Описание: в процессе всего проектирования разрабатывается подробная документация, в которую входят:
- тестирование, выполняемое на каждом программном модуле;
- решения и их обоснования;
- проблемы и их решения.
В процессе проектирования и по завершении проекта эта документация может быть проанализирована на наличие широкого набора информации. В частности, такая информация, использовавшаяся в качестве обоснования при принятии конкретных решений в процессе разработки проекта и очень важная для обслуживания вычислительных систем, не всегда известна инженерам по эксплуатации.
Более подробное описание данного метода/средства приведено в [184].
B.5.3 Тестирование интерфейса
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.5).
Цель: обнаружение ошибок в интерфейсах подпрограмм.
Описание: возможно применение нескольких уровней детализации или полноты тестирования. К наиболее важным уровням относится тестирование:
- всех интерфейсных переменных с их предельными значениями;
- всех отдельных интерфейсных переменных с их предельными значениями с другими интерфейсными переменными с их нормальными значениями;
- всех значений предметной области каждой интерфейсной переменной с другими интерфейсными переменными с их нормальными значениями;
- всех значений всех переменных в разных комбинациях (возможно только для небольших интерфейсов);
- каждого вызова каждой подпрограммы, уместного при специфицированных условиях тестирования.
Эти тестирования особенно важны, если интерфейсы не обладают способностью обнаруживать неправильные значения параметров. Такие тестирования также важны при генерации новых конфигураций ранее существовавших подпрограмм.
Более подробное описание данного метода/средства приведено в [185].
B.5.4 Анализ граничных значений
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы Б.2, Б.3 и Б.8).
Цель: обнаружение программных ошибок при предельных и граничных значениях параметров.
Описание: предметная входная область программы разделяется на множество входных классов в соответствии с отношениями эквивалентности (см. В.5.7). Тестирование должно охватывать границы и экстремальные значения классов. Данное тестирование проверяет совпадение границы предметной входной области в спецификации с границами, установленными программой. Использование нулевого значения в непосредственных и в косвенных преобразованиях часто приводит к ошибкам. Особого внимания требуют:
- нулевой делитель;
- знаки пробела ASCII;
- пустой стек или элемент списка;
- заполненная матрица;
- ввод нулевой таблицы.
Обычно границы входных значений напрямую соотносятся с границами выходных значений. Для установления выходных параметров в их предельные значения необходимо записывать специальные тестовые примеры. Следует также по возможности рассмотреть спецификацию такого тестового примера, который побуждает выходное значение превысить установленные спецификацией граничные значения.
Если выходные значения являются последовательностью данных, например таблица, то особое внимание следует уделить первому и последнему элементам, а также спискам, содержащим либо ни одного, либо один, либо два элемента.
Более подробное описание данного метода/средства приведено в [186].
B.5.5 Предположение ошибок
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы Б.2 и Б.8).
Цель: исключение ошибки программирования.
Описание: опыт тестирования и интуиция в сочетании со сведениями и заинтересованностью относительно тестируемой системы могут добавить некоторые неклассифицированные тестовые примеры к набору заданных тестовых примеров.
Специальные значения или комбинации значений могут быть подвержены ошибкам. Некоторые вызывающие интерес тестовые примеры могут быть получены из анализа контрольных списков. Следует также рассмотреть, является ли система достаточно устойчивой. Например: следует ли нажимать клавиши на передней панели слишком быстро или слишком часто; что произойдет, если две клавиши нажать одновременно.
Более подробное описание данного метода/средства приведено в [187].
B.5.6 Введение ошибок
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.2).
Цель: подтверждение адекватности набора тестовых примеров.
Описание: некоторые известные типы ошибок вводятся (подмешиваются) в программу, и программа выполняется с тестовыми примерами в режиме тестирования. При обнаружении только некоторых подмешанных ошибок тестовый пример становится неадекватным. Отношение числа обнаруженных подмешанных ошибок к общему числу подмешанных ошибок оценивается как отношение числа обнаруженных реальных ошибок к общему числу реальных ошибок. Это дает возможность оценить число остаточных ошибок и, тем самым, остальную работу по тестированию.
Обнаружение всех подмешанных ошибок может указывать либо на адекватность тестового примера, либо на то, что подмешанные ошибки было слишком легко найти. Ограничениями данного метода являются: порядок получения любых полезных результатов, типы ошибок. Также необходимо, чтобы позиции подмешивания ошибок отражали статистическое распределение реальных ошибок.
Более подробное описание данного метода/средства приведено в [186 - 189].
B.5.7 Классы эквивалентности и разделенное тестирование входов
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы Б.2 и Б.3).
Цель: адекватное тестирование программных средств с использованием минимума тестируемых данных. Тестируемые данные образуются путем выбора частей входных данных предметной области, требующихся для анализа программных средств.
Описание: применяемая стратегия испытаний базируется на отношении эквивалентности входов, которое определяет разделение входной области.
Тестовые примеры выбираются с учетом охвата всех предварительно специфицированных разбиений. Из каждого класса эквивалентности выбирается по меньшей мере один тестовый пример. Существуют следующие основные возможности разбиения входных данных:
- классы эквивалентности, образованные из спецификации (интерпретация спецификации может быть ориентирована либо на вход, например, когда выбранные значения считаются одинаковыми, либо на выход, например, когда набор значений приводит к одному и тому же функциональному результату);
- классы эквивалентности, образованные в соответствии с внутренней структурой программы (результаты класса эквивалентности определяются из статического анализа программ, например, набор значений обрабатывается одним и тем же способом).
Более подробное описание данного метода/средства приведено в [190 - 194].
B.5.8 Структурное тестирование
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.2).
Цель: применение тестов, анализирующих определенные подмножества структуры программы.
Описание: на основе анализа программы определяется набор входных данных так, чтобы мог быть проанализирован достаточно большой (часто с заранее заданным назначением) процент программных кодов. Средства охвата программы, в зависимости от степени требуемой строгости могут быть различными:
- утверждение - это наименее строгий тест, поскольку можно выполнить все закодированные утверждения без анализа обеих ветвей условного утверждения;
- ветвление - следует проверять обе стороны каждой ветви (это может оказаться непрактичным для некоторых типов кодов защиты);
- составные условия - анализируется каждое условие в составной ветви (связанное оператором И/ИЛИ) (см., например, охват решения модифицированными условиями MCDC, который означает, что каждая точка входа и выхода в программе была задействована по меньшей мере один раз, что любое решение в программе получило все возможные результаты по крайней мере один раз и что для каждого условия в решении был показан независимый результат, влияющий на результирующее решение). Для каждого набора переменных (внутри логического выражения), как истинных, так и ложных, должны быть разработаны Булевы таблицы истинности;
- LCSAJ - последовательность линейного кода и переходов представляет собой любую линейную последовательность закодированных утверждений, включая условные утверждения, заканчивающиеся переходом. Многие потенциальные подпоследовательности могут оказаться невыполнимыми из-за ограничений, которые налагаются на входные данные в результате выполнения предыдущего кода;
- поток данных - выполняющиеся последовательности выбираются на основе используемых данных; например, последовательность, где одна и та же переменная и записывается, и считывается;
- граф вызовов - программа, состоящая из подпрограмм, которые могут быть вызваны из других подпрограмм. Этот граф вызовов представляет собой дерево вызовов подпрограмм в программе. Тесты должны охватывать все вызовы в дереве;
- базовая последовательность - одна из минимального набора конечных последовательностей от начала до конца, когда охвачены все дуги (перекрывающиеся комбинации последовательностей в этом базовом наборе могут сформировать любую последовательность через эту часть программы). Тесты всех базовых последовательностей показали свою эффективность при обнаружении ошибок.
Более подробное описание данного метода/средства приведено в [195 - 200].
B.5.9 Анализ потоков управления
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение низкокачественных и потенциально некорректных структур программ.
Описание: анализ потока управления представляет собой метод статического тестирования для нахождения подозреваемых областей программы, которые не соответствуют оправдавшей себя практике программирования. Программа анализируется, формируя направленный граф, который может быть проанализирован на наличие:
- недоступных фрагментов программы, например безусловных переходов, которые делают фрагменты программы недостижимыми;
- запутанных кодов. Хорошо структурированный код имеет управляющий граф, допускающий сокращение путем последовательного сокращения графа до одного узла. В отличие от этого плохо структурированный код может быть сокращен только до группы, состоящей из нескольких узлов.
Более подробное описание данного метода/средства приведено в [201, 202].
B.5.10 Анализ потоков данных
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение низкокачественных и потенциально некорректных структур программ.
Описание: анализ потока данных представляет собой метод статического тестирования, объединяющий информацию, полученную из анализа потока управления, с информацией о том, какие переменные считываются или записываются в различных частях кода. Данный метод может проверять:
- переменные, которые могут быть считаны до присвоения им значений. Такую ситуацию можно исключить, если всегда присваивать значение при объявлении новой переменной;
- переменные, записанные несколько раз, но не считанные. Такая ситуация может указывать на пропущенный код;
- переменные, которые записаны, но никогда не считываются. Такая ситуация может указывать на избыточный код.
Аномальный поток данных не всегда непосредственно соответствует программным ошибкам, но если аномалии исключены, то маловероятно, что код будет содержать ошибки.
Более подробное описание данного метода/средства приведено в [201 - 203].
B.5.11 Выявление скрытых схем исполнения
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение неожидаемых путей или логических потоков в системе, в конкретных условиях инициирующих нежелательные функции или запрещающих выполнение необходимых функций.
Описание: путь паразитной схемы может содержать аппаратные, программные средства, операторы действий или комбинации этих элементов. Паразитные схемы не являются результатом неисправностей аппаратных средств, а представляют собой скрытые условия невнимательного проектирования системы или кодирования прикладных программ, что при определенных условиях может привести к неправильному функционированию системы.
Паразитные схемы разделяют на следующие категории:
- паразитные пути, вызывающие потоки тока, энергии или логических последовательностей по неожидаемому пути или в незаданном направлении;
- паразитная синхронизация, при которой события происходят в неожидаемой или противоречивой последовательности;
- паразитная индикация, вызывающая неоднозначные или ложные изображения условий эксплуатации системы, что может привести к нежелательным действиям оператора;
- паразитные метки, некорректно или неточно размечающие системные функции, например системные входы, коды управления, изображения, шины и т. д., что может ввести в заблуждение оператора, который может выполнить в системе некорректные действия.
Анализ паразитных схем основывается на распознавании базовых топологических комбинаций в аппаратной или программной структуре. Анализ осуществляется с помощью контрольного списка вопросов об использовании базовых топологических компонентов и отношениях между ними.
Более подробное описание данного метода/средства приведено в [204, 205].
B.5.12 Тестирование на символьном уровне
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: показать соответствие между исходным кодом и спецификацией.
Описание: переменные программы оцениваются после замены во всех операторах присваивания левой его части на правую. Условные ветви и циклы преобразуются в булевы выражения. Окончательный результат представляет собой символьное выражение для каждой переменной программы. Оно может быть проверено относительно предполагаемого символьного выражения.
Более подробное описание данного метода/средства приведено в [206, 207].
B.5.13 Формальное доказательство
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.9).
Цель: верификация (путем доказательства) корректности программ или спецификаций без их исполнения, используя теоретические и математические модели и правила.
Описание: ряд утверждений устанавливается в различных точках программы, и они используются в качестве предусловий и постусловий для различных путей программы. Доказательство демонстрирует, что программа преобразует предусловия в постусловия в соответствии с набором логических правил и завершается.
В настоящем стандарте описаны различные формальные методы, например CCS, CSP, HOL, LOTOS, OBJ, временная логика, VDM и Z (см. В.2.4).
Альтернативным методу формального доказательства является «строгий аргумент». Подготавливается процедура формального доказательства, в которой представлены основные этапы, но включены не все математические подробности. Метод «строгий аргумент» является более слабым методом верификации, устанавливающим, что доказательство было бы возможным, если бы к этому были предприняты попытки.
Более подробное описание данного метода/средства приведено в [207 - 210].
B.5.14 Метрики сложности программного обеспечения
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы А.9 и А.10).
Цель: прогнозирование характеристик программ исходя из свойств самих программ или их разработки либо предыстории тестирования.
Описание: данные методы оценивают некоторые структурные свойства программных средств и их отношения к требуемым характеристикам, например надежность или сложность. Для оценки большинства средств требуются программные инструменты. Некоторые применяющиеся метрики перечислены ниже:
- теоретическая сложность графа. Эта метрика может быть применена на раннем этапе жизненного цикла для оценки компромиссных решений и основана на величине сложности графа управления программы, представленной ее цикломатическим числом;
- число способов активизации некоторых программных модулей (доступность) - чем больше программных модулей может быть доступно, тем должна быть большая вероятность их отладки;
- теория метрик Холстеда. При помощи этих средств вычисляют длину программы путем подсчета числа операторов и операндов; данная метрика дает меру сложности и размеры, которые формируют основу для сравнений при оценке будущих разрабатываемых ресурсов;
- число входов и выходов на программный модуль. Сведение к минимуму числа точек входов/выходов является ключевой особенностью методов структурного проектирования и программирования.
Более подробное описание данного метода/средства приведено в [211 - 213].
B.5.15 Инспекция программ
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение ошибок на всех этапах разработки программ.
Описание: формальный аудит гарантирующих качество документов, направленный на отыскание ошибок. Процедура инспекции (проверки) состоит из пяти этапов: планирование, подготовка, исследование, анализ и учет. Каждый из этих этапов имеет свои конкретные цели. Должна быть проанализирована вся разработка системы (спецификация, проектирование, кодирование и тестирование).
Более подробное описание данного метода/средства приведено в [214, 215].
B.5.16 Сквозной контроль/анализ проекта
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение ошибок в различных частях проекта с высокой оперативностью и экономичностью.
Описание: в МЭК опубликовано руководство по общему представлению формального анализа проектов, которое содержит общее описание представления формального анализа проектов, его цели, подробные сведения о различных типах анализа проекта, состав группы анализа проекта и относящиеся к ним обязанности и ответственности. Это руководство содержит также общие руководящие материалы по планированию и выполнению формального анализа проектов, а также конкретные подробные сведения, относящиеся к роли независимых специалистов в группе по анализу проекта. Например, помимо прочего, в функции специалистов входят надежность, поддержка обслуживания и доступность.
В упомянутом выше руководстве МЭК рекомендуется, чтобы формальный анализ проекта проводился для всех новых изделий/процессов, применений и при пересмотрах существующих изделий и производственных процессов, влияющих на функции, производительность, безопасность, надежность, способность анализировать обслуживание, доступность, способность к экономичности и другие характеристики, влияющие на конечные изделия/процессы, пользователей или наблюдателей.
Закодированный сквозной контроль состоит из группы сквозного контроля, выбирающей небольшой набор изложенных на бумаге тестовых примеров, представляющих наборы входных данных и соответствующие предполагаемые выходы для программы. После этого тестовые данные вручную трассируются через логику программы.
Более подробное описание данного метода/средства приведено в [200, 216, 217].
B.5.17 Макетирование/анимация
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы Б.3 и Б.5).
Цель: проверка возможности реализации системы при наличии заданных ограничений. Увязка интерпретации разработчика спецификации системы с ее потребителем для исключения непонимания между ними.
Описание: выделяются подмножество системных функций, ограничения и требования к рабочим параметрам. С помощью инструментов высокого уровня строится макет. На данном этапе не требуется рассмотрение ограничений (например, используемый компьютер, язык реализации, объем программ, обслуживание, надежность и доступность). Макет оценивается по критериям потребителя, и системные требования могут быть модифицированы в свете этой оценки.
Более подробное описание данного метода/средства приведено в [218 - 220].
B.5.18 Моделирование процесса
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.3).
Цель: тестирование функции программной системы вместе с ее интерфейсами во внешнем окружении, не допуская модификации реального окружения.
Описание: создание системы только для целей тестирования, имитирующей поведение управляемого оборудования (УО).
Имитация может осуществляться только программным обеспечением либо сочетанием ПО и АС. Она должна:
- обеспечить входы, эквивалентные входам, которые могут быть при фактической установке УО;
- реагировать на выходные результаты тестирования программных средств способом, точно отражающим объект управления;
- обладать средствами для входных данных оператора, обеспечивающими любые нарушения, с которыми должна справиться тестируемая система.
По завершении тестирования ПО созданная система может тестировать АС с их входами и выходами. Более подробное описание данного метода/средства приведено в [221, 222].
B.5.19 Требования к реализации
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.6).
Цель: установление демонстрируемых требований к рабочим характеристикам системы ПО. Описание: выполняется анализ как системы, так и спецификаций требований к ПО для спецификации всех общих и конкретных, явных и неявных требований к функционированию.
Каждое требование к функционированию анализируется по очереди для определения:
- критериев успешности результата, который следует получить;
- возможности получения меры критерия успешности;
- потенциальной точности таких результатов измерения;
- этапов проектирования, на которых эти результаты измерения могут быть оценены;
- этапов проектирования, на которых могут быть получены эти результаты измерений.
Затем анализируется целесообразность каждого требования к функционированию для получения списка требований к рабочим характеристикам, критериев успешности результата и возможных результатов измерений. Основными целями являются:
- связь каждой рабочей характеристики по крайней мере с одной мерой;
- выбор (по возможности) точных и эффективных мер, которые могут быть использованы на самых ранних стадиях разработки;
- спецификация важных и факультативных рабочих характеристик и критериев успешности результата;
- использование (по возможности) преимуществ применения одной меры для нескольких рабочих характеристик.
Более подробное описание данного метода/средства приведено в [222 - 224].
B.5.20 Моделирование реализации
Примечание -Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы А.5, Б.2 и Б.5).
Цель: достижение достаточной для удовлетворения специфицированных требований рабочей производительности системы.
Описание: спецификация требований включает в себя требования к пропускной способности и реакции конкретных функций, возможно, объединенных с ограничениями на использование общих системных ресурсов. Предложенный проект системы сравнивается с установленными требованиями следующим путем:
- создание модели процессов системы и их взаимодействий;
- определение ресурсов, используемых каждым процессом (время процессора, полоса пропускания канала связи, объем памяти и т. п.);
- определение распределения запросов, выдаваемых системе при средних и наихудших условиях;
- вычисление средних и наихудших случаев значений величин пропускной способности и времени отклика для конкретных функций системы.
Для простых систем может оказаться достаточным аналитическое решение, тогда как для более сложных систем более подходящей для получения точных результатов является создание модели системы.
Перед детальным моделированием может быть использована более простая проверка «бюджета ресурсов», которая суммирует требования к ресурсам всех процессов. Если сумма этих требований к системе превышает возможности спроектированной системы, проект считается нереализуемым. Даже в случае, если проект проходит эту простую проверку, моделирование выполнения может показать, что слишком большие задержки и времена откликов происходят из-за недостатка ресурсов. Для исключения такой ситуации инженеры часто проектируют системы, использующие только часть (например, 50 %) общих ресурсов для уменьшения вероятности нехватки ресурсов.
Более подробное описание данного метода/средства приведено в [222, 225, 226].
B.5.21 Проверка на критические и напряженные нагрузки
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.3 (таблица Б.6).
Цель: подвержение тестируемого объекта исключительно высокой нагрузке для демонстрации, что тестируемый объект будет легко выдерживать нормальную рабочую нагрузку.
Описание: существует множество тестов для проверки на критические и напряженные нагрузки, например:
- при работе объекта в режиме упорядоченного опроса он подвергается тестированию в единицу времени гораздо чаще, что приводит к большим входным изменениям, чем при нормальных условиях;
- при работе объекта по запросам число запросов к тестируемому объекту увеличивают в единицу времени по сравнению с нормальными условиями;
- если объем базы данных играет важную роль, то этот объем увеличивают относительно объема при нормальных условиях;
- устройства, имеющие решающее влияние, настраивают на их максимальные или минимальные скорости соответственно;
- для экстремальных тестов все факторы, имеющие решающее влияние, по возможности вводят одновременно в граничные условия.
Для указанных выше тестов может быть оценено поведение во времени тестируемого объекта. Можно также исследовать изменения нагрузки и проверить размер внутренних буферов или динамических переменных, стеков и т. п.
Более подробное описание данного метода/средства приведено в [227, 228].
B.5.22 Ограничения на время реакции и объем памяти
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.6).
Цель: обеспечение соответствия системы требованиям к параметрам времени и памяти.
Описание: спецификация требований к системе и программному обеспечению включает в себя требования к памяти и времени выполнения системой конкретных функций, возможно, объединенных с ограничениями на использование общих системных ресурсов.
Данный метод выполняется для установления распределения запросов при средних и наихудших условиях. Рассматриваемый метод требует оценки используемых ресурсов и затраченного времени каждой функцией системы. Такие оценки могут быть получены различными способами, например сравнением с существующей системой или макетированием и дальнейшим сравнением времени реакции с критическими системами.
Более подробное описание данного метода/средства приведено в [227, 229 - 232].
B.5.23 Анализ влияния
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.8).
Цель: определение влияния, изменяющего или расширяющего программную систему, которому могут подвергаться также и другие программные модули в данной программной системе, а также другие системы.
Описание: перед выполнением модификации или расширения программного обеспечения следует определить влияние модификаций или расширений на программное обеспечение, а также определить, на какие программные системы и программные модули это повлияет.
Далее принимается решение о повторной верификации программной системы. Это зависит от числа подвергнувшихся воздействию программных модулей, их критичности и характера изменений. Возможными решениями могут быть:
- повторная проверка только изменений программного модуля;
- повторная проверка всех подвергнувшихся воздействию программных модулей;
- повторная проверка всей системы.
Более подробное описание данного метода/средства приведено в [200, 233].
B.5.24 Управление конфигурацией программного обеспечения
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.8).
Цель: обеспечение согласованности результатов работы групп поставщиков составляющих проекта, а также изменений в этих поставках. В общем случае управление конфигурацией применимо к разработке как АС, так и ПО.
Описание: управление конфигурацией ПО представляет собой метод, используемый в течение всей разработки. В сущности, он требует документирования разработки каждой версии, каждой значимой ее поставки и каждой взаимосвязи между различными версиями разработки различных поставщиков. Полученная документация позволяет разработчику определять, как влияет на другие поставки изменение в первой поставке (особенно одного из его компонентов). В частности, системы или подсистемы могут надежно компоноваться (конфигурироваться) из согласованных наборов версий компонентов.
Более подробное описание данного метода/средства приведено в [234, 235].
В.6 Оценка функциональной безопасности
Примечание - Соответствующие методы и средства см. также в Б.6 настоящего стандарта.
В.6.1 Таблицы решений и таблицы истинности
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы А.10 и Б.7).
Цель: обеспечение ясных и согласующихся спецификаций и анализа сложных логических комбинаций и их отношений.
Описание: в данном методе используют бинарные таблицы для точного описания логических отношений между булевыми переменными программы.
Использование таблиц и точность метода позволили применить его в качестве средства анализа сложных логических комбинаций, выраженных в бинарных кодах.
Рассматриваемый метод достаточно легко автоматизируется, поэтому его можно использовать в качестве средства спецификации систем.
B.6.2 Исследование опасности и работоспособности (HAZOP)
Цель: определение угроз безопасности в предлагаемой или существующей системе, их возможных причин и последствий, а также рекомендуемых действий по минимизации вероятности их появления.
Описание: группа специалистов в области создаваемой системы принимает участие в структурном анализе проекта системы путем ряда запланированных совещаний. Они рассматривают как реализацию функций проекта системы, так и способы работы системы на практике (включая действия персонала и процедуры эксплуатации системы). Руководитель группы специалистов инициирует ее участников создавать потенциальные опасности и управляет этой процедурой, описывая каждую часть системы в сочетании с отдельными ключевыми словами: «отсутствует», «более», «менее», «часть целого», «больше чем» (или «так же как и») и «иначе чем». Каждое применимое условие или режим отказа рассматривается с точки зрения реализуемости, причин возникновения, возможных последствий (появляется ли опасность), способа устранения и, в случае устранения, выбора наиболее целесообразного метода.
Затем часто возникает необходимость провести дальнейшее исследование опасностей (методом вероятностной или количественной оценки риска) с целью их более подробного рассмотрения.
Исследование опасностей может выполняться на разных стадиях разработки проекта, однако наиболее эффективным такое исследование может быть на начальных стадиях, с тем чтобы как можно раньше повлиять на основные решения по проектированию и работоспособности системы. Полезно в графике выполнения проекта определить фиксированное время для совещаний продолжительностью не менее половины дня и не более четырех раз в неделю с тем чтобы рассматривать весь поток сопроводительной документации. Сопроводительная документация, выработанная на совещаниях, должна составлять существенную часть досье об опасности/безопасности системы.
Метод HAZOP создавался для производственных процессов, и без модификации его сложно применить к программным элементам программируемых электронных систем (РЕ-систем - PES). Были разработаны различные производные методы PES HAZOP (или Computer HAZOPs - «CHAZOPs»), которые сопровождались новыми руководящими материалами и/или реализовывали способы систематического охвата системной и программной архитектур.
Более подробное описание данного метода/средства приведено в [236, 237].
B.6.3 Анализ отказов по общей причине
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.10).
Цель: определение возможных отказов в нескольких системах или нескольких подсистемах, которые могут свести к нулю преимущества избыточности из-за одновременного появления одних и тех же отказов во многих частях системы.
Описание: системы, ориентированные на безопасность объекта, часто используют избыточность аппаратных средств и мажоритарный принцип голосования. Этот подход исключает случайные отказы в компонентах или подсистемах аппаратных средств, которые могут помешать корректной обработке данных.
Однако некоторые отказы могут оказаться общими для нескольких компонентов или подсистем. Например, если система установлена в одном помещении, то недостатки вентиляции могут снизить преимущества избыточности. Это может оказаться верным и для других внешних влияний на систему (например, пожар, затопление, электромагнитные влияния, трещины в печатных платах и землетрясение). Система может быть также подвержена воздействиям, относящимся к ее функционированию и эксплуатации. Поэтому важно, чтобы в рабочих инструкциях были предусмотрены адекватные и хорошо задокументированные процедуры по функционированию и эксплуатации системы, а обслуживающий персонал был хорошо обучен.
Внутренние причины также вносят большой вклад в общее число отказов. Их основой могут являться ошибки проектирования общих или идентичных компонентов и их интерфейсов, в том числе и устаревших компонентов. Анализ отказов по общей причине должен отыскивать также общие дефекты в системе. К методам анализа отказов по общей причине относятся:
- общее управление качеством;
- анализ проектов;
- верификация и тестирование независимой группой;
- анализ реальных ситуаций, полученных из опыта работы аналогичных систем.
Однако область применения такого анализа выходит за рамки только АС. Даже если разные программы используются в разных каналах избыточных систем, возможна некоторая общность в программных подходах, которая может привести к росту отказов по общей причине (например, ошибки в общей спецификации).
Если отказы по общей причине не появляются точно в одно и то же время, то должны быть предприняты меры предосторожности путем сравнения методов, применяемых в различных каналах. При этом использование каждого метода должно приводить к обнаружению отказа до того, как он окажется общим для всех каналов. При анализе отказов по общей причине следует использовать этот подход.
Более подробное описание данного метода/средства приведено в [238, 239].
B.6.4 Модели Маркова
Цель: оценка надежности, безопасности и доступности систем.
Описание: строится граф системы, представляющий состояния системы, связанные с ее отказами (состояния отказов представляются узлами графов). Связи между узлами, представляющие собой события-отказы или события-восстановления, имеют весовые коэффициенты, соответствующие частотам отказов или частотам восстановлений. Предполагается, что переход из состояния N в последующее состояние N + 1 не зависит от предыдущего состояния N - 1. Следует заметить, что события, состояния и частоты отказов могут быть детализированы так, что может быть получено точное описание системы, например обнаруженные или необнаруженные отказы, обнаружение наибольшего отказа и т. п.
Метод Маркова подходит для моделирования многих систем, уровень избыточности которых изменяется со временем вследствие нахождения компонента в состоянии отказа или восстановления. Другие классические методы, например FMEA и FTA, не могут быть адаптированы к моделированию влияний отказов в течение жизненного цикла системы, поскольку не существует простой комбинаторной формулы для вычисления соответствующих вероятностей.
В простейших случаях такую формулу, описывающую вероятности системы, можно найти в литературе или вывести самостоятельно. В более сложных случаях существуют методы упрощения (то есть сокращение числа состояний). Для очень сложных случаев результаты могут быть вычислены с помощью моделирования графа на компьютере.
Более подробное описание данного метода/средства приведено в [240 - 244].
B.6.5 Структурные схемы надежности
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица А.10).
Цель: моделирование в форме диаграмм набора событий, которые должны происходить, и условий, которые должны быть удовлетворены для успешного выполнения операций системы или задач.
Описание: данный метод позволяет сформировать успешный маршрут, состоящий из блоков, линий и логических переходов. Такой успешный маршрут начинается от одной стороны диаграммы и проходит через блоки и логические переходы до другой стороны диаграммы. Блок представляет собой условие или событие, маршрут проходит через него, если условие истинно или событие произошло. Когда маршрут подходит к логическому переходу, то он продолжается, если критерий логического перехода выполняется. Если маршрут достигает какой-либо вершины, то он может продолжаться по всем исходящим из нее путям. Если существует по меньшей мере один успешный маршрут через всю диаграмму, то цель анализа считается достигнутой.
Более подробное описание данного метода/средства приведено в [245, 246].
B.6.6 Моделирование методом Монте-Карло
Примечание - Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.4).
Цель: моделирование ситуаций реального мира с помощью программных средств методом генерации случайных чисел.
Описание: моделирование методом Монте-Карло используется для решения двух классов задач:
- вероятностных, в которых для генерации стохастических ситуаций используются случайные числа;
- детерминистических, которые математически преобразуются в эквивалентную вероятностную форму. При методе Монте-Карло формируются потоки случайных чисел, с тем чтобы генерировать шум при анализе сигналов или добавлять их в случайные смещения или допуски.
Данный метод гарантированно обеспечивает нахождение смещений, допусков или шума в приемлемых диапазонах.
Общие принципы моделирования методом Монте-Карло заключаются в переформулировании задачи так, чтобы полученные результаты были как можно более точными, что позволяет отказаться от решения проблемы в ее исходной постановке.
Более подробное описание данного метода/средства приведено в [247, 248].
Г.1 Общие положения
Настоящее приложение содержит исходные руководящие материалы по использованию вероятностного подхода к определению полноты безопасности ПО СБЗС-систем для предварительно разработанных программ на основе их опыта эксплуатации. Вероятностный подход является наиболее подходящим для оценки операционных систем, библиотечных компонентов, компиляторов и других программных систем. Настоящее приложение содержит также описание возможностей вероятностного подхода, однако его следует использовать только специалистам, компетентным в статистическом анализе.
Предложенные в настоящем приложении методы могут быть также использованы для демонстрации роста уровня полноты безопасности программных средств, которые некоторое время успешно эксплуатировались. Например, программные средства, созданные в соответствии с требованиями ГОСТ Р 53195.4 для SIL1, после соответствующего периода успешной работы в большом числе применений могут продемонстрировать соответствие уровню полноты безопасности SIL2.
Число запросов без отказов при испытании или число часов, необходимое для работы без отказов, для определения конкретного уровня полноты безопасности представлено в таблице Г.1. В таблице Г.1 также обобщены результаты, приведенные в Г.2.1 и Г.2.3 настоящего приложения.
Опыт эксплуатации может быть выражен математически, как показано в Г.2, для дополнения или замены статистического тестирования, а опыт эксплуатации, полученный из нескольких мест эксплуатации, может быть объединен путем добавления конкретного числа обработанных запросов или часов работы в течение эксплуатации, но только в случае, если:
- программная версия, подлежащая использованию в Е/Е/РЕ СБЗС-системе, будет идентична версии, для которой предъявлен результат опыта ее эксплуатации;
- их эксплуатационный профиль и входные условия схожи;
- существует эффективная система уведомлений и документирования отказов;
- справедливы принятые в Г.2 предположения.
Таблица Г.1 - Необходимая предыстория для определения уровня полноты безопасности
Значение вероятности отказа при выполнении планируемых функций по запросу (режим работы с низкой интенсивностью запросов) |
Число реальных запросов |
Значение вероятности опасного отказа в час (режим с высокой интенсивностью запросов или непрерывным запросом) |
Общее число часов эксплуатации |
|||
1 - a = 0,99 |
1 - a = 0,95 |
1 - a = 0,99 |
1 - a = 0,95 |
|||
SIL4 |
От 10-5 включ. до 10-4 |
4,6 × 105 |
3 × 105 |
От 10-9 включ. до 10-8 |
4,6 × 109 |
3 × 109 |
SIL3 |
От 10-4 включ. до 10-3 |
4,6 × 104 |
3 × 104 |
От 10-8 включ. до 10-7 |
4,6 × 108 |
3 × 108 |
SIL2 |
От 10-3 включ. до 10-2 |
4,6 × 103 |
3 × 103 |
От 10-7 включ. до 10-6 |
4,6 × 107 |
3 × 107 |
SIL1 |
От 10-2 включ. до 10-1 |
4,6 × 102 |
3 × 102 |
От 10-6 включ. до 10-5 |
4,6 × 106 |
3 × 106 |
Примечания 1 Величина 1 - а представляет собой уровень доверия. 2 Предпосылки и описание процедур получения числовых значений в настоящей таблице см. в Г.2.1 и Г.2.3 настоящего приложения. |
Г.2 Формулы статистического тестирования и примеры их использования
Г.2.1 Простой статистический тест для режима работы с низкой интенсивностью запросов
Г.2.1.1 Исходные предпосылки
Тест применим при следующих предпосылках:
- распределение тестовых данных равно распределению запросов при выполнении операций в режиме он-лайн;
- прохождения тестов статистически не зависят друг от друга в отношении причины отказа;
- для обнаружения любых отказов, которые могут появиться, существует адекватный механизм;
- число тестовых примеров п > 100;
- во время прогона п тестовых примеров отказы отсутствуют.
Г.2.1.2 Результаты
Вероятность отказа р (на один запрос) при уровне доверия 1 - a определяется из выражения
ПРИМЕР
Таблица Г.2 - Вероятности отказа при режиме работы с низкой интенсивностью запросов |
|
Значение уровня доверия 1 - a |
Вероятность отказов р |
0,95 |
3/п |
0,99 |
4,6/п |
Для вероятности отказа при запросе для уровня полноты безопасности SIL3 при уровне доверия 95 % применение указанной формулы дает 30 000 тестовых примеров при выполнении условий принятых предпосылок. Результаты для каждого уровня полноты безопасности объединены в таблице Г.1.
Г.2.2 Тестирование входного массива (предметной области) для режима работы с низкой интенсивностью запросов
Г.2.2.1 Исходные предпосылки
Единственная исходная предпосылка состоит в том, что тестируемые данные выбираются так, чтобы обеспечить случайное унифицированное распределение по входному массиву (предметной области).
Г.2.2.2 Результаты
Необходимо определить число тестов п, которые требуются, исходя из порога точности 8, входов для тестируемой функции с низкой интенсивностью запросов (например, безопасное отключение).
Таблица Г.3 - Средние расстояния между двумя точками тестирования
Размер предметного пространства |
Среднее расстояние между двумя точками тестирования в произвольном направлении |
1 |
d = 1/n |
2 |
|
3 |
|
k |
|
Примечание - k может быть любым положительным целым числом. Значения 1, 2 и 3 приведены только в качестве примеров. |
ПРИМЕР
Рассмотрим безопасное отключение, которое зависит только от переменных А и В. Если проверкой было установлено, что пороговые значения, которые разделяют входную пару переменных А и В, определены с точностью до 1 % диапазона измерения А или В, то число равномерно распределенных тестовых примеров, требуемое в области А и В, будет равно
n = 1/d2 = 104.
Г.2.3.1 Исходные предпосылки Тест применим при следующих предпосылках:
- распределение тестовых данных такое же, как и распределение данных при выполнении операций в режиме с внешним управлением он-лайн;
- относительное уменьшение вероятности отсутствия отказа пропорционально продолжительности рассматриваемого интервала времени и постоянно в противном случае;
- для обнаружения любых отказов, которые могут появиться, существует адекватный механизм;
- тест выполняется в течение времени тестирования t;
- во время тестирования t никаких отказов не происходит.
Г.2.3.2 Результаты
Соотношение между интенсивностью отказов l, уровнем доверия 1-a и временем тестирования t имеет вид
Интенсивность отказов обратно пропорциональна среднему времени наработки на отказ (MTBF):
Примечание - В настоящем стандарте не делается различий между интенсивностью отказов в час и частотой отказов в час. Строго говоря, вероятность отказа F связана с частотой отказов f выражением F = 1 - e-ft, однако область применения настоящего стандарта охватывает частоту отказов менее 10-5 1/ч, а для небольших значений частоты справедливо F ~ ft.
ПРИМЕР
Таблица Г.4 - Вероятности отказа для режима с высокой интенсивностью запросов или непрерывным запросом
Значение уровня доверия 1 - a |
Вероятность отказов в час у |
0,95 |
3t |
0,99 |
4,6/t |
Для подтверждения того, что среднее время наработки на отказ составляет по меньшей мере 108 час. с уровнем доверия 95 %, требуется время тестирования 3×108 ч и должны быть соблюдены исходные предпосылки. Число тестов, необходимое для каждого уровня полноты безопасности, - в соответствии с таблицей Г.1.
Г.2.4 Полное тестирование
Программу можно рассматривать как урну, содержащую N шаров. Каждый шар представляет собой конкретное свойство программы. Шары извлекаются случайно и заменяются после проверки. Полное тестирование достигается, если все шары извлечены.
Тест применим при следующих предпосылках:
- распределение тестируемых данных таково, что каждое из N свойств программы тестируется с равной вероятностью;
- тесты проводятся независимо друг от друга;
- каждый появляющийся отказ обнаруживается;
- число случаев тестирования п >> N;
- во время п случаев тестирования отказы не появляются;
- каждый прогон теста контролирует одно свойство программы (свойство программы - это то, что может быть протестировано во время одного прогона теста).
Г2.4.2 Результаты
Вероятность тестирования всех свойств программы р определяется выражением
где
При оценке этого выражения обычно только первые его члены имеют значение, поскольку в реальных условиях выполняется соотношение п >> N, что делает все члены этого выражения при большом значении j несущественными. Это видно из таблицы Г.5.
ПРИМЕР
Рассмотрим программу, которая имела несколько инсталляций в течение нескольких лет. За это время она выполнялась по меньшей мере 7,5×106 раз. Предположим, что каждое 100-е выполнение программы соответствует перечисленным выше исходным предпосылкам (см. Г.2.4.1). Поэтому для статистической оценки могут быть приняты 7,5×10* выполнений программы. Если предположить, что 4000 тестовых прогонов программы могут выполнить исчерпывающее тестирование, считая такую оценку консервативной, то в соответствии с таблицей Г.5 вероятность того, что не все будет протестировано, составляет 2,87×10-5.
При N = 4000 значения первых членов в зависимости от п представлены в таблице Г.5.
Таблица Г.5- Вероятность тестирования всех свойств программы
Вероятность тестирования всех свойств программы р |
|
5 × 104 |
1 - 1,9 × 10-2 + 1,10 × 10-4-... |
7,5 × 104 |
1 - 2,87 × 10-5 + 4 × 10-10-... |
1 × 105 |
1 - 5,54 × 10-8 + 1,52 × 10-15-... |
2 × 105 |
1 - 7,67 × 10-19 + 2,9 × 10-37-... |
На практике такие оценки должны быть консервативными.
Более подробные сведения по оценке полноты безопасности ПО систем приведены в [88, 148, 249, 250].
Ларионов А. М., Майоров С. А., Новиков Г И. Вычислительные комплексы, системы и сети. П.: Ленинградское отделение ЭНЕРГОАТОМ ИЗ ДАТ, 1987. http://sergey.weblab.ru/AVSiS/book/Larionov-VKSiS.htm (дата обращения 30.06.2009) |
|
Денисенко В. В. Компьютерное управление технологическим процессом, экспериментом, оборудованием. М.: Горячая линия-Телеком, 2009, 608 с, ил. |
|
Сети хранения данных Fibre Channel. Аппаратные средства технологии Fibre Channel, http://www.fibrechannel.ru/app.htm (дата обращения 29.06.2009) |
|
Компания Backhoff. Комплексная система противоаварийной защиты TwinSAFE//Автоматизация в промышленности. Июнь 2006, с. 31-34 |
|
Компания Backhoff. «Желтые» модули противоаварийной защиты работают по промышленной шине//Автоматизация в промышленности. Январь 2005, с. 36-38 |
|
Дудкин А. В. (Backhoff GmbH) ПО TwinCAT CNT решает сложные задачи движения по заданной траектории //Автоматизация в промышленности. Май 2004, с. 52-54 |
|
Жуков В. В., Лабковский М. Д. Регулировка электромеханических и радиотехнических приборов и систем: Учеб. пособ. для сред., проф.-техн. училищ. М.: Высш. шк., 1984, 200 с, ил. (Профессионально-техническое образование) |
|
Платунов А., Постников Н., Чистяков А. Механизм граничного сканирования в неоднородных микропроцессорных системах, http://www.chipnews.ru/html.cgi/arhiv/00_10/stat_8.htm (дата обращения 27.03.2009) |
|
[9] |
Грушвицкий Р., Ильин И., Михайлов М. Метод граничного сканирования для смешанных сигналов //Компоненты и технологии. № 8, 2006 |
Грушвицкий Р., Ильин И., Михайлов М. Метод граничного сканирования для смешанных сигналов. http://www.kit-e.ru/articles/plis/2006_8_118.php (дата обращения 27.03.2009) |
|
Система безопасного отключения для MOVIDRIVE® MDX60B/61B - Условия применения. Издание «SEWEurudrive» - On-line, 03.2004. http://www.sew-eurodrive.ru/files/pdf/11255064.pdf (дата обращения 06.07.2009) |
|
[12] |
Применение сертифицированных устройств безопасности производства немецкой компании WIELAND ELECTRIC GMBH на российских предприятиях. Информационно-консультативное издание «Технадзор». Май 2007, № 6 |
Брагин Г. Безопасность и сертификация, http://www.safemar.ru/articles.php?id=10 (дата обращения 06.07.2009) |
|
[14] |
Система безопасного отключения для MOVIDRIVE® MDX60B/61В - Условия применения. Издание SEWEurudrive, 03.2004. (дата обращения 06.07.2009). http://www.sew-eurodrive.ru/files/pdf/11255064.pdf (дата обращения 06.07.2009) |
Применение сертифицированных устройств безопасности производства немецкой компании WIELAND ELECTRIC GMBH на российских предприятиях. Информационно-консультативное издание «Технадзор». Май 2007, № 6 |
|
Хотек М. Методы достижения высокой отказоустойчивости: Windows &. NET Magazine/RE: Открытые системы, http://www.rnivc.kis.ru/?id=420 (дата обращения 27.03.2009). Постоянный адрес статьи: http://www.osp.ru/win2000/sql/312_4.htm |
|
Неплохое И. Мировые тенденции развития адресно-аналоговых систем пожарной сигнализации, http://articles.security-bridge.com/articles/13/11792 (дата обращения 27.03.2009) |
|
Щербина В. И. Комплексные системы безопасности высотных и многофункциональных зданий и сооружений. Построение систем, технические средства, рекомендации по применению. М.: Изд-во УКСБиИО, 2006. 216 с, ил. (Учебно-методическое, справочное пособие) |
|
Харченко В., Юрченко Ю. IOTS-подход: анализ вариантов структур отказоустойчивых бортовых комплексов при использовании электронных компонентов Industry // Технология и конструирование в электронной аппаратуре, 2003, № 2 |
|
Харченко В., Юрченко Ю. IOTS-подход: анализ вариантов структур отказоустойчивых бортовых комплексов при использовании электронных компонентов Industry. http://www.chipinfo.rU/literature/chipnews/200307/7.html (дата обращения 12.07.2009) |
|
Вернер М. Основы кодирования: Учебник для вузов. М.: Техносфера, 2004, 286 с |
|
[22] |
БлохЭ. Л., ЗябловВ. В. Обобщенные каскады-коды: алгебраическая теория и сложность реализации. М.: Связь, 1976 |
[23] |
Блох Э. Л., Зяблов В. В. Линейные каскады-коды. М.: Наука, 1982 |
Питерсон У, Уэлдон Э. Коды, исправляющие ошибки. Пер. с англ. Изд. 2-е, М.: Мир, 1976, 596 с. |
|
Конопелько В. К., Липницкий В. А. Теория норм синдромов и перестановочное декодирование помехоустойчивых кодов. М.: Эдиториал УРСС, 2004, 176 с. |
|
Жирнов М. Н. Анализ методов и синтез программно-технического комплекса для диагностирования дискретных систем на основе эталонных моделей. Вологодский государственный технический университет. http://nit.miem.edu.ru/2006/sb/section1/112.htm (дата обращения 28.03.2009) |
|
Многопроцессорные системы. Классификация систем параллельной обработки данных, http://www.lcard.ru/~nail/database/skbd/glava_10.htm (дата обращения 07.07.2009) |
|
Калядин А. Отладчики микроконтроллеров и их применение в разработке микроконтроллерных приложений. Мир компьютерной электроники / МКА - On-Line. http://www.mka.ru/?p=42051 (дата обращения 12.07.2009) |
|
Встраиваемый контроллер самотестирования памяти ARM11. Техническое руководство (ARM11 Memory Built-in Self Test Controller Technical Reference Manual) www.htmldatasheet.ru/pdf/ arm/arm11.pdf (дата обращения 28.03.2009) |
|
Интеллектуальные САПР Таганрог, Известия ЮФУ. Технические науки - тематический сборник. Сентябрь 2008, № 9. http://yandex.ru/yandsearch?p=2&text=TecTHpoBaHHe%20O3y%20n%20n3y,TecT%20Abraham (дата обращения 12.07.2009) |
|
Методы и алгоритмы тестирования памяти ЭВМ с обнаружением кратных функциональных неисправностей: Автореф. диссертация канд. техн. наук (05.13.15 - вычислительные машины и системы)/Новиков А. С; Науч. рук. Шаршунов С. Г. - Владивосток: ДВГТУ [s. п.], 2002. 18 с. |
|
Харкевич А. А. Борьба с помехами. М.: Наука, гл. ред. физ.-мат лит., 1965 |
|
Хемминг Р В. Теория кодирования и теория информации. М.: Мир, 1983 |
|
Питерсон У, Уэлдон Э. Коды, исправляющие ошибки: Пер. с англ. / Под ред. Р Л. Добрушина и С. И. Самойленко. М.: Мир, 1976, 594 с. |
|
Морелос-Сарагоса Р. Искусство помехоустойчивого кодирования. Методы, алгоритмы, применение. М.: Техносфера, 2005 |
|
Хмельнов А. Е. Организация ввода/вывода. Страница Хмельнова Алексея Евгеньевича - On-Line. http://hmelnov.icc.ru/stud/lit/ Shnitman/143-2.html (дата обращения 12.07.2009) |
|
[37] |
Хмельнов А. Е. Системы высокой готовности и отказоустойчивые системы. Страница Хмельнова Алексея Евгеньевича - On-Line. http://hmelnov.icc.ru/stud/lit/Shnitman/143-4.html (дата обращения 12.07.2009) |
[38] |
RAID. Глоссарий промышленной компании «СПЛАЙН», http://www.spline.ru/information/reviews/interface/SCSI_glossary (дата обращения 12.07.2009) |
Интеллектуальный дисковый массив RAID 6. Портал «NStor». http://www.nstor.ru/ru/catalog/76/88.html (дата обращения 12.07.2009) |
|
Ватье Ж.-К. Таблицы принятия решений: техника проведения тестирования с использованием Functional Tester от IBM Rational. Software Services, IBM: Пер. с англ. http://www.interface.ru/home.asp?artld=1170 (дата обращения 07.07.2009) |
|
[41] |
Ематин В., Закис А., Новичков А., Шкляева Н., ПодолякО. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational. Ч. 1. http://www.software-testing.ru/library/7-vendorpapers/156-ibm-rational (дата обращения 08.06.2009) |
Новичков А. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational. Ч. 2. http://www.software-testing.ru/library/7-vendor-papers/155----------ibm-rational-2- (дата обращения 08.07.2009) |
|
Новичков А. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational. Ч. 3. http://www.software-testing.ru/library/vendors/154----------ibm-rational-3- (дата обращения 08.06.2009). |
|
[44] |
Денисенко В. В. Компьютерное управление технологическим процессом, экспериментом, оборудованием. М.: Горячая линия-Телеком, 2009, 608 с, ил. |
Шнитман В. 3., Кузнецов С. Д. Серверы корпоративных баз данных. Информационно-аналитические материалы. Портал «Сервер» On-Line. http://www.ods.com.ua/win/rus/db/skbd/contents.htm. (дата обращения 12.07.2009) |
|
FAQ по активному воздушному охлаждению. Портал «Перегрева НЕТ!» http://www.peregreva.net/fan_basics1 .html (дата обращения 15.07.2009) |
|
[47] |
Баранов В. Термоэлектрический кулер Titan Amanda ТЕС. Портал «3DNews». http://www.3dnews.ru/cooling/titan_amanda_t.ec/ (дата обращения 14.07.2009) |
[48] |
Новый твердотельный вентилятор посрамляет традиционные кулеры! http://glamurnenko.com/archives/173 (дата обращения 15.07.2009) |
Задерновский А. А., Ривлин Л. А. Лазерное охлаждение полупроводника (оптическая тепловая машина) // Квант. Электроника, 1996, №23(12), с. 1131-1133 |
|
Метрологическое оборудование для контактных и бесконтактных средств измерений температуры, теплофизических и линейно-угловых измерений. Портал ОАО «Эталон». http://wwwomsketalon .ru/?action=poverka (дата обращения 14.07.2009) |
|
[51] |
Эталонные датчики. Портал «Элемер». http://www.elemer.ru/files/articles/listovka_pkds_210.pdf. (дата обращения 14.07.2009) |
[52] |
Лукьянченко А., Федоров А., Соколов Д.В., Ломаев Е.Н., ДонгХынгЧ. Газовые пожарные извещатели. Теоретические основы и практическое применение//Системы безопасности. 2007, №6. http://daily.sec.ru/dailypbl show.cfm?rid=6&pid=20660&pos=2&stp=25 (дата обращения 14.07.2009) |
Охранный извещатель Bosch Blue Line Р1-Р http://www.fbgroup.ru/indexshop.php?scid=1164&sgid=8372. (дата обращения 14.07.2009) |
|
Роздин И. А. Безопасность производства и труда на химических предприятиях. М.: Колосс. 2006, 254 с. (Серия: Учебники и учебные пособия для высших учебных заведений) |
|
ISO/IEC 15289:2006 Systems and software engineering - Content of systems and software life cycle process information products (Documentation) |
|
[56] |
ISO/IEC 90003:2004Software engineering - Guidelines for the application of ISO 9001:2000 to computer software |
Шалыто A. A. SWITCH-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998, 628 с. |
|
Шалыто А. А. Логическое управление. Методы аппаратной и программной реализации алгоритмов. СПб.: Наука, 2002, 784 с. |
|
Красилов А. А. Информатика в семи томах. Т. 6. Методы информатики (Изобретание, проектирование, разработка и сопровождение). М., 1997, 2003 |
|
Сети Петри. Отчет лаб. 11 СИАПУ ДВО РАН. http://www.iacp.dvo.ru/ lab 11/otchet/ot2000/pn3.html (дата обращения 06.04.2009) |
|
Простые сети Петри. Отчет лаб. 11 СИАПУ ДВО РАН. http://www.iacp.dvo.ru/lab 11/otchet/ot2000/pn3.html#simple (дата обращения 06.04.2009) |
|
[63] |
Цветные сети Петри. Отчет лаб. 11 СИАПУ ДВО РАН. http://www.iacp. dvo.ru/lab 11/otchet/ot2000/pn3.html#color (дата обращения 06.04.2009) |
Язык предписаний. Отчет лаб. 11 СИАПУ ДВО РАН. http://www.iacp. dvo.ru/lab 11/otchet/ot2000/lnscriptions.html (дата обращения 06.04.2009) |
|
Голенков Е. А., Соколов А. С. Метод автоматического построения модели параллельной программы в терминах сетей Петри. Вычислительные методы и программирование. Т. 6. № 2. Изд-во Московского университета, 2005, с. 77-82 |
|
Прозоров А. Лекция 4. Моделирование сущностей http://rtlab.ru/ lections/ Iec04 (дата обращения 07.04.2009) |
|
[67] |
Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2000, 592 с. |
Трахтенгерц Э. А. Компьютерная поддержка принятия решений. М.: Наука, 1998. http://www.masters.donntu.edu.ua/2004/kita/petrov/ library/led.htm (дата обращения 16.07.2009) |
|
Чекинов Г. П., Чекинов С. Г. Применение технологии многоагентных систем для интеллектуальной поддержки принятия решения (ИППР). Сетевой электронный научный журнал «СИСТЕМОТЕХНИКА». 2003, № 1. http://systech.miem.edu.ru/2003/n1/Chekinov.htm (дата обращения 07.04.2009) |
|
Йордон Э., Аргила С. Структурные модели в объектно-ориентированном анализе и проектировании. М.: Лори, 1999, 288 с. |
|
Дубинин В. Н., Зинкин С. А. Языки логического программирования в проектировании вычислительных систем и сетей: Учеб. пособие. Пенза: Изд-во Пенз. гос. техн. ун-та, 1997, 88 с. |
|
Ларман К. Применение UNL 2.0 и шаблонов проектирования. Пер. с англ. А. Ю. Шелестова. Изд. 3-е, Издательский дом «Вильяме», 2009, 727 с. |
|
Златин И. Л. Systemview 6.0 (SystemVue). Системное проектирование радиоэлектронных устройств. М.: Горячая линия-Телеком, 2006, 424 с. |
|
Загидуллин Р. Ш., Стешенко В. В., Карутин С. Н. SystemView. Системотехническое моделирование устройств обработки сигналов. М.: Горячая линия-Телеком, 2005, 294 с. |
|
Потапов Ю. В. Protel DSP. М.: Горячая линия-Телеком, 2006, 276 с, ил. (Серия «Инструменты разработчика») Multisim, LabVIEW и Signal Express. Практика автоматизированного проектирования электронных устройств /Р. Ш. Загидуллин. М.: Горячая линия-Телеком, 2009, 366 с, ил. (Серия «Современная электроника») http://www.altium.com/products/altium-designer/en/ altium-designer_home.cfm (дата обращения 07.04.2009) |
|
Башлы П. Н. Информационная безопасность: Учеб. пособие. М.: Феникс, 2006, 253 с, ил. |
|
Галле К. Полезные советы по разработке и отладке электронных схем. М.: ДМК Пресс, 2008, 208 с. |
|
[79] |
Бек К. Экстремальное программирование: разработка через тестирование. СПб.: Питер, 2003, 224 с. |
[80] |
Канер С, Фолк Д., Енг Кек Нгуен. Тестирование программного обеспечения. М.: ДиаСофт, 2001, 538 с. |
Дюваль П., Гловер Э. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска. М.: «Вильяме», 2008, 240 с. |
|
[82] |
Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. СПб.: Питер, 2004, 320 с. |
[83] |
Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. М.: Бином. Лаборатория знаний «Интуит», 2008, 368 с. |
Тэллес М., Хсих Ю. Наука отладки. КУДИЦ -ОБРАЗ, 2003, 560 с. |
|
[85] |
Терехов С. А. Нейросетевые аппроксимации плотности распределения вероятности в задачах информационного моделирования. Научная сессия МИФИ-2002. IV Всероссийская науч.-техн. конф. «Нейроинформатика-2002»: Лекции по нейроинформатике. Ч. 2. М.: МИФИ, 2002, 172 с. |
[86] |
Казиев В. М., Казиев К. В. Информатика: Задачи и тесты. М.: Просвещение, 2007, 191 с. |
Казиев В. М. Введение в практическое тестирование: Курс Интернет-университета информационных технологий (ИНТУИТ.ру) http://www .intuit.ru/department/informatics/practest (дата обращения 02.05.2009) |
|
Казарин О. В. Безопасность программного обеспечения компьютерных систем. М.: МГУЛ, 2003, 212 с. http://scanner.narod.ru/link/Safe/ bezopasnost programmnogo obespecheniya1.htm (дата обращения 27.06.2009) |
|
Техника анализа надежности систем. Метод анализа вида и последствий отказа, http://www.standards.ru/doc.aspx?catalogid=mec& classid=-1&search=60812%962006 (дата обращения 07.11.2009) |
|
Анализ видов и последствий потенциальных отказов (FMEA) (Potential Failure Mode and Effects Analysis). Пер. с англ. M.: Приоритет, 2003, 84 с. |
|
AMDEC. Анализ видов и последствий потенциальных дефектов продукции /системы. Руководство SOGEDAC-IV-1-12, 1994. Пер. с франц. Н. Новгород: СМЦ Приоритет, 2001,16с. |
|
Леоненков А. Самоучитель UML. Изд. 2-е, СПб.: БХВ-Петербург, 2004, 432 с. |
|
Трофимов С. А. CASE-технологии: практическая работа в Rational Rose. Изд. 2-е, СПб.: Бином. Торговый Дом, 2002, 288 с. |
|
Алымов В. Т., Тарасова Н. П. Техногенный риск: анализ и оценка. М.: ИКЦ Академкнига, 2007, 118 с. |
|
МЭК 60812-2006 Техника анализа надежности систем. Метод анализа вида и последствий отказа, http://www.standards.ru/doc. aspx?catalogid=mec&classid=-1&search=60812 (дата обращения 07.11.2009) |
|
МушикЭ., Мюллер П. Методы принятия технических решений. Пер. с нем. М.: Мир, 1990,208 с. |
|
Макконелл Д. Анализ алгоритмов. Вводный курс. М.: Техносфера, 200, 304 с. |
|
Шафер Д. Ф., Фатрелл Р. Т., Шафер Л. И. Управление программными проектами: достижение оптимального качества при минимуме затрат. Пер. с англ. М.: Издательский дом «Вильяме», 2004, 1135 с, ил. |
|
Казарин О. В. Безопасность программного обеспечения компьютерных систем. М.: МГУЛ, 2003, 212 с. |
|
[100] |
Платонов В. В. Программно-аппаратные средства обеспечения информационной безопасности вычислительных сетей. М.: Академия, 2006, 240 с. |
[101] |
Шнайер Б. Секреты и ложь. Безопасность данных в цифровом мире. СПб.: Питер, 2003, 368 с. |
Липаев В. Функциональная безопасность программных средств. Информационный бюллетень «Jet Info»08(135)/2004. Публикация от 27.01.2005 |
|
Липаев В. Функциональная безопасность программных средств, http://daily.sec.ru/ dailypblshow.cfm?rid=45&pid=11751&pos=7&stp=10&cd=18&cm=5&cy=2005 (дата обращения 05.05.2009) |
|
Состав нормативной базы, регламентирующей процесс разработки, эксплуатации, сопровождения и развития информационной системы железнодорожного транспорта. Информационная система железнодорожного транспорта. Системный проект. Кн. 2 (приложение 2), тема 10.00.76/95.00.00 НИОКР МПС № 29 от 29.01.96 г. М.: НИИЖА, 1997 |
|
BS EN 50128:2001 Системы телекоммуникационные, сигнализационные и системы для обработки данных, применяемые на железных дорогах. Программное обеспечение для систем управления и защиты на железных дорогах. Пер. с англ. (Railway applications. Communications, signalling and processing systems. Software for railway control and protection systems) http://emc.belsut.info/docs/standards/DIN_EN/EN_50128.pdf (дата обращения 05.05.2009) |
|
Йордан Э. Путь камикадзе. Как разработчику выжить в безнадежном море проектов. М.: Лори, 2000, 255 с. |
|
[107] |
Зотов В. Формирование описаний компонентов для внутрикристальной отладки цифровых устройств и встраиваемых микропроцессорных систем на основе программируемых модулей Xinix CORE Generator Tool // Компоненты и технологии. 2008, № 11 |
[108] |
Зотов В. Формирование описаний компонентов для внутрикристальной отладки цифровых устройств и встраиваемых микропроцессорных систем на основе программируемых модулей Xinix CORE Generator Tool. Ч. 2 // Компоненты и технологии. 2008, № 12 |
[109] |
Зотов В. Формирование описаний компонентов для внутрикристальной отладки цифровых устройств и встраиваемых микропроцессорных систем на основе программируемых модулей Xinix CORE Generator Tool. Ч. 2 // Компоненты и технологии. 2009, № 2 |
Зотов В. Формирование описаний компонентов для внутрикристальной отладки цифровых устройств и встраиваемых микропроцессорных систем на основе программируемых модулей Xinix CORE Generator Tool. Ч. 2 // Компоненты и технологии. 2009, № 3 |
|
Мейер Б. Объектно-ориентированное конструирование программных систем. М.: Издательско-торговый дом «Русская Редакция», «Интернет-университет информационных технологий», 2005, 1232 с, ил. |
|
[112] |
Гайсарян С. С. Объектно-ориентированные технологии проектирования прикладных программных систем. http://wm-help.net/books-online/print-page/55841/55841.html (дата обращения 16.07.2009) |
Методология JSD. http://wm-help.net/books-online/print-page/55841/55841-37.html (дата обращения 15.05.2009) |
|
Пайл Я. Ада - язык встроенных систем /Пер. под ред. А. А. Красилова. М.: Мир, 1984 |
|
Вендров А. Case-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998, 176 с. |
|
Марка Д.-А., МакГоуэнК. Методология структурного аннализа и проектирования SADT (Structured Analysis & Design Technique). Электронная библиотека. http://www.interface.ru/fset.asp?Url=/CASE/ prw.htm (дата обращения 15.05.2009) |
|
Леоненков А. В. UML 2 Самоучитель. СПб.: БХВ-Петербург, 2007, 576 с. |
|
Энсор Д., Стивенсон Й. Oracle. Проектирование баз данных. BHV-Киев, 2000, 560 с. |
|
Системная информатика. Сб. науч. тр. Вып. 9. Формальные методы и модели информатики. Новосибирск: Изд-во СО РАН, 2004 |
|
Макконнелл Д. Основы современных алгоритмов. М.: Техносфера, 2006, 368 с. |
|
Топорков В. В. Модели распределенных вычислений. М.: Физматлит, 2004, 320 с. |
|
Бэкон Д, Харрис Т. Операционные системы. Параллельные и распределенные системы. СПб.: Питер, Издательская группа BHV, 2004, 800 с. |
|
Ступников С. А. Моделирование композитных уточняющих спецификаций. Диссертация канд. техн. наук. М.: Ин-т проблем информатики РАН, 2006. На правах рукописи |
|
Никифоров А. Ю. Язык описания взаимодействия иерархических систем и его персонализация // Программные продукты и системы. 2009, № 1 |
|
Дорошенко А. Е., Шевченко Р. С. Система символьных вычислений для программирования динамических приложений, http://oai.org.ua/ index.php/record/view/3144 (дата обращения 25.12.2009) |
|
Блейхут Р. Быстрые алгоритмы цифровой обработки сигналов. М.: Мир, 1989, 448 с. |
|
Григорьев О. М. Аналитико-табличные процедуры для временных логик// Logical Studies. 2000, № 4 |
|
[128] |
Стемпковский А. Л. Методы логического и логико-временного анализа цифровых КМОП СБИС. М.: Наука, 2007 |
Гуц А. К. Математическая логика и теория алгоритмов. Электронная библиотека, http://mat-ua.narod.ru/mat/ Guz-Logika-Algoritmi.htm (дата обращения 16.05.2009) |
|
Лаврищева Е. М., Петрухин В. А. Методы и средства инженерии программного обеспечения: Уч. М.: МФТИ (ГУ), 2006, 304 с. |
|
Разработка технологии верификации управляющих программ со сложным поведением, построенных на основе автоматного подхода. Этап 1. Выбор направления исследований и базовых методов. Отчет № 2007.08.31. СПб.: СПбГУ ИТМО, 2007. http://is.ifmo.ru/verification/2007 01patent-verification.pdf (дата обращения 16.05.2009) |
|
Якушин. Программирование с защитой от ошибок, http://www.tspu .tula.ru/ivt/old site/umr/trpo/node74.html (дата обращения 16.05.2009) |
|
[133] |
Колесов A. "Go to" - выражение из четырех букв // BYTE Россия, 2001, № 8 (37) |
[134] |
Петраков А. В. Основы практической защиты информации: Учеб. пособие. М.: Салон-Пресс, 2005, 384 с. |
[135] |
Корт С. С. Теоретические основы защиты информации. М.: Гелиос АРВ, 2004, 240 с. |
Домашев А., Попов В., Правиков Д., Грунтович М. Программирование алгоритмов защиты информации. Изд. 2-е., М.: НОЛИДЖ, 2002, 416 с. |
|
Липаев В. В. Выбор и оценивание характеристик качества программных средств. Методы и стандарты. М.: СИНТЕГ, 2001, 228 с. |
|
Саттер Г., АлександрескуА. Стандарты программирования на C++. 101 правила и рекомендации. М.: «Вильяме», 2005, 224 с. |
|
[139] |
Сухомлин В. Система программирования тройного стандарта (ЗС++). Науч.-иссл. вычисл. центр МГУ им. М. В. Ломоносова. http://www citforum.ru/programming/prg96/94.shtml (дата обращения 16.05.2009) |
[140] |
Шпаковский Г. И., Серикова Н. В. Программирование для многопроцессорных систем в стандарте MPI. Минск: Изд-во БГУ, 2002, 323 с. |
Липаев В. В. Программная инженерия. Методологические основы: Учеб. / В. В. Липаев. Гос. ун-т- Высшая школа экономики. - М.: ТЕИС, 2006, 608 с. |
|
Липаев В. В. Системное проектирование сложных программных средств для информационных систем. М.: СИНТЕГ, 2002, 268 с. |
|
Структурное проектирование и структурное программирование. http://www.ssti.ru/kpi/informatika/Content/ biblio/M/inform man/gl 18 2.html (дата обращения 16.05.2009) |
|
[144] |
Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. М.: Бином. Лаборатория знаний «Интуит», 2008, 368 с. |
[145] |
Кулямин В. В. Перспективы интеграции методов верификации программного обеспечения: Труды Института системного программирования РАН. http://www.citforum.ru/SE/testing/integration (дата обращения 15.07.2009) |
[146] |
Липаев В. В. Тестирование крупных комплексов программ на соответствие требованиям: Учеб. М.: ИПЦ «Глобус», 2008, 376 с. |
[147] |
Липаев В. В. Системное проектирование сложных программных средств для информационных систем. М: СИНТЕГ, 2002, 268 с. |
Липаев В. В. Методы обеспечения качества крупномасштабных программных средств. М.: СИНТЕГ, 2003, 520 с, ил. |
|
Липаев В. В. Документирование сложных программных средств. М.: СИНТЕГ, 2005, 216 с. |
|
Липаев В. В., Филинов Е. Н. Мобильность программ и данных в открытых информационных системах. М.: Научная книга, 1997, 368 с. |
|
Очков В. Принцип неопределенности программирования, http://metod.ce.cctpu.edu.ru/edu/df/se/general/gen_08.html (дата обращения 15.05.2009) |
|
Структурное проектирование и структурное программирование. http://www.ssti.ru/kpi/informatika/Content/biblio/M/inform_man/gl_18_2.html (дата обращения 16.05.2009) |
|
Липаев В. В. Функциональная безопасность программных средств. М.: СИНТЕГ, 2004, 348 с. |
|
Конопелько В. К., Липницкий В. А. Теория норм синдромов и перестановочное декодирование помехоустойчивых кодов. Изд. 2-е, М.: Эдиториал УРСС, 2004, 176 с. |
|
Керман М. К. Программирование и отладка в Delphi: Учебный курс. М.: «Вильяме», 2003, 672 с. |
|
[156] |
Власов К. А., Смачёв А. С. Методика автоматизированной проверки возвращаемых кодов ошибок при тестировании программных интерфейсов. Тр. Института системного программирования РАН. М., 2007 |
Сайков, Б. Сбои компьютера: диагностика, профилактика, лечение. Изд. 2-е, М.: Бином. Лаборатория знаний, 2003, 351 с. |
|
Программный модуль дополнительного мониторинга TSS-2000 МuItimonitoring фирмы TSS (Россия), http://www.centers.ru/brands/tss/ model/mod221002280.htm (дата обращения 13.06.2009) |
|
[159] |
ЕС-16. Блок аварийного резервирования аппаратно-программного комплекса AMS-16/32. Техническое описание и инструкция по эксплуатации. М.: ООО «РОКСТОН», 2005. http://www.escortpro.ru/data/catalog/instruction/15112005121715.pdf (дата обращения 13.06.2009) |
Горбунов-Посадов М. М. Расширяемые программы. М.: Полиптих, 1999, 336 с. |
|
[161] |
Семенова И. И. Способ построения алгоритмов по многовариантным моделям. Развитие оборонно-промышленного комплекса на современном этапе: Мат. науч.-техн. конф.- 4.1. Омск: ОмГУ, 2003, с. 135-137. http://semenova-ii.narod.ru/stat/08.html (дата обращения 13.06.2009) |
Семенова И. И. Система автоматизированного построения многовариантных моделей. СибАДИ. http://semenova-ii.narod.ru/stat/08.html (дата обращения 13.06.2009) |
|
Тестирование и отладка приложений на С#. Skillsoft, /DDBS Prospero. http://shop.ddbs.ru/prog_49185.html (дата обращения 19.05.2009) |
|
Роббинс Д. Отладка приложений для Microsoft.NET и Microsoft Windows. Электронная библиотека Brain2life.[com], 42,2 МБ. http://www.brain2life.com/book/597.html (дата обращения 19.05.2009) |
|
Крюков В. А. Операционные системы распределенных вычислительных систем (распределенные ОС). Курс лекций. Лаборатория Параллельных Информационных Технологий. НИВЦ МГУ. Электронная книга. «Parallel.ru». http://www.parallel.ru/krukov/lec7.html (дата обращения 19.05.2009) |
|
Богатырев В. А. Отказоустойчивость распределенных вычислительных систем динамического распределения запросов и размещение функциональных ресурсов. Электронное научно-техническое издание «Наука и образование». Эл. № ФС 77 - 30569. Государственная регистрация № 0420900025. http://technomag.edu. ru/doc/56860.html (дата обращения 19.05.2009) |
|
[167] |
Таненбаум Э., ван Стенн. Распределенные системы. Принципы и парадигмы. М.: Питер, 2003, 877 с. Формат: pdf, 23.3 MB |
Таненбаум Э., ВудхаллА. Операционные системы. Разработка и реализация (+CD-ROM). СПб.: Питер, 2007, 704 с. Формат: djvu> 9472 кБ |
|
Красилов А. А. Информатика в семи томах. Т. 7. Интеллектуальные системы (Системы решения проблем). «Интеллсист». Интеллектуальные системы общего назначения. М., 1997-2003. http://www. intellsyst.ru/publications/_text/TOM7.shtml (дата обращения 19.05.2009) |
|
Ахо А. В., Лам М.-С, Рави С, Ульман Д.-Д. Компиляторы: принципы, технологии и инструменты. Изд. 2-е, М.: «Вильяме», 2008, 1184 с, ил. |
|
[171] |
Душкин Р. В. Опыт построения единого комплекса автоматизированных систем управления предприятием. // Инженер. Технолог. Рабочий: Публицистический производственно-технический журнал/ МАШИЗДАТ Вып. 5, 2009, с. 13-14 |
[172] |
Душкин Р. Лекция 1. Вводная лекция. http://roman-dushkin.narod .ru/fp_01.html (дата обращения 07.06.2009) |
Ксавье П. Delphi for NET. Руководство разработчика. М.: «Вильяме», 2005, 960 с, ил. |
|
Компилятор полного стандарта языка C++ как ядро систем разработки программного обеспечения. Сб. статей компании «Интерстрон». Приложение к журналу «Компьюлог». 2000, № 3. http://www.interstron.ru/old/pdf/komp_log.pdf (дата обращения 07.06.2009) |
|
Цирлов В., Миронов В., Марков А. Выявление уязвимостей в программном коде//Открытые системы. 2005. № 12. http://www.osp. ru/os/2005/12/380655 (дата обращения 07.06.2009) |
|
Чернов А. В. Анализ запутывающих преобразований программ. Труды ИСП РАН. 2008. http://www.citforum.idknet.com/security/articles/analysis (дата обращения 07.06.2009) |
|
[177] |
Кормен Т-Х., Лейзерсон Ч.-И., Ривест Р.-Л., Штайн К. Алгоритмы: построение и анализ. Изд. 2-е, М.: Издательский дом «Вильяме», 2008, 1297 с. |
Буч Г, МаксимчукР-А., Энгл М.-У, ЯнгБ.-Д., Коналлен Д., Хьюстон К.-А. Объектно-ориентированный анализ и проектирование с примерами приложений. Изд. 3-е, М.: Издательский дом «Вильяме», 2008, 720 с. |
|
Макаров А. В., Скоробогатов С. Ю., Чеповский А. М. Common Inter-mediate Language и системное программирование в Microsoft.NET М.: Интернет-университет информационных технологий, 2006, 314 с. http://www.rus-kniga.biz/tv246-298579.html (дата обращения 07.06.2009) |
|
Елманова Н. Полезные компоненты и утилиты для пользователей Delphi, C++Builder и IB Database: продукты компании BatSoft. Компьютер Пресс - CD. 1999. № 2. http://www.citforum.ru/progra mming/comp/comp02.shtml (дата обращения 07.06.2009) |
|
Элиенс А. Принципы объектно-ориентированной разработки программ. Изд. 2-е, М.: «Вильяме», 2002, 496 с. |
|
Налютин Н. Ю., Синицын С. В. Верификация программного обеспечения. М.: Бином. Лаборатория знаний «Интуит», 2008, 368 с. |
|
Плаксин М. А. Тестирование и отладка программ - для профессионалов будущих и настоящих. М.: Бином. Лаборатория знаний, 2007, 167 с. |
|
Тюрин Ю., Марков А. Анализ данных на компьютере. М.: Инфра-М, 2003, 544 с. |
|
Рубанов В. В., ХорошиловА. В., Шатохин Е. А. Т2С: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов. М.: Труды Института системного программирования РАН, 2008 г. http://www.citforum.ru/SE/testing/t2c/ (дата обращения 13.06.2009) |
|
Калбертсон Р., Браун К., Кобб Г Быстрое тестирование. М.: «Вильяме», 384 с. |
|
Иванова Г С. Технология программирования. М.: Изд.-во МГТУ им. Н. Э. Баумана, 336 с. |
|
[188] |
Медина К. Устройства ввода ошибок FBD-памяти для компьютеров IBM System х. http://www.ibm.com/developerworks/ru/library/es-fbd (дата обращения 14.06.2009) |
Климант Ю. В. C++. Дистанционное обучение программистов. Уроки по программированию. Урок 8. http://cipg.km.ru/lessons/ci/les08.html (дата обращения 14.06.2009) |
|
Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. М.: Лори, 544 с. |
|
[191] |
Макгрегор Д., Сайке Д. Тестирование объектно-ориентированного программного обеспечения: Практическое пособие. М.: ТИД «ДС», 432 с. |
[192] |
Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. СПб.: Питер, 2004, 320 с. |
[193] |
Бек К. Экстремальное программирование: разработка через тестирование. СПб.: Питер, 2003, 223 с. |
Майерс Г. Искусство тестирования программ. Пер. с англ. М.: Финансы и статистика, 1982, 176 с. |
|
Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. Лекция 13: Документация, сопровождающая процесс верификации и тестирования (отчеты) «Интернет университет. Информационные технологии» http://www.intuit.ru/department/se/verify/13 (дата обращения 25.06.2009) |
|
[196] |
Романюк С. Г Оценка надежности программного обеспечения. М.: НИИСИ РАН. http://www.uprav.biz/materials/innov/view/2273.html (дата обращения 25.06.2009) |
[197] |
Смагин В. А. Форсированные быстродействием испытания программного обеспечения на надежность. http://sprobv-17.narod.ru (дата обращения 25.06.2009) |
[198] |
Смагин В. А. О форсированных испытаниях программного обеспечения на надежность, http://sprobv-17.narod.ru (дата обращения 25.06.2009) |
[199] |
Смагин В. А. Введение в точностную теорию надежности программного обеспечения, http://sprobv-17.narod.ru (дата обращения 25.06.2009) |
Казарин О. В. Безопасность программного обеспечения компьютерных систем. М.: МГУЛ, 2003, 212 с. http://infonet.cherepovets.ru /citforum/security/articles/kazarin (дата обращения 25.06.2009) |
|
Чернов А. В. Анализ запутывающих преобразований программ. Тр. Института системного программирования РАН. М., 2003. http://www.citforum.ru/security/articles/analysis (дата обращения 25.06.2009) |
|
Ковалев В. В., Компаниец Р. И., Маньков Е. В., Дьяченко Д. А., Пустарнаков В. Ф. Анализ и защита потоков управления в исполняемых кодах программ. Информационно-издательский центр CONNECT! Мир связи, 2006, № 4 |
|
Ахо А. В., Хопкрофт Д.-Э., Ульман Д.-Д. Структуры данных и алгоритмы. Пер. с англ: Уч. пос. М.: Издательский дом «Вильяме», 2000, 384 с. |
|
Липаев В. Программно-технологическая безопасность информационных систем, http://www.info-system.ru/security/security_pr_tech_ security.html (дата обращения 25.06.2009) |
|
Касперский К. Техника оптимизации программ - эффективное использование памяти. БХВ-Петербург, 2003, 464 с. |
|
Разработка сложного программного обеспечения, http://www.devcomplexsoft.ru (дата обращения 25.06.2009) |
|
Лаврищева Е. М., Петрухин В. А. Методы и средства инженерии программного обеспечения: Уч. М.: МФТИ (ГУ), 2006, 304 с. http://window.edu.ru/window catalog/files/r41699/lavrishcheva petrukhin.pdf (дата обращения 26.06.2009) |
|
[208] |
Тенихин А. Л. Применение формальных методов доказательства при создании безопасных систем. СПбГТУ, кафедра ИБКС. http://www.ssl. stu.neva.ru/ssl/publications/magazine/2000/2/3/tenihin.pdf (дата обращения 26.06.2009) |
[209] |
Боуэн Д.-П., Хинчи М.-Д. Десять заповедей формальных методов, http://www.osp.ru/pcworld/1997/09/157957 (дата обращения 26.06.2009) |
Немолочнов О.Ф., Зыков А.Г., Осовецкий Л.Г., Поляков В.И., Петров К.В. Тестирование логических неисправностей вычислительных процессов в программах//Информационные технологии. 2007, № 12, с. 2-5 |
|
Колдовский В. Разработка ПО: метрики программных проектов. Киев: Издательский Дом ITC, 2009. http://itc.ua/node/27774 (дата обращения 26.06.2009) |
|
[212] |
Сбор и публикация проектных метрик в процессе разработки программного обеспечения на базе штатных средств IBM Rational Clear Case. OLAP.ru http://www.olap.ru/home.asp?artld=445 (дата обращения 26.06.2009) |
Николе Э., Петерсон Г Метрики управления качеством защиты приложений. Портал «Открытые системы. СУБД», http://www.osp. ru/os/2007/04/4219959 (дата обращения 26.06.2009) |
|
Кулямин В. В. Компонентный подход в программировании. Лекция 8: Образцы проектирования. БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру 2006. http://www.intuit.ru/department/se/compprog/8/1.html (дата обращения 26.06.2009) |
|
Кулямин В. В. Компонентный подход в программировании. Курс лекций. БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру. 2006. http://www.intuit.ru/department/ se/compprog/1 (дата обращения 26.06.2009) |
|
Салливан Э. Время-деньги. Создание команды разработчиков программного обеспечения. Пер. с англ. М.: Издательско-торговый дом «Русская Редакция», 2002, 368 с, ил. http://www.proklondike.com (дата обращения 27.06.2009) |
|
Руководящий документ. Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей. Утвержден решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г., № 114 |
|
Бурьяк А. Компактное программирование. Программирование на основе прототипов. Prototype-Based Programming (РВР). http://compact-programming.narod.ru/CP0003.htm (дата обращения 28.06.2009) |
|
[219] |
Уолш Д. (George Walsh). Создание прототипа программы с помощью библиотеки OpenMP*. Intel, 2006. http://www.intel.com/cd/ids/developer/emea/rus/dc/windows/windows64/191144.htm (дата обращения 28.06.2009) |
Павловская ТА. Программирование на языке высокого уровня. СПб.: Питер, 2007, 432 с. |
|
Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. М.: Лори, 2003, 592 с. |
|
Советов Б. Я., Яковлев А. М. Моделирование систем. Изд. 3-е перераб. и доп. Электронная библиотека образовательных и просветительских изданий. М., 2001, 374 с. |
|
[223] |
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы |
Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: «Вильяме», 2002, 448 с. |
|
Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: «Вильяме», 2002, 448 с. |
|
Пипер Ш., Пол Д., Сколт М. Новая эра в оценке производительности компьютерных систем. (Sean Pieper, Joann Paul, Michael Schulte. A New Era of Performance Evaluation, IEEE Computer, September 2007. IEEE Computer Society, 2007. All rights reserved. Reprinted with permission). Пер. с англ. Портал «Открытые системы - СУБД», http://www.osp.ru/os/2007/09/4569364 (дата обращения 29.06.2009) |
|
Елашкин М. Производительность СУБД и тесты ТРС. «BYTE - Платформы и технологии». 2004, № 3 (67). http://www.bytemag.ru/ articles/detail.php?ID=8571 (дата обращения 29.06.2009) |
|
Анализ производительности 64- и 32-разрядных многопроцессорных вычислительных систем в программном комплексе вычислительной гидрогазодинамики STAR-CD. Gjhnfk «iXBT.com». http://www.ixbt. com/cpu/star-cd-tests.shtml (дата обращения 29.06.2009) |
|
Пушников А. Ю. Введение в системы управления базами данных. Глава 9. Транзакции и целостность баз данных. Портал «CITFORUM.ru». http://www.citforum.ru/database/dblearn/dblearn09.shtml (дата обращения 29.06.2009) |
|
[230] |
Преодолевая ограничения Windows: физическая память. Портал «Русский хакер.ру». http://rushacker.ru/index.php?autocom=ibwiki& cmd=article&id=5 (дата обращения 29.06.2009) |
[231] |
Ограничение пользователей Портал «FreeBSD». http://www freebsd.org.ua/doc/ru_RU.KOI8-R/books/handbook/users-limiting.html (дата обращения 29.06.2009) |
Грудина П. Настройка ограничений пользователям. Портал IT профессионалов «Grudina.ru». http://grudina.info/articles/freebsd/nastroyka-ogranicheniy-polzovatelyam.html (дата обращения 29.06.2009) |
|
Боне Ш. Эпоха систем, терпимых к изменениям. Портал «Открытые системы - СУБД», http://www.osp.ru/os/2007/07/4394365 (дата обращения 29.06.2009) |
|
Системы менеджмента качества. Руководящие указания по менеджменту конфигурации. Пер. с англ. Портал «Стандартинформ» http://www.vniiki.ru/doc.aspx?catalogid=iso&classid=-1&search=10007. (дата обращения 29.06.2009) |
|
Белладжио Д., Миллиган Т. Стратегия управления конфигурацией программного обеспечения с использованием IBM Rational ClearCase. Изд. 2-е, М.: ДМК Пресс, 2008, 384 с. |
|
ГОСТ Р 51901.11-2005 (МЭК 61882:2001) Менеджмент риска. Исследование опасности и работоспособности. Прикладное руководство, http://intranet.fastweb.ru/docs/gost/item 566 (дата обращения 29.06.2009) |
|
Шубинский И. Б. Методы анализа рисков нарушения безопасности систем управления. «Евроазия - Вести». 2006, Вып. 6. http://www.eav.ru/publ1p.php?publid=2006-05a14 (дата обращения 29.06.2009) |
|
Общие положения безопасности атомных станций. Приказ ГКЯР Украины от 19.11.2007, № 162. http://www.snrc.gov.ua/nuclear/ru/publish/article/82143 (дата обращения 29.06.2009) |
|
Смит Д.Д. Безотказность, ремонтопригодность и риск. Практические методы для инженеров, включая вопросы оптимизации надежности и систем, связанных с безопасностью. М.: Группа ИДТ, 2007, 431 с. http://www.centrmag.ru/book2286985.html (дата обращения 29.06.2009) |
|
Мухин О.И. Моделирование систем. Учебник на портале «Stratum.ac.ru» http://stratum.ac.ru/textbooks/modelir/index.html (дата обращения 29.06.2009) |
|
[241] |
Николенко С. Скрытые марковские модели. Машинное обучение - ИТМО, осень 2006. http://logic.pdmi.ras.ru/~sergey/teaching/mlbayes/06-hmm.pdf (дата обращения 29.06.2009) |
[242] |
Куликов Г.Г, Флеминг П.-Д., Брейкин Т.В., Арьков В.Ю. Марковские модели сложных динамических систем: идентификация, моделирование и контроль состояния (на примере цифровой САУ ГТД). Уфа: Уфим. гос. авиац. техн. ун-т, 1998, 103 с. |
[243] |
Рухман Е.П., Шеховцов О.И. Марковские модели в задачах помехоустойчивости и надежности передачи информации: Учеб. пособие. П.: ЛЭТИ, 1981, 78 с. |
Моттль В.В., Мучник И.Б. Скрытые марковские модели в структурном анализе сигналов. М.: Физматлит, 1999, 352 с. |
|
Алексеев A. FTA. Дерево отказов как метод структурного анализа. Портал «IT Expert» http://www.itexpert.ru/rus/ITEMS/77-30 (дата обращения 29.06.2009) |
|
ГОСТ Р 51901.14-2007 Менеджмент риска. Структурная схема надежности и булевы методы |
|
Абельсон Х., Сассман Д.Д., Сассман Д. Структура и интерпретация компьютерных программ - язык ЛИСП (Lisp). М.: Добросвет, 2004, 608 с. |
|
Волков И.М., Грачева М.В. Вероятностные методы анализа рисков, http://www.ndc.ru/ru/press/pubs/depo/archive/22/article5.htm (дата обращения 29.06.2009) |
|
Орлов А.И. Теория принятия решений: Учеб. пособие. М.: Март, 2004, 656 с. http://orlovs.pp.ru (дата обращения 27.06.2009) |
|
Орлов А.И. Высокие статистические технологии //Заводская лаборатория. 2003, Т. 69, № 11, с. 55-60. http://orlovs.pp.ru (дата обращения 27.06.2009) |
Ключевые слова: безопасность функциональная, связанные с безопасностью зданий и сооружений системы, методы и средства снижения риска, методы оценки соответствия