B.2.5 Таблица контрольных проверок
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1, В.2 и В.6) и в МЭК 61508-3 (таблицы А.10 и В.8).
Цель: рассмотрение и управление критическими оценками всех важных аспектов системы на этапе жизненного цикла безопасности, обеспечивая исчерпывающий охват без установления точных требований.
Описание: специалист, заполняющий таблицу контрольных проверок, должен дать ответ на ряд вопросов. Многие вопросы носят общий характер, и он должен интерпретировать их как наиболее подходящие к конкретной оцениваемой системе. Таблицы контрольных проверок допускается использовать на всех этапах полного жизненного цикла безопасности, жизненного цикла безопасности E/E/PES и жизненного цикла безопасности программного обеспечения. Такие таблицы, в частности, полезны в качестве инструмента для оценки функциональной безопасности [4].
Для сокращения широкого разнообразия проходящих подтверждение соответствия систем большинство таблиц контрольных проверок содержат вопросы, которые применимы ко многим типам систем. Поэтому в используемой таблице контрольных проверок может оказаться множество вопросов, которые не уместны для конкретной системы и должны игнорироваться. Кроме того, может также возникнуть необходимость дополнить стандартную таблицу контрольных проверок вопросами, специально ориентированными на конкретную систему.
Использование таблицы контрольных проверок в большой степени зависит от экспертной оценки и суждения специалиста, который выбирает и применяет таблицу контрольных проверок. Принятые им решения относительно выбранных (ой) таблиц (ы) контрольных проверок и любые дополнительные или игнорируемые вопросы должны быть полностью задокументированы и обоснованы. Необходимо стремиться к тому, что если применение таблиц контрольных проверок пересматривается, то гарантируется получение одних и тех же результатов, если только не используются различные критерии.
Описание системы в заполненной таблице контрольных проверок должно быть как можно более кратким. При необходимости исчерпывающего обоснования оно должно быть дано в виде ссылок на дополнительные документы. Для документирования результатов каждого вопроса должен использоваться ответ «успешно», «безуспешно» или «не завершено», либо аналогичный набор ответов. Эта лаконичность значительно упрощает процедуру оформления общего заключения результатов оценки в виде таблицы контрольных проверок [16].
Литература:
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
Programmable Electronic Systems (PES) in Safety Related Application. Health and Safety Executive, UK, 1987.
Dependability of Critical Computer Systems 2, F. J. Redmill, Elsevier Applied Science, 1989, ISBN 1-85166-381-9.
The Art of Software Testing. G. Myers, Wiley & Sons, New York, 1979.
B.2.6 Экспертиза спецификации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 и В.6).
Цель: исключить некомплектность и противоречивость спецификации.
Описание: общий метод анализа спецификации для ее оценки с различных сторон независимой командой экспертов. Такая команда задает вопросы разработчику, который должен дать ей удовлетворительные ответы. Анализ должен (по возможности) проводиться командой экспертов, которая не принимала участия в создании спецификации. Требуемая степень независимости оценки определяется уровнями полноты безопасности, задаваемыми для системы. Команда независимых экспертов должна быть способна реконструировать эксплуатационную функцию системы бесспорным способом без ссылок на любые последующие спецификации. Специалисты команды независимых экспертов должны также убедиться в том, что охвачены все уместные аспекты безопасности и технические аспекты в эксплуатационных и организационных средствах. Общий метод экспертизы спецификации доказал свою высокую эффективность на практике [12].
Литература:
The Art of Software Testing. G. Myers, Wiley & Sons, New York, 1979.
В.3 Проектирование и разработка E/E/PES
Главная цель: создание устойчивого проекта системы, связанной с безопасностью, в соответствии со спецификацией.
В.3.1 Соблюдение руководящих материалов и стандартов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.2).
Цель: рассмотрение стандартов прикладного сектора (не рассматриваемых в настоящем стандарте).
Описание: во время проектирования системы, связанной с безопасностью, должны составляться руководящие материалы, которые должны, во-первых, приводить к созданию систем, связанных с безопасностью, и быть практически свободны от ошибок и, во-вторых, упрощать последующее подтверждение соответствия безопасности. Такие руководящие материалы могут быть универсальными, специальными для проекта или специальными только для отдельного этапа проекта.
Литература:
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.
Deutsche Bundesbahn: Richtlinien-Entwürfe 42500 to 42550 für das Handbuch «Grundsatze zur technischen Zulassung in der Signal- und Nachrichtentechnik». Bundesbahn-Zentralamt München, August 1987.
Richtlinie zur Erstellung und Prüfung sicherheitsrelevanter Software. K. Grimm, G. Heiner, Informatik Fachberichte 86, Springer Verlag, Berlin, 277-288, 1984.
B.3.2 Структурное проектирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.2 и В.6).
Цель: снижение сложности проектирования путем создания иерархической структуры частичных требований. Исключение ошибок взаимосвязей между требованиями. Упрощение верификации.
Описание: при проектировании аппаратных средств должны использоваться конкретные критерии или методы. Например, может потребоваться:
- проектирование иерархически структурированных схем;
- использование изготовленных и проверенных частей схем.
При проектировании программных средств использование структурных схем также позволяет создать однозначную структуру программных модулей. Данная структура показывает взаимосвязь модулей друг с другом, конкретные данные, которые передаются между модулями, и конкретное управление, существующее между модулями [16].
Литература:
Structured Development for Real-Time Systems (3 Volumes). P. T. Yourdon, P. T. Yourdon Press, 1985.
Software Design for Real-time Systems. J. E. Cooling, Chapman and Hall, 1991.
Essential Systems Analysis. St. M. McMenamin, F. Palmer, Yourdon Inc, 1984.
The Use of Structured Methods in the Development of Large Software-Based Avionic Systems. D. J. Hatley, Proceedings DASC, Baltimore, 1984.
An Overview of JSD, J. R. Cameron, IEEE Trans SE-12 No. 2, February 1986.
System Development. M. Jackson, Prentice-Hall, 1983.
MASCOT 3 User Guide. MASCOT Users Forum, RSRE, Malvern, England, 1987.
Structured Development for Real-Time Systems (3 Volumes). P. T. Ward, S. J. Mellor, Yourdon Press, 1985.
Structured Analysis for Requirements Definition, D. T. Ross, K. E. Schoman Jr, IEEE Trans. Software Eng, Vol. SE-3, 6-15, 1977.
Structured Analysis (SA): A language for communicating ideas. D. T. Ross, IEEE Trans. Software Eng, Vol. SE-3 (1), 16-34.
Applications and Extensions of SADT. D. T. Ross, Computer, 25-34, April 1985.
Structured Analysis and Design Technique - Application on Safety Systems. W. Heins, Risk Assessment and Control Courseware, Module B1, chapter 11, Delft University of Technology, Safety Science Group, PO Box 5050, 2600 GB Delft, Netherlands, 1989.
B.3.3 Использование достоверно испытанных компонентов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.2 и В.6).
Цель: снижение риска многих оригинальных и необнаруживаемых отказов путем использования компонентов с конкретными характеристиками.
Описание: выбор достоверно испытанных компонентов для целей безопасности выполняется производителем в соответствии с надежностью компонентов (например, использование эксплуатационно-тестируемых физических модулей для удовлетворения высоких требований безопасности или хранение относящихся к безопасности программ только в безопасной памяти). Обеспечение безопасности памяти может касаться устранения несанкционированного доступа, влияний несанкционированной среды (электромагнитная совместимость, радиация, и т.д.), а также отклика компонентов в случае обнаружения отказов [13].
Литература:
Reliability Testing for Industrial use. W. T. Greenwood, Computer 10 (7), 26-30, 1977.
Independent Test Labs: Caveat Emptor. E. Rubinstein, IEEE Spectrum, 14 (6), 44-50, 1977.
Microcomputers in safety technique - an aid to orientation for developer and manufacturer. H. Hölscher, J. Rader, Verlag TÜV Rheinland, Köln, 1986, ISBN 3-88585-315-9.
Zuverlässigkeit elektronischer Komponenten. T. Bajenescu, VDE-Verlag, Berlin, 1985.
В.3.4 Модульное проектирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.2 и В.6).
Цель: снижение сложности и исключение ошибок, связанных с интерфейсами между подсистемами.
Описание: каждая подсистема на всех уровнях проектирования четко определена и ограничена по размеру (только небольшим набором функций). Интерфейсы между подсистемами поддерживаются как можно более простыми, и пересечения (разделяемые данные, обмен информацией) минимизированы. Сложность отдельных подсистем также ограничивается.
Литература:
EWICS European Workshop on Industrial Computer Systems, TC 7: Safety Related Computers - Software Development and Systems, Documentation. TÜV Rheinland, Köln, 1985.
The Art of Software Testing. G. J. Myers, Wiley & Sons, New York, 1979.
Software Reliability - Principles и Practices. G. J. Myers, Wiley-lnterscience, New York, 1976.
Software Design for Real-time Systems. J. E. Cooling, Chapman и Hall, 1991.
B.3.5 Средства автоматизированного проектирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.2 и В.6) и в МЭК 61508-3 (таблица А.4).
Цель: более систематическое выполнение процедуры проектирования. Включение в проект подходящих автоматически сконструированных элементов, уже созданных и проверенных.
Описание: инструменты автоматизированного проектирования (CAD) должны использоваться в процессе проектирования, как аппаратных, так и программных средств, если они доступны и их использование обосновано сложностью системы. Корректность использования таких инструментов должна быть продемонстрирована конкретным тестированием, обширной предысторией удовлетворительного использования, либо независимой верификацией их результата для конкретной проектируемой системы, связанной с безопасностью.
Литература:
Verification - The Practical Problems. J. Т. Webb и D. J. Mannering, SARSS 87, November 1987, Altrincham, England, Elsevier Applied Science, 1987, ISBN 1-85166-167-0.
An Experience in Design and Validation of Software for a Reactor Protection System. S. Bologna, E. de Agostino et al, IFAC Workshop, SAFECOMP 1979, Stuttgart, 16-18 May 1979, Pergamon Press, 1979.
B.3.6 Моделирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.2, В.5 и В.6).
Цель: проведение систематических и полных проверок, как функционирования электрических/электронных схем, так и для корректного задания значений параметров их компонентов.
Описание: функция схемы, реализующая систему, связанную с безопасностью, имитируют на компьютере с помощью запрограммированной модели ее поведения. Поведение каждого отдельного компонента схемы моделируют отдельно, и отклик схемы, в которую он входит, анализируют при задании предельных значений параметров для каждого компонента.
Литература:
Proc. Working Conference on Prototyping. Namur, October 1983, Budde et al, Springer Verlag, 1984.
Using an executable specification for an information system. S. Urban et al, IEEE Trans Software Engineering, Vol. SE-11 No. 7, July 1985.
Verification and validation of Real-time Software. W. J. Quirk (ed.), Springer Verlag, Berlin, 1985.
VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.
B.3.7 Проверка (обзор и анализ)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.2 и В.6).
Цель: выявление рассогласования между спецификацией и реализацией.
Описание: проверяются заданные функции системы, связанной с безопасностью. Оценивается соответствие системы, связанной с безопасностью, требованиям, приведенным в спецификации. Все вызывающие сомнение ситуации при реализации и использовании изделий документируют с целью их последующего разрешения. В отличие от сквозного контроля во время процедуры проверки разработчик системы пассивен, а эксперт - активен.
Литература:
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.
VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993. ANSI/IEE Std. 1028:1997, IEEE Standard reviews и audits.
B.3.8 Сквозной контроль
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.6).
Цель: выявление рассогласования между спецификацией и реализацией.
Описание: проверяются заданные функции системы, связанной с безопасностью. Оценивается соответствие системы, связанной с безопасностью, требованиям, приведенным в спецификации. Все вызывающие сомнение ситуации при реализации и использовании изделий документируются с целью их последующего разрешения. В отличие от процедуры проверки во время сквозного контроля автор должен быть активен, а эксперт - пассивен.
Литература:
Dependability of Critical Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN 1-85166-544-7.
Methodisches Testen von Programmen. G. J. Myers, Oldenbourg Verlag, München, Wien, 1987.
VDI-Gemeinschaftsausschuβ Industrielle Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.
ANSI/IEE Std. 1028:1997, IEEE Standard for software reviews and audits.
B.4 Процедуры эксплуатации и обслуживания E/E/PES
Главная цель: разработка процедур, которые исключают ошибки во время эксплуатации и обслуживания систем, связанных с безопасностью.
В.4.1 Инструкции по эксплуатации и обслуживанию
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.4).
Цель: исключение ошибок во время эксплуатации и обслуживания систем, связанных с безопасностью.
Описание: инструкции пользователя содержат важную информацию о способах использования и обслуживания систем. В особых случаях эти инструкции могут содержать также примеры общих способов установки систем, относящихся к безопасности. Все инструкции должны легко восприниматься. Для описания сложных процедур и зависимостей должны использоваться рисунки и схемы.
Литература:
Guidelines for Safe Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.4.2 Удобство общения с пользователем
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.4).
Цель: снижение сложности во время эксплуатации систем, связанных с безопасностью.
Описание: правильность эксплуатации систем, связанных с безопасностью, в определенной степени зависит от оператора. Рассматривая конкретные проекты системы и рабочего места, разработчик систем, связанных с безопасностью, должен предусмотреть:
