Цель: повышение вероятности выполнения программой, в конечном счете, своих заданных функций.
Описание: некоторые различные разделы программы, которые часто пишутся независимо, предназначены для выполнения одной требуемой функции. Из таких разделов конструируется окончательная программа. Сначала выполняется первый раздел, называемый первичным. Далее происходит тестирование его результатов. Если проверка проходит успешно, результат принимается и передается следующим разделам программы. Если проверка дает отрицательный результат, то все побочные эффекты первого сбрасываются и выполняется второй раздел, называемый первой альтернативой. Далее следует тестирование второго раздела, которое выполняется аналогично первому. При необходимости могут быть предусмотрены вторая, третья и т. д. альтернативы.
Литература:
System Structure for Software Fault Tolerance. B. Randall. IEEE Trans Software Engineering, Vol. SE-1, No. 2, 1975.
Fault Tolerance - Principles and Practice. T. Anderson, P. A. Lee, Prentice-Hall, 1981.
C.3.7 Восстановление предыдущего состояния
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: обеспечение исправления функциональных операций при наличии одной или нескольких ошибок.
Описание: при обнаружении ошибки система возвращается в первоначальное внутреннее состояние, правильность которого была подтверждена ранее. Данный метод предполагает частое сохранение внутреннего состояния в так называемых четко определенных контрольных точках. Сохранение может быть выполнено глобально (для всей базы данных) или частично (для изменений только между контрольными точками). После этого система должна устранить изменения, произошедшие за это время путем занесения в журнал (аудиторское отслеживание действий) компенсации (все результаты этих изменений аннулируются) или внешнего (ручного) способа.
Литература:
Software Fault Tolerance (Trends in Software, No. 3), M. R. Lyu (ed.), John Wiley & Sons, April 1995, ISBN 0471950688.
C.3.8 Прямое восстановление
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: обеспечение исправления функциональных операций при наличии одного или нескольких сбоев.
Описание: при обнаружении сбоя текущее состояние системы анализируется для достижения состояния, которое через некоторое время будет признано правильным. Данный метод особенно подходит для систем реального времени с небольшой базой данных и высокой скоростью изменения внутреннего состояния. Предполагается, что, по меньшей мере, часть состояний системы может влиять на окружение, и окружение влияет только на часть состояний системы.
Литература:
Software Fault Tolerance (Trends in Software, No. 3), M. R. Lyu (ed.), John Wiley & Sons, April 1995, ISBN 0471950688.
C.3.9 Механизмы повторных попыток парирования сбоя
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: парирование обнаруженного сбоя с помощью механизмов повторных попыток.
Описание: в случае обнаружения сбоя или ошибочного условия предпринимаются попытки парирования сбоя или восстановления ситуации путем повторного выполнения того же кода. Восстановление с помощью повторной попытки может быть полным в виде перезагрузки и повторного пуска процедуры, либо небольшим в виде перепланирования и повторного пуска задачи после выполнения блокировки по времени программы или управляющего действия задачи. Методы повторной попытки широко используются при коммуникационных сбоях или при восстановлении от ошибок, и условия повторной попытки могут быть отделены флажками от ошибки протокола связи (контрольная сумма и т. д.) или от подтверждающего ответа блокировки по времени коммуникации.
Литература:
Reliable Computer Systems: Design and Evaluation, D. P. Siewiorek and R. S. Schwartz, A. K. Peters Ltd., 1998, ISBN 156881092X.
C.3.10 Сохранение достигнутых состояний
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: безопасное прекращение работы программы в случае, если она попытается выполнить неразрешенное действие.
Описание: все соответствующие подробные сведения о каждом выполнении программы документируются. При нормальной работе каждая выполненная операция программы сравнивается с ранее задокументированными сведениями. При обнаружении различий выполняются действия по безопасности.
Документация о выполненных операциях может содержать последовательность индивидуальных шагов «от решения к решению» или последовательность отдельных обращений к массивам, записям или томам, либо к тому и другому.
Допускаются различные методы хранения сведений о последовательностях шагов выполнения программы. Могут быть использованы методы хэш-кодирования для отображения этих последовательностей в виде одного большого числа или последовательности чисел. При нормальной работе перед выполнением выходной операции значения чисел, отображающих последовательности шагов выполнения программы, должны быть сопоставлены со значениями, сохраненными в памяти.
Поскольку возможные комбинации таких последовательностей шагов при выполнении одной программы достаточно велики, может оказаться невозможным рассматривать программы как единое целое. В этом случае данный метод может быть применен на уровне программных модулей.
Литература:
Fail-safe Software - Some Principles and a Case Study. W. Ehrenberger. Proc. SARSS 1987, Altrincham, Manchester, UK, Elsevier Applied Science, 1987.
C.3.11 Постепенное отключение функций
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: обеспечение пригодности наиболее критичных системных функций, несмотря на отказы, путем игнорирования наименее критичных функций.
Описание: данный метод устанавливает приоритеты для различных функций, выполняемых системой. Проект создаваемой системы гарантирует, что в случае недостаточности ресурсов для выполнения всех системных функций функции высшего приоритета будут выполнены в предпочтение функциям более низкого приоритета. Например, функции регистрации ошибки и события могут оказаться задачей более низкого приоритета, чем системные функции управления, и в этом случае управление системой будет продолжаться, даже если аппаратные средства из-за регистрации ошибки окажутся неработоспособными. Более того, если аппаратные средства управления системой окажутся неработоспособными, а аппаратные средства регистрации ошибок останутся работоспособными, то аппаратные средства регистрации ошибок возьмут на себя функцию управления.
Данные соображения относятся в основном к аппаратным средствам, но они применимы также и к системе в целом. Данные соображения должны учитываться, начиная с самых ранних этапов проектирования.
Литература:
Space Shuttle Software. С. Т. Sheridan, Datamation, Vol. 24, July 1978.
The Evolution of Fault-Tolerant Computing. Vol. 1 of Dependable Computing and Fault-Tolerant Systems, Edited by A. Avizienis, H. Kopetz and J. С Laprie, Springer Verlag, 1987, ISBN 3-211-81941-X.
Fault Tolerance, Principle and Practices. T. Anderson and P. A. Lee, Vol. 3 of Dependable Computing and Fault-Tolerant Systems, Springer Verlag, 1987, ISBN 3-211-82077-9.
C.3.12 Исправление ошибок методами искусственного интеллекта
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: способностью гибко реагировать на возможные угрозы безопасности, используя сочетания методов и моделей процессов, а также некоторые способы безопасности в режиме «онлайн» и анализа надежности.
Описание: для различных каналов связи системы прогнозирование (вычисление тенденций), исправление ошибок, обслуживание и контролирующие действия могут достаточно эффективно поддерживаться системами, основанными на методах искусственного интеллекта (AI). Правила для таких систем могут быть образованы непосредственно из спецификаций и проверены на соответствие. С помощью методов искусственного интеллекта некоторые ошибки общего характера, попадающие в спецификации, для устранения которых уже существуют некоторые правила проектирования и реализации, могут быть исключены, особенно при представлении комбинаций моделей и методов функциональным или описательным способом.
Методы выбираются так, чтобы ошибки могли быть устранены и влияние отказов минимизировано для обеспечения требуемой полноты безопасности.
Примечание - Предупреждение об исправлении ошибочных данных см. С.3.2 и об отрицательных рекомендациях применения данного метода - МЭК 61508-3 (таблица А.2, пункт 5).
Литература:
Automatic Programming Techniques Applied to Software Development: An approach based on exeption handling. M. Bidoit et al, Proc. 1st Int. Conf. on Applications of Artificial Intelligence to Engineering Problems, Southampton, 165-177, 1986.
Artificial Intelligence and Design of Expert Systems. G. F. Luger and W. A. Stubblefield, Benjamin/Cummings, 1989.
C.3.13 Динамическая реконфигурация
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.2).
Цель: обеспечение функциональности системы, несмотря на внутренний отказ.
Описание: логическая архитектура системы должна быть такой, чтобы ее можно было отобразить в подмножестве доступных ресурсов системы. Логическая архитектура должна быть способна к обнаружению отказа в физическом ресурсе и дальнейшему повторному преобразованию логической архитектуры в ограниченные ресурсы, остающиеся функционирующими. Несмотря на то, что данный метод в основном традиционно ограничен только восстановлением отказавших модулей аппаратных средств, он применим также к ошибкам в программных средствах при наличии достаточной «избыточности времени прогона» для повторного выполнения программы или при наличии достаточных избыточных данных, которые обеспечат незначительное влияние отдельному и изолированному отказу.
Данный метод должен рассматриваться на первом этапе проектирования системы.
Литература:
Critical Issues in the Design of Reconfigurable Control Computer, H. Schmid, J. Lam, R. Naro and K. Weir, FTCS 14 June 1984, IEEE, 1984.
Assigning Processes to Processors: A Fault-tolerant Approach. G. Kar and С N. Nikolaou, Watson Research Centre, Yorktown, June 1984.
C.4 Инструменты разработки и языки программирования
С.4.1 Строго типизированные языки программирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.3).
Цель: снижение вероятности ошибок путем использования языка, который компилятором обеспечивает высокий уровень проверки.
Описание: если скомпилирован строго типизированный язык программирования, то проводится много проверок по использованию типов переменных, например в вызовах процедур и доступе к внешним данным. Компиляция может оказаться безуспешной, и будет выдано сообщение об ошибке при любом использовании типа переменных, которое не соответствует заранее установленным правилам.
Подобные языки обычно позволяют определять установленные пользователем типы данных на основе типов данных базового языка (например, целое число, реальное число). Затем эти типы могут быть использованы так же, как и базовый тип. Вводятся строгие проверки, чтобы гарантировать использование правильного типа. Эти проверки проводятся для всей программы, даже если она построена из отдельных скомпилированных модулей. Данные проверки гарантируют также, что число и тип аргументов конкретной процедуры соответствуют числу и типу аргументов в ее вызове, даже если к ней обращаются из отдельно скомпилированных программных модулей.
Строго типизированные языки обычно обеспечивают другие аспекты проверенной на практике технике программного обеспечения, например, легко анализируемые структуры управления (if... then... else..., do... while и т.п.), которые приводят к четко структурированным программам.
Типичными примерами строго типизированных языков являются Pascal [21], Ada [23] и Modula 2 [27].
Литература:
In Search of Effective Diversity: a Six Language Study of Fault-Tolerant Flight Control Software. A. Avizienis, M. R. Lyu and W. Schutz. 18th Symposium on Fault-Tolerant Computing, Tokyo, Japan, 27-30 June 1988, IEEE Computer Society Press, 1988, ISBN 0-8186-0867-6.
C.4.2 Подмножество языка
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.3).
Цель: снижение вероятности внесения программных ошибок и повышение вероятности обнаружения оставшихся ошибок.
Описание: язык исследуется для определения программных конструкций, подверженных ошибкам либо сложных для анализа, например, при использовании методов статического анализа. После этого определяется языковое подмножество, которое исключает такие конструкции.
Литература:
Requirements for programming languages in safety and security software standard. B. A. Wichmann. Computer Standards and Interfaces. Vol. 14, pp 433-441, 1992.
Safer C: Developing Software for High-integrity and Safety-critical Systems. L. Hatton, McGraw-Hill, 1994, ISBN 0-07-707640-0.
C.4.3 Сертифицированные средства
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.3).
Цель: помощь разработчику на различных этапах разработки программных средств в использовании необходимых инструментальных средств, которые, где это возможно, должны быть сертифицированы с тем, чтобы обеспечить конкретную степень уверенности в корректности результатов.
Описание: сертификацию инструментальных средств в общем случае допускается проводить независимо, как правило, в национальных органах по сертификации, по независимому набору критериев, находящемуся обычно в национальных или международных стандартах. В идеальном случае инструментальные средства, применяемые на всех стадиях разработки (спецификация, проектирование, кодирование, тестирование и оценка соответствия), и те из них, которые используются в управлении конфигурацией, должны быть сертифицированы.
В настоящее время регулярным процедурам сертификации подвергаются только компиляторы (трансляторы); сертификация проводится национальными органами по сертификации и заключается в проверке компиляторов (трансляторов) на соответствие международным стандартам, например, для языков Ada или Pascal.
Важно отметить, что сертифицированные инструментальные средства и сертифицированные трансляторы обычно сертифицируются только на соответствие стандартам на соответствующий язык или процесс. Обычно они никак не сертифицируются на соответствие стандартам по безопасности.
Литература:
Pascal Validation Suite. UK Distributor: BSI Quality Assurance, PO Box 375, Milton Keynes, MK 14 6LL.
Ada Validation Suite. UK Distributor: National Computing Centre (NCC), Oxford Road, Manchester, England.
