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

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

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

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

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

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

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

Литература:

Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.

VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.

B.6.5 Динамический анализ

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6) и в МЭК 61508-3 (таблицы А.5 и А.9).

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

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

Литература:

Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.

VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.

B.6.6 Анализ отказов

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).

В.6.6.1 Виды отказов и анализ их последствий

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

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

Литература:

System Reliability Engineering Methodology: A Discussion of State of Art. J. B. Fussel, J. S. Arend, Nuclear Safety 20(5), 1979.

Reliability Technology. A. E. Green, A. J. Bourne, Wiley-lnterscience, 1972.

Fault Tree Handbook. W. E. Vesely et al, NUREG-0942, Division of System Safety Office of Nuclear Reactor Regulation, U.S. Nuclear Regulatory Commission, Washington, DC 20555, 1981.

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

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.10, В.3 и В.4).

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

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

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

Литература:

The Cause Consequence Diagram Method as a Basis for Quantitative Accident Analysis. B. S. Nielsen, Riso-M-1374, 1971.

B.6.6.3 Анализ дерева событий

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.4).

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

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

Литература:

Event Trees and their Treatment on PC Computers. N. Limnious и J. P. Jeannette, Reliability Engineering, Vol. 18, No. 3, 1987.

B.6.6.4 Виды отказов и анализ влияний событий на критичность компонентов

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.10 и В.4).

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

Описание: критичность может быть ранжирована многими методами. Наиболее сложный метод описан Обществом автомобильных инженеров (Society for Automotive Engineers - SAE) в ARP 926. В этом методе значение критичности для любого компонента определяется числом отказов конкретного вида, предполагаемым в процессе выполнения каждого миллиона операций, реализуемых в критическом режиме. Критичность является функцией девяти параметров, большинство из которых должны быть измерены. Очень простой метод определения критичности состоит в умножении вероятности отказа компонента на величину ущерба, который может быть при этом нанесен; этот метод аналогичен простой оценке показателя риска [3].

Литература:

Design Analysis Procedure for Failures Modes, Effects и Criticality Analysis (FMECA). Aerospace Recommended Practice (ARP) 926, Society of Automotive Engineers (SAE), США, 15 September 1967.

B.6.6.5 Анализ дерева отказов

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.4).

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

Описание: начиная с события, которое может непосредственно вызвать угрозу или опасные последствия («событие вершины дерева»), анализ проводится по ветвям дерева. Комбинации причины описываются логическими операторами («И», «ИЛИ» и т. д.). Затем анализируются промежуточные причины тем же способом и т. д., возвращаясь к базовым событиям, где анализ прекращается.

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

Литература:

System Reliability Engineering Methodology: A Discussion of State of Art. J. B. Fussel и J. S. Arend, Nuclear Safety 20 (5), 1979.

Fault Tree Handbook. W. E. Vesely et all, NUREG-0492, Division of System Safety Office of Nuclear Reactor Regulation, US Nuclear Regulatory Commission Washington, DC 20555, 1981.

Reliability Technology. A. E. Greene и A. J. Bourne, Wiley-lnterscience, 1972.

B.6.7 Анализ наихудшего случая

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).

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

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

В.6.8 Расширенное функциональное тестирование

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).

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

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

Литература:

Functional Program Testing and Analysis. W. E. Howden, McGraw-Hill, 1987.

The Art of Software Testing. G. J. Myers, Wiley & Sons, New York, 1979.

Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.

B.6.9 Испытания в наихудших случаях

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).

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

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

В.6.10 Испытания с введением неисправностей

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).

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

Описание: представленный метод оценки зависимостей является качественным. Для описания местоположения и типа неисправностей, а также способа их внесения предпочтительно используются детализированные функциональные блоки, схемы и схемные диаграммы: например, питание может не поступать на различные модули; линии питания, линии общей шины или адресные линии могут быть разомкнуты/коротко замкнуты; компоненты или их порты могут быть разомкнуты или закорочены; реле могут быть замкнуты или разомкнуты, либо их действия могут выполняться в неправильные моменты времени и т. д. Возникающие в результате отказы системы классифицируются, например, в МЭК 60812 (таблицы I и II). Обычно вводятся одиночные неисправности в устойчивом состоянии системы. Однако, в случае, если неисправность не обнаруживается тестом встроенной диагностики или оказывается не очевидной, она может сохраниться в системе и вызвать следующую неисправность. При этом количество неисправностей может быстро возрасти многократно [3], [9].

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

Литература:

Integrity Testing of Process Control Systems. R. J. Lasher, Control Engineering 36 (11), 152-164, October 1989.

Приложение С
(справочное)
Анализ методов и средств достижения полноты безопасности программного обеспечения
(см. МЭК 61508-3)

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

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

Литература:

System - Safety Society of America System Safety Analysis Handbook. System Safety Society, New Mexico Chapter. PO Box 95424, Albuquerque NM, USA.

Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.

Encyclopaedia of Software Engineering. Ed. J. Marciniak. John Wiley & Sons, 1994, ISBN 0-471-54004-8.

Software Engineer's Reference Book. Ed. J. McDermid. Butterworth-Heinemann, 1991, ISBN 0-7506-1040-9.

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

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

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

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.2 и А.4).

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

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