терминологические справочники.
Литература:
EWICS European Workshop on Industrial Computer Systems, TC 7: Safety Related Computers - Software Development and Systems Documentation. Verlag TÜV Rheinland, Köln, 1985.
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
Entwicklungstechnik sicherheitsverantwortlicher Software in der Eisenbahn-Signaltechnik. U. Feucht, Informatik-Fachberichte 86, Springer Verlag, Berlin, 184-195, 1984.
Richtlinie zur Erstellung und Prüfung sicherheitsrelevanter Software. K. Grimm, G. Heiner, Informatik Fachberichte 86, Springer Verlag, Berlin, 277-288, 1984.
B.1.3 Разделение систем, связанных с безопасностью, и систем, не связанных с безопасностью
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 и В.6).
Цель: предотвращение влияния систем, связанных с безопасностью, на системы, не связанные с безопасностью, в непредвиденных ситуациях.
Описание: в спецификации должно быть определено, возможно ли разделение систем, связанных и не связанных с безопасностью. Должны быть установлены четкие спецификации взаимодействия между системами, связанными и не связанными с безопасностью. Четкое их разделение снижает затраты на тестирование систем, связанных с безопасностью.
Литература:
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.1.4 Разнообразие аппаратных средств
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы А.16, А.17 и А.19).
Цель: обнаружение систематических отказов при выполнении операций EUC с использованием разнообразных компонентов с различными частотами и типами отказов.
Описание: для разнообразных каналов систем, связанных с безопасностью, используются различные типы компонентов. Это снижает вероятность отказов по общей причине (например увеличение напряжения по сравнению с номиналом, электромагнитные влияния) и повышает вероятность обнаружения таких отказов.
Существование различных средств выполнения требуемой функции, например применение других физических принципов, предполагает возможность использования других способов решения проблемы обнаружения систематических отказов. Возникает разнообразие типов используемых способов. Это функциональное разнообразие дает возможность использовать различные подходы для достижения одного и того же результата.
Литература:
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.2 Спецификация требований к безопасности E/E/PES
Главная цель: создание спецификации, которая, по возможности, была бы полна, свободна от ошибок, противоречий и проста для проверки.
В.2.1 Структурирование спецификации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 и В.6).
Цель: уменьшение сложности путем создания иерархической структуры частичных требований. Исключение ошибок интерфейса между требованиями.
Описание: данный метод разделяет функциональную спецификацию на частичные требования так, чтобы между ними существовали, по возможности, простейшие отношения. Этот метод применяется последовательно до тех пор, пока не будут получены небольшие четкие частичные требования. В результате получается иерархическая структура частичных требований, которая создает основу для спецификации полных требований. Данный метод выделяет интерфейсы между частичными требованиями и особенно эффективен при его использовании для исключения ошибок интерфейса.
Литература:
Structured Analysis and System Specification. Т. De Marco, Yourdon Press, Englewood Cliffs, 1979.
ESA PSS 05-02, Guide to the user requirements definition phase, European Space Agency, 1989.
B.2.2 Формальные методы
Примечания
1 Подробные сведения о конкретных формальных методах приведены в С.2.4.
2 Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 и В.6).
Цель: создание недвусмысленной и согласованной спецификации с целью обнаружения ошибок и пропусков.
Описание: формальные методы обеспечивают средства разработки и описания системы на конкретном этапе ее спецификации или проектирования. Результирующее описание имеет математическую форму и может быть подвержено математическому анализу для обнаружения различных классов несогласованностей или некорректностей. Более того, такое описание может быть в некоторых случаях проанализировано на ЭВМ подобно тому, как синтаксис исходной программы проверяется компилятором, или поддержано средствами анимации для изображения различных аспектов поведения описываемой системы. Анимация может дать дополнительное подтверждение соответствия системы как реальным, так и формально заданным требованиям, поскольку анимация улучшает восприятие человеком поведения системы.
Формальный метод может в общем случае предлагать нотацию (в основном некоторые методы дискретной математики), средства для вывода описания в данной нотации и различные виды анализа для проверки корректности различных свойств описаний.
Проектирование, начиная с математически формальной спецификации, с помощью последовательности пошаговых уточнений может привести к созданию логической схемы.
Литература:
Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.
HOL: A Machine Orientated Formulation of Higher Order Logic. M. Gordon, University of Cambridge Technical Report Number 68, 1985.
В.2.3 Полуформальные методы
Цель: создание недвусмысленных и согласованных частей спецификации с целью обнаружения ошибок и пропусков.
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1, В.2 и В.6) и в МЭК 61508-3 (таблицы А.1, А.2 и А.4).
B.2.3.1 Общие положения
Цель: убедиться в том, что проект соответствует своей спецификации.
Описание: полуформальные методы обеспечивают средства создания описания системы на стадиях ее разработки (например, спецификации, проектирования или кодирования). Описание может быть в некоторых случаях проанализировано на ЭВМ или для отображения различных аспектов поведения системы использована анимация. Анимация может придать дополнительную уверенность в том, что система соответствует как реальным, так и специфицированным требованиям.
В следующих пунктах настоящего приложения описаны два полуформальных метода.
B.2.3.2 Метод конечных автоматов/диаграммы переходов состояний
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.5 и В.7).
Цель: проведение моделирования, специфицирование или реализация структуры управления системы.
Описание: многие системы могут быть описаны в терминах их состояний, входов и действий. Таким образом, находясь в состоянии S1 и при получении входа I, система может выполнить действие А и перейти в состояние S2. Путем описания действий системы для каждого входа в каждом состоянии можно полностью описать систему. Такая модель системы называется «автоматом с конечными состояниями». Ее часто изображают в виде так называемой «диаграммы переходов состояний», которая показывает, как система переходит из одного состояния в другое, или в виде матрицы, в которой для каждого состояния и входа задаются действия по переходу в новое состояние.
В случае, если система усложняется или имеет естественную структуру, то это может быть отражено в уровневой структуре «автомата с конечными состояниями».
Спецификация (проект), выраженная (ый) в виде «автомата с конечными состояниями», могут быть проверены:
- на полноту (система должна иметь действие и новое состояние для каждого входа в каждом состоянии);
- согласованность (только одно изменение состояния описывается для каждой пары состояние/вход) и
- достижимость (можно или нельзя перейти из одного состояния в другое при любой последовательности входов).
Это важные свойства для критических систем. Инструменты для обеспечения этих проверок легко разработать. Существуют также алгоритмы, позволяющие автоматически генерировать тестовые примеры для верификации реализаций «автомата с конечными состояниями» или анимации модели «автомата с конечными состояниями».
Литература:
Introduction to theory of Finite State Machines. A. Gill, McGraw-Hill, 1962.
B.2.3.3 Метод сетей Петри
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.5 и В.7).
Цель: моделирование соответствующих аспектов поведения системы, оценка и, возможно, повышение безопасности и эксплуатационных требований путем анализа и повторного проектирования.
Описание: сети Петри относятся к классу моделей, описываемых теорией графов, и используются для представления информации и управления потоками в системах, в которых процессы конкурентны и асинхронны.
Сеть Петри - это сеть позиций и переходов. Позиции могут быть «маркированными» или «немаркированными». Переход считают «активизированным», если все его входы маркированы. В активизированном состоянии позиции разрешается (но не требуется) быть «возбужденной». Если позиция «возбуждена», то вход, поступающий на переход, становится немаркированным, а вместо него каждый выход из перехода оказывается маркированным.
Потенциальные опасности могут быть представлены в виде конкретных состояний (маркировок) в модели сети Петри. Модель может быть расширена с тем, чтобы обеспечить возможности моделирования систем во времени. И хотя «классические» сети Петри концентрируются на моделировании потоков управления, существуют некоторые расширения модели сети Петри, в которых моделируются потоки данных.
Литература:
Petri nets: Properties, analysis and applications. T. Murata, Proc. IEEE 77 (4), 541-580, April 1989.
Safety analysis using Petri nets. N. G. Leveson, J. L. Stolzy, Proc. 15th Ann. Int. Symp on Fault-Tolerant Computing, 358-363, IEEE, 1985.
Using Petri nets for safety analysis of unmanned Metro system. M. El Koursi, P. Ozello, Proc. SAFECOMP '92, 135-139, Pergamon Press, 1992.
Net theory and applications. W. Brauer (ed), Lecture Notes in Computer Science, Vol. 84, Springer Verlag, 1980. Petri net theory and modelling of systems. J. L. Peterson, Prentice Hall, 1981.
A tool requirements specification and analysis real time software based on timed Petri nets. S. Bologna, F. Pisacane, С Ghezzi, D. Mandrioli, Proc. SAFECOMP 88, 9-11 November 1988. Fulda, Fed. Rep. of Germany, 1988.
B.2.4 Автоматизированные средства разработки спецификации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 и В.6) и в МЭК 61508-3 (таблицы А.1 и А.2).
B.2.4.1 Общие положения
Цель: использование формальных методов спецификации для упрощения автоматического обнаружения неоднозначностей и полноты.
Описание: данный метод создает спецификацию в виде базы данных, которая может автоматически анализироваться для оценки согласованности и полноты. Инструмент спецификации может в интересах пользователя использовать анимацию различных аспектов специфицированной системы. В общем случае данный метод поддерживает создание не только спецификаций, но и этап проектирования, а также другие этапы жизненного цикла. Инструменты спецификаций могут быть классифицированы в соответствии со следующими пунктами настоящего приложения.
B.2.4.2 Инструменты, не ориентированные на конкретный метод
Цель: помощь пользователю в составлении правильной спецификации, применяя подсказки и формируя связи между соответствующими частями.
Описание: инструмент спецификаций освобождает пользователя от некоторой рутинной процедуры, поддерживает управление проектом и не представляет из себя какую-либо конкретную методологию разработки спецификаций. Относительная независимость пользователей от метода позволяет быть более свободными при выборе конкретного метода и дает немного специальной поддержки, необходимой при создании спецификаций, что усложняет освоение системы.
Литература:
Integrierte Rechnerunterstützung fur Entwicklung, Projektmanagement und Produktverwaltung mit EPOS. R. Lauber, P. Lempp, Elektron. Rechenanlagen 27, Heft 2, 68-74, 1985.
B.2.4.3 Процедура, ориентированная на модель с иерархическим анализом
Цель: помощь пользователю в создании правильной спецификации, обеспечении согласованности между описаниями процессов и данных на различных уровнях абстрагирования.
Описание: данный метод дает функциональное представление о необходимой системе (структурный анализ) на различных уровнях абстрагирования (степень точности). Структурный анализ проводится на различных уровнях, как с процессами, так и с данными. Оценка неоднозначности и полноты возможна между иерархическими уровнями, а также между двумя функциональными единицами (модулями) на одном и том же уровне.
Литература:
Structured Analysis for Requirement Definition. D. T. Ross, K. E. Schomann jr, IEEE Trans, on SE, Januay 1977.
B.2.4.4 Модели сущности
Цель: помощь пользователю в создании правильной спецификации на основе использования при описании системы сущностей и отношений между ними.
Описание: описание проектируемой системы в виде совокупности объектов и отношений между ними позволяет определять, какие отношения могут интерпретироваться системой. В общем случае эти отношения позволяют описывать иерархическую структуру объектов, поток данных, отношения между данными и данные, зависимые от конкретных производственных процессов. Этот классический подход расширен применением управления процессами. Возможности обследования и поддержка пользователя зависят от разнообразия проиллюстрированных отношений. Но множество возможностей представления усложняет применение этого метода.
Литература:
PSL/PSA Computer-aided Technique for Structured Documentation and Analysis of Information Processing. D. Teichroew, E. A. Hershey, IEEE Trans on SE, Jan 1977.
Computer Aided Software Development. D. Teichroew, E. A. Hershey, Y. Lamamoto, Beitrag in: Verfahren und Hilfsmittel fbr Spezifikation und Entwurf von Prozeβautomatisierungs-systemen. Hommel (ed.), Bericht KfK-PDV 154, Kernforschungszentrum Karlsruhe, 1978.
PCSL und ESPRESO - zwei Ansätze zur Formalisierung der Prozessrechner Software-spezifikation. J. Ludewig, Gl-Fachtagung Prozessrechner 1981, Informatik-Fachberichte Bd. 39, Springer Verlag, Berlin, 1981.
B.2.4.5 Стимул и ответ
Цель: помощь пользователю в создании правильной спецификации путем идентификации взаимоотношений «стимул-ответ».
Описание: взаимоотношения между объектами системы определены в нотации «стимулы» и «ответы». Используется простой и легко расширяемый язык, который содержит элементы языка, представляющие объекты, взаимоотношения, характеристики и структуры.
Литература:
A Requirements Engineering Methodology for Real-time Processing Requirements. M. W. Alford, IEEE Trans on SE, January 1977.
The Specification System X-SPEX - Introduction and Experiences. G. Dahll, J. Lahti, Proc. SAFECOMP 83, 111-118.
