---

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

Литература:

Software Engineering: Planning for Change. D. A. Lamb. Prentice-Hall, 1988.

On Design and Development of Program Families. D. L. Parnas. IEEE Trans SE-2, March 1976.

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

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

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

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

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

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

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

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

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

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

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

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

Литература:

Structured Design - Fundamentals of a Discipline of Computer Program and Systems Design. E. Yourdon, L. L. Constantine, Prentice-Hall, 1979, ISBN 0-13-854471-9.

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература:

DIN V VDE 0801 A1: Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben (Principles for Computers in Safety-Related Systems). Änderung 1 zu DIN V VDE 0801/01.90. Beuth-Verlag, Berlin, 1994. Guidelines for safe automation of chemical processes. CCPS, AlChE, New York, 1993.

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

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

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

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

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

Обнаружение сбоев основывается на принципах избыточности [в основном при обнаружении сбоев аппаратных средств (см. МЭК 61508-2, приложение А)] и разнообразия (программные ошибки). Необходим один из способов голосования для определения корректности результатов. Применимы специальные методы, к которым относятся программирование утверждений, программирование N-версий и множественной безопасности. Для аппаратных средств: введение дополнительных сенсоров; контуров регулирования; кодов, проверяющих ошибки, и др.

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

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

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

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

Литература:

Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN 1-85166-203-0.

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

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

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

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

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

Литература:

The Technology of Error Correcting Codes. E. R. Berlekamp, Proc. IEEE 68 (5), 1980.

A Short Course on Error Correcting Codes. N. J. A. Sloane, Springer Verlag, Wien, 1975.

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

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

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

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

ПРИМЕР -

assert < pre-condition>;

action 1;

………..

action x;

assert < post-condition>;

Литература:

A Discipline of Programming. E. W. Dijkstra, Prentice-Hall, 1976.

The Science of Programming. D. Gries, Springer Verlag, 1981.

Software Development - A Rigorous Approach. С. В. Jones, Prentice-Hall, 1980.

C.3.4 Методы «подушки безопасности»

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

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

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

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

Литература:

Using Al Techniques to Improve Software Safety. Proc. IFAC SAFECOMP 88, Sarlat, France, Pergamon Press, October 1986.

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

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

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

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

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

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

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

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

Литература:

Dependable Computing: From Concepts to Design Diversity. A. Avizienis and J. С Laprie, Proc. IEEE 74 (5), May 1986.

A Theoretical Basis for Analysis of Multi-version Software subject to Co-incident Failures. D. E. Eckhardt and L. D. Lee, IEEE Trans SE-11 (12), 1985.

Computers can now perform vital functions safely. Otto Berg Von Linde, Railway Gazette International, Vol. 135, No. 11, 1979.

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

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