ФЕДЕРАЛЬНОЕ АГЕНТСТВО
ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
|
|
НАЦИОНАЛЬНЫЙ
СТАНДАРТ
российской
ФЕДЕРАЦИИ
|
ГОСТ Р МЭК
61508-7-
2007
|
ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ СИСТЕМ
ЭЛЕКТРИЧЕСКИХ,
ЭЛЕКТРОННЫХ, ПРОГРАММИРУЕМЫХ ЭЛЕКТРОННЫХ,
СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ
Часть 7
Методы и средства
IEC 61508-7:2000
Functional safety of
electrical/electronic/programmable electronic safety-related systems - Part 7:
Overview of techniques and measures
(IDT)
|
Москва
Стандартинформ
2008
|
Предисловие
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные
положения»
Сведения о стандарте
1
ПОДГОТОВЛЕН обществом с ограниченной ответственностью «Корпоративные электронные системы» и Техническим комитетом по стандартизации ТК 10 «Перспективные производственные технологии, менеджмент и оценка рисков» на основе собственного аутентичного перевода стандарта, указанного в
пункте 4
2
ВНЕСЕН Управлением развития, информационного обеспечения и аккредитации Федерального
агентства по техническому регулированию и метрологии
3
УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 декабря 2007 г. № 581-ст
4 Настоящий стандарт идентичен международному стандарту МЭК 61508-7:2000 «Функциональная
безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Анализ методов и средств» (IEC 61508-7:2000 «Functional safety of
electrical/electronic/ programmable electronic safety-related systems - Part 7:
Overview of techniques and measures»).
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении С
5 ВВЕДЕН ВПЕРВЫЕ
Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок
- в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования
- на официальном сайте Федерального агентства по техническому регулированию и метрологии
в сети Интернет
Введение
Системы, состоящие из электрических и/или электронных компонентов, в течение многих лет используются для выполнения функций безопасности в большинстве областей применения. Компьютерные системы [обычно называемые программируемыми электронными системами (PES)], используемые во всех областях применения для выполнения задач, не связанных с безопасностью, во все возрастающих масштабах используются для решения задач обеспечения безопасности. Для эффективной и безопасной эксплуатации технологий, основанных на использовании компьютерных систем, важно, чтобы лица, ответственные за принятие решений, имели в своем распоряжении практические руководства по вопросам безопасности.
Настоящий стандарт устанавливает общий подход к вопросам обеспечения безопасности всего жизненного цикла систем, состоящих из электрических и/или электронных и/или программируемых электронных компонентов [электрических/ электронных/ программируемых электронных систем (E/E/PES)], используемых для выполнения функций безопасности. Этот унифицированный подход был принят для разработки рациональной и последовательной технической концепции для всех электрических систем, связанных с безопасностью. Основной целью настоящего стандарта является содействие разработке стандартов для их применения в различных предметных областях.
Обычно безопасность систем достигается использованием в них нескольких систем защиты, в которых используются различные (например, механические, гидравлические, пневматические, электрические, электронные, программируемые электронные) технологии. Следовательно, любая стратегия безопасности должна учитывать не только элементы, входящие в состав отдельных систем (например, датчики, управляющие устройства и исполнительные механизмы), но также и подсистемы, связанные с безопасностью, входящие в состав комбинированной системы, связанной с безопасностью. Таким образом, хотя настоящий стандарт в основном распространяется на электрические /электронные / программируемые электронные (Е/Е/РЕ) системы, связанные с безопасностью, он может также дать представление об общей структуре, в рамках которой рассматриваются системы, связанные с безопасностью, основанные на других технологиях.
Признанным фактом является существование огромного разнообразия применений E/E/PES в различных предметных областях, отличающихся разной степенью сложности, опасностями и возможными рисками. В каждом конкретном применении использование необходимых мер безопасности будет зависеть от многочисленных факторов, специфичных для этого конкретного применения. Настоящий стандарт, являясь базовым, позволяет формулировать такие меры для вновь разрабатываемых международных
стандартов для различных предметных областей.
Настоящий стандарт:
- рассматривает все соответствующие этапы жизненного цикла систем безопасности в целом, а также подсистем E/E/PES и программного обеспечения (начиная с исходной концепции, включая проектирование, разработку, эксплуатацию, техническое обслуживание и вывод из эксплуатации), в ходе которых E/E/PES используются для выполнения функций безопасности;
- разработан с учетом быстрого развития технологий; его структура является достаточно устойчивой и полной для удовлетворения потребностей разработок, которые могут появиться в будущем;
- делает возможной разработку стандартов областей применения, в которых используются системы E/E/PES; разработка стандартов для областей применения в рамках общей структуры, вводимой настоящим стандартом, должна приводить к более высокому уровню согласованности (например основные принципы, терминология и т.п.) как для отдельных областей применения, так и для их совокупности; это дает преимущества как для безопасности, так и в сфере экономики;
- предоставляет метод разработки спецификаций для требований безопасности, необходимых для достижения требуемой функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью;
- использует уровни полноты безопасности для задания планируемого уровня полноты безопасности функций, которые должны быть реализованы Е/Е/РЕ системами, связанными с безопасностью;
- использует для определения уровней полноты безопасности подход, основанный на оценке рисков;
- устанавливает количественные значения отказов Е/Е/РЕ систем, связанных с безопасностью, которые связаны с уровнями полноты безопасности;
- устанавливает нижний предел планируемых значений отказов в режиме опасных отказов, который может быть задан для отдельной Е/Е/РЕ системы, связанной с безопасностью; для Е/Е/РЕ систем, связанных с безопасностью работающих:
- в режиме с низкой интенсивностью запросов нижний предел для выполнения планируемой функции по запросу устанавливают на средней вероятности отказов10-5;
- в режиме с высокой интенсивностью запросов нижний предел устанавливают на вероятности опасных отказов 10-9 в час.
Примечание - Конкретная Е/Е/РЕ система, связанная с безопасностью, не обязательно предполагает
одноканальную архитектуру;
- применяет широкий набор принципов, методов и мер для достижения функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью, но не использует концепцию безаварийности, которая может иметь важное значение в случае, если виды отказов хорошо определены, а уровень сложности является относительно невысоким. Концепция безаварийности признана неподходящей из-за широкого диапазона сложности Е/Е/РЕ систем, связанных с безопасностью и подпадающих под область применения настоящего стандарта.
Содержание
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ СИСТЕМ ЭЛЕКТРИЧЕСКИХ, ЭЛЕКТРОННЫХ, ПРОГРАММИРУЕМЫХ ЭЛЕКТРОННЫХ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ
Часть 7
Методы и средства
Functional safety of electrical, electronic,
programmable electronic safety-related systems.
Part 7. Techniques and measures
|
Дата введения - 2008-09-01
1.1 Настоящий стандарт содержит общее описание различных методов и средств, обеспечивающих
выполнение требований МЭК 61508-2 и МЭК 61508-3.
Примечание - Ссылки должны рассматриваться как базовые ссылки на методы и инструменты либо как примеры, и они могут не отражать современное состояние области.
1.2 Стандарты МЭК 61508-1 -
МЭК 61508-4 представляют собой основополагающие стандарты по
безопасности, хотя этот статус не применяется в контексте Е/Е/РЕ систем, связанных безопасностью, имеющих небольшую сложность (см. МЭК 61508-4, пункт 3.4.4). Как основополагающие стандарты по
безопасности они предназначены для использования техническими комитетами при подготовке стандартов в соответствии с МЭК Руководство 104 и ИСО/МЭК 51. Международный стандарт МЭК 61508 предназначен, кроме того, для использования в качестве самостоятельного стандарта.
В круг обязанностей технического комитета входит использование, где это возможно, основополагающих стандартов по безопасности при подготовке собственных стандартов. В этом случае требования, методы проверки или условия проверки настоящего основополагающего стандарта по безопасности не
будут применяться, если это не указано специально, или они будут включаться в стандарты, подготовленные этими техническими комитетами.
Примечания
1
Функциональная безопасность систем Е/Е/РЕ, связанных с безопасностью, может достигаться только в
том случае, когда все соответствующие требования удовлетворены. Поэтому важно, чтобы все эти требования
были тщательно проанализированы и на них были даны адекватные ссылки.
2 В США и Канаде до тех пор, пока стандарты для конкретного сектора применения стандартов МЭК 61508 (например МЭК 61511 [18])
не будут опубликованы в качестве международных стандартов США и Канады, существующие там национальные стандарты по безопасности в обрабатывающих секторах, основанные на МЭК 61508, могут быть применены вместо МЭК 61508.
1.3 Общая структура МЭК 61508-1 - МЭК 61508-7 с указанием роли МЭК 61508-7 в достижении функциональной безопасности Е/Е/РЕ систем, связанных с безопасностью, показана на рисунке 1.
Рисунок 1 - Структура настоящего стандарта
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ИСО/МЭК Руководство 51:1999 Руководство по включению в стандарты аспектов, связанных с безопасностью
МЭК Руководство 104:1997 Руководство по подготовке стандартов, связанных с безопасностью, и по
роли комитетов с функциями определения направлений и разработки стандартов в области безопасности
МЭК 61508-1:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования
МЭК 61508-2:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам
МЭК 61508-3:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению
МЭК 61508-4:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения
МЭК 61508-5:1998 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 5. Рекомендации по применению методов определения уровней полноты безопасности
МЭК 61508-6:2000 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 6. Руководство по применению МЭК 61508-2:2000 и
МЭК 61508-3:1998
IEEE 352:1987 Руководство IEEE по основным принципам анализа надежности систем безопасности
атомных энергетических станций
В настоящем стандарте применяют термины и определения по МЭК 61508-4.
А.1 Электрические
Главная цель: Управление отказами в электромеханических компонентах.
А.1.1 Отказы, обнаруживаемые мониторингом в режиме «онлайн»
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.2, А.3, А.7 и А.14 - А.19).
Цель: обнаружение отказов путем контроля поведения Е/Е/РЕ систем, связанных с безопасностью, в процессе нормального (в режиме онлайн) функционирования управляемого оборудования (далее - EUC).
Описание: при определенных условиях отказы могут быть обнаружены с помощью информации, например
о поведении во времени EUC. Например, если коммутатор, который является частью Е/Е/РЕ систем, связанных с
безопасностью, нормально активизируется со стороны EUC и если при этом коммутатор не изменяет состояния
в предполагаемое время, то отказ может быть обнаружен. Обычными способами невозможно локализовать
такой отказ.
А.1.2 Мониторинг релейных контактов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.2 и А.15).
Цель: обнаружение отказов (например, пайки) релейных контактов.
Описание: активизируемые контактные реле (или положительно управляемые контакты в реле) спроектированы так, что их контакты жестко связаны между собой. Рассмотрим два переключаемых контакта a и b. Если
нормально разомкнутый контакт a оказался спаянным (залипшим), то нормально замкнутый контакт b не может
замкнуться, если обмотка реле обесточивается. Следовательно, контроль замыкания нормально замкнутого контакта b при обесточенной обмотке реле может быть использован для подтверждения того, что нормально разомкнутый контакт a разомкнут. Отсутствие замыкания нормально замкнутого контакта b указывает на отказ контакта a, поэтому схема контроля должна обеспечить надежное отключение или обеспечить продолжение отключения при
любом управлении оборудования контактом a.
Литература:
Zusammenstellung und
Bewertung elektromechanischer Sicherheitsschaltungen für Ver-riegelungseinrichtungen. F. Kreutzkampf,
W. Hertel, Sicherheitstechnisches Informations- und Arbeitsblatt 330212,
BIA-Handbuch. 17. Lfg. X/91, Erich Schmidt Verlag, Bielefeld.
Anlagensicherung mit
Mitteln der MSR-Technik. G. Strohrman, Oldenburg, 1983.
A.1.3 Компаратор
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.2, А.3, А.4).
Цель: оперативное обнаружение (не одновременное) отказов в независимом модуле обработки или в компараторе.
Описание: сигналы независимых модулей обработки сравнивают циклически или непрерывно компаратором аппаратных средств. Сам компаратор может быть внешне тестируемым или же может использовать самоконтролируемую технологию. Обнаруживаемые компаратором различия в поведении процессоров независимых
модулей формируют информацию для сообщений об отказах.
А.1.4 Схема голосования по мажоритарному принципу
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.2, А.3 и А.4).
Цель: обнаружение и парирование отказов, по меньшей мере, в одном из трех аппаратных каналов.
Описание: модуль голосования, использующий мажоритарный принцип (2 из 3, 3 из 4 или m из n), используется для обнаружения и парирования отказов. Сама схема голосования может внешне тестироваться или же она
может использовать самоконтролирующие технологии.
Литература:
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
Anlagensicherung mit
Mitteln der MSR-Technik. Praxis der Sicherheitstechnik, Vol 1, Dechema, 1988.
Sicherung von Anlagen der
Verfahrenstechnik mit Mitteln der Mess-, Steuerungs- und Regelungstechnik. VDI/
VDE Blatt 1 to 5, 1984 to 1988.
А.1.5 Отсутствие питания (отключение энергии)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.2, А.9, А.14 и А.15).
Цель: выполнение функции безопасности при выключении или отсутствии питания.
Описание: функция безопасности выполняется, если контакты реле разомкнуты и ток не проходит. Например, при использовании тормозов для остановки опасного вращения двигателя тормоза отпускаются замыкающими контактами в системах, связанных с безопасностью, и включаются размыкающими контактами в системах, связанных с безопасностью.
Литература:
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
А.2 Электроника
Главная цель: управление отказами в транзисторных компонентах.
А.2.1 Тестирование избыточным оборудованием
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.3, А.16, А.17 и А.19).
Цель: обнаружение отказов с использованием избыточных аппаратных средств, то есть с использованием
дополнительных аппаратных средств, не требующихся для реализации функций обработки.
Описание: избыточные аппаратные средства могут быть использованы для тестирования на соответствующей частоте заданных функций безопасности. Такой подход обычно требуется для реализации положений пунктов А.1.1 или
А.2.2.
Литература:
DIN V VDE 0801: Grundsätze für Rechner in Systemen mit
Sicherheitsaufgaben (Principles for Computers in Safety-Related Systems),
Beuth-Verlag, Berlin, 1990.
A.2.2 Принципы динамического управления
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу
А.3).
Цель: обнаружение статических отказов путем динамической обработки сигналов.
Описание: принудительное изменение других статических сигналов (генерируемых извне или внутри) помогает обнаруживать статические отказы в компонентах. Этот метод часто ассоциируется с электромеханическими
компонентами.
Литература:
Elektronik in der
Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches
Informations- und Arbeitsblatt 330220, BIA-Handbuch, Erich-Schmidt Verlag,
Bielefeld, 1993.
A.2.3 Стандартный тестовый порт доступа и архитектура граничного сканирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.3, А.16 и А.19).
Цель: управление и наблюдение за происходящим на каждом контакте интегральной схемы (1С).
Описание: тестирование граничного сканирования представляет собой метод построения IС, который повышает тестируемость IС, разрешая проблему доступа к внутренним точкам тестируемой схемы. В типичной сканируемой по границам интегральной схеме, содержащей внутренние логические схемы, а также входные и выходные буферы, между внутренними логическими схемами и входными/выходными буферами, соединенными с
внешними контактами IС, размещается ступень сдвигового регистра. Содержимое каждого сдвигового регистра
находится в ячейке граничного сканирования. Ячейка граничного сканирования может управлять и наблюдать за
происходящим на каждом входном и выходном контакте IС через стандартный тестовый порт доступа. Тестирование внутренних логических схем IС проводится путем отключения размещенных на чипе внутренних логических
схем от входных сигналов, получаемых от окружающих компонентов, и последующего выполнения внутреннего
тестирования. Эти тесты могут быть использованы для обнаружения отказов в IС.
Литература:
IEEE 1149.1:1990, Standard
Test Access Port and Boundary-Scan Architecture. IEEE 1149.1:1990.
A.2.4 Отказоустойчивое оборудование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.3).
Цель: перевести систему в безопасное состояние в случае появления отказов.
Описание: в аппаратно реализованных системах считается, что устройство работает отказоустойчиво, если:
-
конкретный набор отказов может приводить к безопасному состоянию и
-
отказы обнаруживаются.
Пример - К конкретному набору отказов могут относиться постоянные отказы, постоянные отказы типа «разомкнутый», короткие замыкания внутри и между компонентами и направленные короткие замыкания.
Литература:
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN 1-85166-203-0.
Elektronik in der
Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches
Informations-und Arbeitsblatt 330220, BIA-Handbuch, Erich-Schmidt Verlag,
Bielefeld, 1993.
A.2.5 Избыточный контроль
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.3).
Цель: обнаружение отказов путем создания нескольких функциональных модулей, контроля поведения
каждого из них для обнаружения отказов и последующего инициирования перехода в безопасное состояние при
обнаружении какого-либо несоответствия в поведении.
Описание: функция безопасности выполняется, по меньшей мере, двумя аппаратными каналами. Выходы
этих каналов контролируются и безопасное состояние инициируется при обнаружении отказа (в случае, если
выходные сигналы из всех каналов не идентичны).
Литература:
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN
1-85166-203-0.
Elektronik in der
Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches
Informations-und Arbeitsblatt 330220, BIA-Handbuch, Erich-Schmidt Verlag,
Bielefeld, 1993.
A.2.6 Электрические/электронные компоненты с автоматической проверкой
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.3).
Цель: обнаружение отказов путем периодической проверки способности выполнения функции безопасности.
Описание: аппаратные средства тестируются до запуска процесса и затем тестируются повторно через
соответствующие интервалы. EUC продолжает работу только при условии успешного прохождения каждого теста.
Литература:
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN
1-85166-203-0.
Elektronik in der
Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches Informations-und
Arbeitsblatt 330220, BIA-Handbuch, Erich-Schmidt Verlag, Bielefeld, 1993.
A.2.7 Текущий контроль аналоговых сигналов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.3 и А.14).
Цель: повышение достоверности результатов измерений аналоговых сигналов.
Описание: везде, где возможно, используются аналоговые приборы, а не цифровые. В аналоговых приборах отключение или безопасные состояния представляются уровнями аналоговых сигналов обычно с контролем
устойчивости уровня этого сигнала. Это обеспечивает непрерывный контроль и высокую степень достоверности
передачи сигнала, снижает частоту необходимого гарантийного тестирования функции чувствительности передатчика. Внешние интерфейсы, например импульсные линии, также нуждаются в тестировании.
Литература:
UKOOA Guidelines for
Instrument-Based Systems, UK Offshore Operators Association Limited, December
1995.
A.2.8 Снижение номинального значения
Цель: повышение надежности компонентов аппаратных средств.
Описание: компоненты аппаратных средств нормально выполняют свои функции на уровнях напряжений, которые заложены при проектировании системы и являются более низкими, чем максимально специфицированные номинальные значения. Снижение номинального значения - это практика, обеспечивающая, что при всех
нормальных условиях эксплуатации компоненты будут нормально функционировать при уровнях напряжений
ниже их максимальных значений.
А.3 Модули обработки
Главная цель: распознавать отказы, которые приводят к неправильным результатам в модулях обработки.
А.3.1 Программное самотестирование: предельное количество комбинаций (одноканальное)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.4).
Цель: оперативное обнаружение отказов в модулях обработки.
Описание: аппаратные средства создаются с использованием стандартных методов, не учитывающих специальных требований к безопасности. Обнаружение отказов реализуется целиком дополнительными программными функциями, которые выполняют самотестирование с использованием, по меньшей мере, двух дополнительных комбинаций данных (например, 55hex и ААhex).
Литература:
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.
A.3.2 Программное самотестирование: блуждающий бит (одноканальное)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.4).
Цель: оперативное обнаружение отказов в физической памяти (например, в регистрах) и дешифраторе
команд процессора.
Описание: обнаружение отказов полностью реализуется дополнительными программными функциями, которые выполняют самотестирование с использованием комбинации данных (например, комбинации блуждающих битов), которая тестирует физическую память (регистры данных и адресные регистры) и дешифратор команд. Однако диагностический охват составляет только 90 %.
Литература:
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.
A.3.3 Самотестирование, обеспечиваемое оборудованием (одноканальное)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.4).
Цель: оперативное обнаружение отказов в процессоре с использованием специальных аппаратных средств, которые увеличивают скорость и расширяют область обнаружения отказов.
Описание: дополнительные специальные аппаратные средства обеспечивают функции самотестирования
для обнаружения отказов. Например, таким средством может быть аппаратный модуль, который циклически
контролирует выход на наличие конкретной битовой комбинации, используя механизм сторожевой схемы.
Литература:
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.
A.3.4 Закодированная обработка (одноканальная)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.4).
Цель: оперативное обнаружение отказов в процессоре.
Описание: процессоры могут быть спроектированы с встроенными специальными функциями распознавания или исправления отказов. До сих пор эти функции применялись только в относительно простых схемах и не
получили широкого распространения. Однако такие функции не должны исключаться в будущих разработках.
Литература:
The Coded Microprocessor
Certification. P. Ozello, Proc. SAFECOMP '92, 185-190, 1992.
Vital Coded Microprocessor
Principles и Application for Various Transit Systems. P.
Forin, IFAC Control Computers Communications in Transportation, 79-84, 1989.
Le Processeur Codé: un
nouveau concept appliqué a la sécurité des systémes de transports. Gabriel, Martin, Wartski,
Revue Générate des chemins de fer, No. 6, June 1990.
A.3.5 Программное обнаружение несовпадений
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу
А.4).
Цель: оперативное обнаружение отказов в процессоре путем динамического программного сравнения.
Описание: два модуля взаимно обмениваются данными (включая результаты, промежуточные результаты
и тестируемые данные). Если при сравнении данных, выдаваемых с использованием программных средств в
каждом модуле, обнаруживаются различия, то это приводит к выдаче сообщений об отказе.
Литература:
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.
А.4 Постоянная память
Главная цель: выявление модификаций информации в постоянной памяти.
А.4.1 Сохранение слов с многобитовой избыточностью (например, контроль ROM с модифицированным кодом Хэмминга)
Примечание - См. также А.5.6 и С.3.2. Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.5).
Цель: обнаружение всех однобитовых ошибок, всех двухбитовых ошибок и некоторых ошибок во всех битах
в 16-битовом слове.
Описание: каждое слово в памяти расширяется несколькими избыточными битами для формирования
модифицированного кода Хэмминга с расстоянием, равным 4 (по меньшей мере). При каждом считывании слова
проверка избыточных битов может указывать, произошло или нет искажение. При обнаружении различия вырабатывается сообщение об ошибке. Эта процедура может также использоваться для обнаружения ошибок адресации путем вычисления избыточных битов для объединения слова данных с его адресом.
Литература:
Error detecting and error
correcting codes. R. W. Hemming, The Bell System Technical Journal 29 (2),
147-160, 1950.
Prüfbare und korrigierbare Codes. W. W. Peterson, München, Oldenburg, 1967.
A.4.2 Модифицируемая контрольная сумма
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.5).
Цель: обнаружение всех ошибок нечетных битов, то есть приблизительно 50 % всех возможных битовых
ошибок.
Описание: контрольная сумма блока памяти образуется соответствующим алгоритмом, который обрабатывает все слова в блоке памяти. Эта контрольная сумма может храниться как дополнительные слово в ROM, либо
может быть добавлена как дополнительное слово в блок памяти для того, чтобы алгоритм контрольной суммы
выработал заранее заданное значение. В последнем тестировании памяти контрольная сумма создается снова
с использованием того же алгоритма, и результат сравнивается с запомненным или заданным значением. При
обнаружении различий вырабатывается сообщение об ошибке.
Литература:
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.
A.4.3 Сигнатура одного слова (8 бит)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.5).
Цель: обнаружение всех однобитовых ошибок и всех многобитовых ошибок в слове при достижении приблизительно 99, 6 % всех возможных битовых ошибок.
Описание: содержимое блока памяти сжимается (с использованием аппаратных или программных средств) в одно слово памяти с использованием алгоритма контроля с помощью избыточного циклического кода (CRC). Типичный алгоритм CRC рассматривает все содержимое блока памяти как побайтовый или побитовый последовательный поток данных, в котором выполняется непрерывное полиномиальное деление с использованием
полиномиального генератора. Остаток от деления сохраняется и представляет собой сжатое содержимое памяти - «сигнатуру» памяти. Сигнатура вычисляется еще раз в последующем тестировании и сравнивается с уже
запомненным значением. При обнаружении различий выдается сообщение об ошибке.
Литература:
Calculating an error
checking character in software. S. Vasa, Computer Design, 5, 1976.
Berechnung von
Fehlererkennungswahrscheinlichkeiten bei Signaturregistem. D. Leisengang,
Elektronische Rechenanlagen 24, H. 2, S. 55-61, 1982.
A.4.4 Сигнатура двойного слова (16 бит)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.5).
Цель: обнаружение всех однобитовых ошибок и всех многобитовых ошибок в слове составляет примерно
99, 998 % всех возможных битовых ошибок.
Описание: данная процедура вычисляет сигнатуру с использованием алгоритма контроля с помощью CRC, однако длина результирующего значения составляет, по меньшей мере, два слова. Расширенная сигнатура заносится в память, повторно вычисляется и сравнивается как одно слово. При обнаружении различий между сохраненной и повторно вычисленной сигнатурами выдается сообщение об ошибке.
Литература:
Signaturanalyse in der
Datenverarbeitung. D. Leisengang, M. Wagner, Elektronik 32, H. 21, S. 67-72,
1983.
Signaturregister für selbsttestende ICs. B. Könemann, J. Mucha, G.
Zwiehoff, Gropttintegration/ NTG-Fachtagung Baden-Baden, S. 109-112, April
1977.
A.4.5 Повторение блока (например дублирование ROM в аппаратном и программном исполнении)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.5).
Цель: обнаружение всех битовых ошибок.
Описание: адресное пространство дублируется в двух областях памяти. Первая область памяти работает в
нормальном режиме. Вторая - содержит ту же информацию и доступна параллельно с первой. Их выходы
сравниваются, и при обнаружении различий выдается сообщение об ошибке. Для обнаружения некоторых видов
битовых ошибок данные должны запоминаться инверсно в одной из двух областей памяти и инвертироваться
обратно при чтении.
Литература:
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.
Computers can now perform
vital safety functions safely. Otto Berg von Linde, Railway Gazette International,
Vol. 135, No. 11, 1979.
A.5 Память с произвольным доступом
Главная цель: обнаружение отказов во время адресации, записи, запоминания и считывания.
А.5.1 Тесты «шахматная доска» и «марш» для памяти с произвольным доступом
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение преимущественно статических битовых ошибок.
Описание: расположенная в шахматном порядке битовая комбинация нулей и единиц записывается в
ячейки памяти с битовой организацией. Затем эти ячейки анализируются попарно с тем, чтобы убедиться в их
одинаковости и правильности. Адрес первой ячейки такой пары является переменным, а адрес второй ячейки
этой пары образуется путем битового инвертирования первого адреса. При первом прохождении диапазон адресов памяти проходится в направлении более высоких адресов переменных адресов, а при втором прохождении
- в направлении более низких адресов. После этого оба прохождения повторяются с заранее заданным инвертированием. При обнаружении какого-либо различия выдается сообщение об отказе.
При «маршевом» тестировании памяти с произвольным доступом ячейки памяти с битовой организацией
инициализируются унифицированным потоком битов. При первом прохождении ячейки анализируются в нисходящей последовательности; проверяется правильность содержимого каждой ячейки и ее содержимое инвертируется. Основа, созданная в первом прохождении, рассматривается при втором прохождении в убывающем
порядке и так же обрабатывается. Первые прохождения повторяются с инвертируемыми предварительными
значениями в третьем и четвертом прохождениях. При обнаружении различий выдается сообщение об отказе.
Литература:
Memory testing. W. G. Fee,
LSI Testing (Tutorial at COMPCON 11 in
San Francisco), IEEE Computer Society, W. G. Fee (ed.), 81-88, 1978.
Memory testing. P.
Rosenfield, Electronics and Power, H. 1, P. 26-31, 1979.
Halbleiterspeicher-Testfolgen.
Th. John, E. Schaefer, Elektronikpraxis, H. 6, 18-26 and H. 7, 10-14, 1980.
A.5.2 Тест «прогулочная дорожка» для памяти с произвольным доступом
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение статических и динамических ошибочных битов и перекрестных помех между ячейками
памяти.
Описание: тестируемая область памяти инициализируется унифицированным потоком битов. Затем первая ячейка инвертируется и остальная часть памяти анализируется на правильность. После этого первая ячейка
повторно инвертируется для возврата в исходное значение, и вся процедура повторяется для следующей ячейки. Второе прохождение «модели блуждающего бита» осуществляется при инверсии всех первоначально назначенных значений памяти. При обнаружении различий выдается сообщение об ошибке.
Литература:
Memory testing W. G. Fee,
LSI Testing (Tutorial at COMPCON 11 in
San Francisco), IEEE Computer Society, W. G. Fee (ed.), 81-88, 1978.
Techniques for testing the
microprocessor family. W. Barraclough, A. Chiang, W. Sohl, Proceedings of IEEE
64 (6), 943-950, 1976.
A.5.3 Тест «бегущий код» для памяти с произвольным доступом
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение статических битовых ошибок и больших пропорций динамических связей.
Описание: при тестировании памяти с произвольным доступом «попарной записью-считыванием» выбранная область памяти сначала инициализируется унифицированно (то есть все 0 или все 1). После этого первая
ячейка памяти тестируется и затем инвертируется, и все остальные ячейки анализируются на правильность содержимого. После каждого доступа по чтению к одной из оставшихся ячеек инвертированная ячейка также проверяется. Эта процедура повторяется для каждой ячейки в выбранной области памяти. Второе прохождение
выполняется противоположно первому. Любые различия приводят к выдаче сообщения об ошибке.
Тестирование «прозрачной попарной записью-считыванием» представляет собой вариацию описанной
выше процедуры: вместо инициализации всех ячеек в выбранной области памяти существующее содержимое
остается неизменным, а для сравнения содержимого набора ячеек используются контрольные суммы (сигнатуры). Выбирается первая тестируемая ячейка области памяти и вычисляется и сохраняется сигнатура S1 всех
оставшихся ячеек области. Затем тестируемые ячейки инвертируются, и повторно вычисляется сигнатура S2. (После каждого доступа по чтению к одной из оставшихся ячеек инвертируемая ячейка также проверяется). Сигнатура S2 сравнивается с сигнатурой S1 и при любом различии выдается сообщение об ошибке. Тестируемая ячейка
повторно инвертируется для повторного установления исходного содержимого и сигнатура S3 всех оставшихся
ячеек повторно вычисляется и сравнивается с сигнатурой S1. Любые различия приводят к выдаче сообщения об
ошибке. Все ячейки памяти в выбранной области тестируются тем же способом.
Литература:
Entwurf von
Selbsttestprogrammen für Mikrocomputer. E. Maehle, Microcomputing.
Berichte der Tagung III/79 des German Chapter of ACM, W. Remmele, H. Schecher,
(ed.), Stuttgart, Teubner, 204-216, 1979.
Periodischer Selbsttest
einer mikroprocessorgesteuerten Sicherheitsschaltung. U. Stinnesbek,
Diplomarbeit am Institut fur theoretische Elektrotechnik der RWTH Aachen 1980.
A.5.4 Тест «Абрахам» для памяти с произвольным доступом
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение всех постоянных отказов и отказов в соединениях между ячейками памяти.
Описание: диагностический охват выше, чем при тесте «попарная запись-считывание». Число операций, необходимых для выполнения всего тестирования памяти, составляет примерно 30 n, где n - число ячеек памяти. Тестирование может быть «прозрачным» при выполнении запоминания и тестирования в различных временных
сегментах в периоде рабочего цикла.
Литература:
Efficient Algorithms for
Testing Semiconductor Random-Access Memories. R. Nair, S. M. Thatte, J. A.
Abraham, IEEE Trans. Comput. C-27 (6), 572-576,
1978.
A.5.5 Однобитовая избыточность (например контроль памяти с произвольным доступом с помощью
бита четности)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение 50 % всех возможных битовых отказов в тестируемой области памяти.
Описание: каждое слово в памяти расширяется на один бит (бит четности), который дополняет каждое
слово до четного или нечетного числа логических единиц. Четность слова данных проверяется при каждом чтении. При обнаружении ложного числа единиц выдается сообщение об ошибке. Выбор четности или нечетности
должен осуществляться так, чтобы всякий раз в случае отказа не выдавалось ничего кроме нулевого (0) и единичного (1) слова, вырабатывалось уведомление о том, что это слово неправильно закодировано. Контроль четности
также может быть использован для обнаружения ошибок адресации, если четность определяется для объединения слова данных с его адресом.
Литература:
Integrierte
Digitalbausteine. К. Reiβ, H. Liedl, W. Spichall, Berlin, 1970.
A.5.6 Контроль памяти с произвольным доступом с помощью модифицированного кода Хэмминга или
обнаружение ошибок данных с кодами обнаружения и исправления ошибок (EDC)
Примечание - См. также А.4.1 и С.3.2. Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение всех нечетных битовых отказов, всех двухбитовых отказов, некоторых трехбитовых отказов и некоторых многобитовых отказов.
Описание: каждое слово в памяти расширяется несколькими избыточными битами для выработки модифицированного кода Хэмминга с расстоянием Хэмминга равным, по меньшей мере, 4. При каждом считывании
слова проверка избыточных битов может указывать, произошло или нет искажение. При обнаружении различий
выдается сообщение об отказе. Эта процедура может быть также использована для обнаружения ошибок адресации при вычислении избыточных битов для объединения слова данных с его адресом.
Литература:
Error detecting и error correcting codes. R. W. Hamming, The Bell
System Technical Journal 29 (2), 147-160, 1950.
Prüfbare und korrigierbare Codes. W. W. Peterson, München, Oldenburg, 1967.
А.5.7 Дублирование со сравнением памяти с произвольным доступом с аппаратными или программными средствами и тестирование чтением/записью
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.6).
Цель: обнаружение всех битовых отказов.
Описание: адресное пространство содержит две части. Первая часть памяти функционирует в нормальном
режиме. Вторая часть памяти содержит ту же информацию и доступна параллельно с первой. Выходы этих
частей памяти сравниваются. При обнаружении различий выдается сообщение об ошибке. Для обнаружения
некоторых видов битовых ошибок данные должны сохраняться инверсно в одной из двух частей памяти и обратно
инвертироваться при чтении.
Литература:
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.
Computers can now perform
vital function safely. Otto Berg von Linde, Railway Gazette International, Vol.
135, No. 11, 1979.
А.6 Устройства ввода-вывода и интерфейсы (внешний обмен)
Главная цель: обнаружение отказов на устройствах ввода и вывода (цифровые, аналоговые, последовательные или параллельные) и предотвращение дальнейшей передачи недопустимых выходных данных.
А.6.1 Тестирующая комбинация
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.7, А.14 и А.15).
Цель: обнаружение статических отказов (постоянные отказы) и перекрестных помех.
Описание: этот метод реализует независимое от потока данных циклическое тестирование входных и выходных элементов. В нем используются определенные тестирующие комбинации для сравнения с соответствующими этим тестирующим комбинациям предполагаемыми значениями. Информация тестирующей комбинации, восприятие и оценка тестирующей комбинации должны быть независимы друг от друга. Тестирующие комбинации
не должны неблагоприятно влиять на операции EUC.
Литература:
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.
A.6.2 Кодовая защита
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.7, А.16, А.17 и А.19).
Цель: обнаружение случайных отказов аппаратных средств и систематических ошибок в потоке ввода/вывода данных.
Описание: процедура, реализующая кодовую защиту, защищает вводимую и выводимую информацию от
систематических и случайных отказов аппаратных средств. Кодовая защита обеспечивает зависимое от потока
данных обнаружение отказов входных и выходных модулей, основываясь на избыточности информации и/или
временной избыточности. Обычно избыточная информация налагается на входные и/или выходные данные; тем
самым обеспечиваются средства для мониторинга правильности операций входных и выходных схем. Возможно
применение многих методов - например, сигнал несущей частоты может налагаться на выходной сигнал датчика. После этого логический модуль может проверить наличие частоты несущей, либо на выходе канала могут быть
добавлены избыточные кодовые биты для контроля действительности прохождения сигнала между логическим
модулем и оконечным исполнительным механизмом.
Литература:
Standard input/output tests
and monitoring procedures - 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.
A.6.3 Многоканальное параллельное выходное устройство
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.7).
Цель: обнаружение случайных отказов аппаратных средств (константные отказы), отказов, обусловленных
внешними воздействиями, временных сбоев, отказов адресации, постепенных отказов и самоустраняющихся
отказов.
Описание: это зависимое от потока данных многоканальное параллельное выходное устройство с независимыми выходами для обнаружения случайных аппаратных отказов. Обнаружение отказов осуществляется с
помощью внешних компараторов. При появлении отказа EUC непосредственно отключается. Это устройство действует только в том случае, если поток данных изменяется в интервале диагностического тестирования.
Литература:
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.
A.6.4 Средство контроля выходов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.7).
Цель: обнаружение случайных отказов, отказов, обусловленных внешними воздействиями, временных сбоев, отказов адресации, постепенных отказов (для аналоговых сигналов) и самоустраняющихся отказов.
Описание: это устройство, зависимое от потока данных, сравнивает выходные данные с независимыми
входными данными для обеспечения совместимости с областью допустимых значений (время, диапазон). Обнаруженный отказ не всегда относится к неправильному выходному сигналу. Это устройство действует только в том
случае, если поток данных изменяется в интервале диагностического тестирования.
Литература:
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.
MSR-Schutzeinrichtungen.
Anforderungen und Massnahmen zur gesicherten Funktion. DIN V 19251, February
1995.
A.6.5 Сравнение/голосование входных данных
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.7 и А.14).
Цель: обнаружение случайных отказов, отказов, обусловленных внешними воздействиями, временных сбоев, отказов адресации, постепенных отказов (для аналоговых сигналов) и самоустраняющихся отказов.
Описание: это устройство, зависимое от потока данных, сравнивает выходные данные с независимыми
входными данными для обеспечения совместимости с областью допустимых значений (время, диапазон). Реализуемая избыточность может быть 1 из 2, 2 из 3 или более высокая. Это устройство действует только в том случае, если поток данных изменяется в интервале диагностического тестирования.
Литература:
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.
MSR-Schutzeinrichtungen.
Anforderungen und Massnahmen zur gesicherten Funktion. DIN V 19251, February
1995.
А.7. Маршруты данных (внутренний обмен)
Главная цель: обнаружение отказов, обусловленных искажениями при передаче информации.
А.7.1 Однобитовая аппаратная избыточность
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.8).
Цель: обнаружение всех нечетно-битовых ошибок, то есть 50 % всех возможных битовых ошибок в потоке
данных.
Описание: шина расширяется на одну линию (бит) и эта дополнительная линия (бит) используется для
обнаружения отказов путем проверки на четность.
Литература:
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.
A.7.2 Многобитовая аппаратная избыточность
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.8).
Цель: обнаружение отказов в процессе передачи по шине и в последовательных каналах связи.
Описание: шина расширяется на две или более линий (битов) и эти дополнительные линии (биты) используются для обнаружения отказов методом кода Хэмминга.
Литература:
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.
A.7.3 Полная аппаратная избыточность
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.8).
Цель: обнаружение отказов в процессе передачи данных путем сравнения сигналов двух шин. Описание: шина дублируется и дополнительные линии (биты) используются для обнаружения отказов.
Литература:
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.
A.7.4 Анализ с использованием тестирующих комбинаций
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.8).
Цель: обнаружение статических отказов (постоянных отказов) и перекрестных помех.
Описание: осуществляется независимое от потока данных циклическое тестирование маршрутов данных. Используется определенная тестирующая комбинация для сравнения наблюдаемых значений с соответствующими предполагаемыми значениями.
Восприятие информации о тестирующей комбинации и ее оценка должны быть независимы друг от друга. Тестирующие комбинации не должны неблагоприятно влиять на операции EUC.
Литература:
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.
A.7.5 Избыточность при передаче
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.8).
Цель: обнаружение самоустраняющихся отказов в обмене по шине.
Описание: информация передается последовательно несколько раз. Повторение осуществляется только
для обнаружения самоустраняющихся отказов.
Литература:
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.
A.7.6 Информационная избыточность
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.8).
Цель: обнаружение отказов в обмене по шине.
Описание: данные передаются блоками наряду с вычислениями контрольной суммы для каждого блока. После этого приемник повторно вычисляет контрольную сумму полученных данных. Результат сравнивается с
полученной контрольной суммой.
Литература:
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.
А.8 Питание
Главная цель: обнаружение или устойчивость к отказам, обусловленным источником питания.
А.8.1 Защита от броска напряжения с помощью безопасного выключения
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.9).
Цель: защита систем, связанных с безопасностью, от броска напряжения.
Описание: бросок напряжения обнаруживается достаточно рано с тем, чтобы все выходы могли быть переключены в безопасное состояние процедурой отключения питания или переключились на второй блок питания.
Литература:
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
A.8.2 Управление напряжением (вторичным)
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.9).
Цель: контроль вторичных напряжений и инициализация безопасного состояния, если значение напряжения не находится в заданном диапазоне.
Описание: вторичное напряжение контролируется и питание отключается либо происходит переключение
на второй блок питания, если напряжение не
находится в заданном диапазоне.
А.8.3 Выключение питания с соблюдением безопасности
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.9).
Цель: выключение питания с безопасным сохранением имеющейся информации.
Описание: бросок напряжения или недонапряжение обнаруживается достаточно рано с тем, чтобы сохранить внутреннее состояние в неэнергозависимой памяти (при необходимости) и тем самым установить все выходы в безопасное состояние процедурой отключения питания, или же все выходы переключить в безопасное
состояние процедурой отключения питания, либо происходит переключение на второй блок питания.
А.9 Временной и логический контроль последовательности выполнения программ
Примечание - На эту группу методов или средств даны ссылки в МЭК 61508-2 (см. приложение А, таблицы А.16, А.17 и А.19).
Главная цель: обнаружение искаженных программных последовательностей. Искаженная программная
последовательность появляется, если отдельные элементы программы (например, программные модули, подпрограммы или команды) обрабатываются в неправильной последовательности или в несоответствующий период времени, или если сбилась тактовая частота процессора.
А.9.1 Контрольный датчик времени с отдельной временной базой без временного окна
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.10
и
А.12).
Цель: контроль поведения и последовательности выполнения программ.
Описание: внешние средства определения времени с отдельной базой времени (например, контрольный
датчик времени) периодически переключаются для контроля поведения компьютера и последовательности выполнения программ. Важно, чтобы моменты переключения были правильно расположены в программе. Контрольный датчик времени не переключается с некоторым фиксированным периодом, однако задается максимальный интервал.
Литература:
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.
A.9.2 Контрольный датчик времени с отдельной временной базой и временным окном
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.10
и
А.12).
Цель: контроль поведения и последовательности выполнения программ.
Описание: внешние средства определения времени с отдельной базой времени (например, контрольный
датчик времени) периодически переключаются для контроля поведения компьютера и последовательности выполнения программ. Важно, чтобы моменты переключения были правильно расположены в программе. Контрольный датчик времени не переключается с некоторым фиксированным периодом, однако задается максимальный интервал. Если последовательности программ выполняются больше или меньше ожидаемого времени, то выполняется действие чрезвычайного случая.
Литература:
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.
A.9.3 Логический контроль последовательности выполнения программ
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.10 и А.12).
Цель: контроль правильной последовательности выполнения отдельных частей программы.
Описание: правильная последовательность выполнения отдельных частей программы контролируется с
помощью программных средств (процедур учета, ключевых процедур) или с использованием внешних средств
контроля. Важно, чтобы точки проверки располагались в программе правильно.
Литература:
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.
A.9.4 Комбинация временного и логического контроля программной последовательности
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.10
и
А.12).
Цель: контроль поведения и правильной последовательности выполнения отдельных частей программы.
Описание: средство определения времени (например, контрольный датчик времени), контролирующее программную последовательность, вновь запускается только в случае, если последовательность модулей программы
выполнятся правильно.
Литература:
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.
А.9.5 Первоначальный тест при включении
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.10 и А.12).
Цель: обнаружение отказов при первоначальном тесте.
Описание: при запуске проводится первоначальный тест. Запуск возможен только в случае, если первоначальный тест прошел успешно. Например, датчик температуры может быть проверен нагретым резистором при
запуске.
А.10 Вентиляция и температура
Примечание - На эту группу методов и средств дана ссылка в МЭК 61508-2 (см. приложение А, таблицы
А.17
и А.19).
Главная цель: управление отказами в системах вентиляции и температурных приборах и/или их контроль, если они связаны с безопасностью.
А.10.1 Датчик температуры
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.11).
Цель: обнаружение температурного перегрева или недогрева до того, как система начнет действовать вне
заданных требований.
Описание: датчик температуры контролирует температуру в наиболее критических точках E/E/PES. Прежде
чем температура выйдет из заданного диапазона, происходит аварийное действие.
А.10.2 Управление вентиляцией
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.11).
Цель: обнаружение отказов в работе вентилятора.
Описание: работа вентиляторов контролируется. Если вентилятор находится в нерабочем состоянии, то
предпринимаются действия по восстановлению его рабочего состояния (или его аварийному отключению).
А.10.3 Безопасное выключение с использованием плавкого предохранителя
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.11).
Цель: выключение системы, связанной с безопасностью, до того как параметры системы выйдут из заданных температурных режимов.
Описание: плавкий предохранитель используется для выключения систем, связанных с безопасностью. В системе PES выключение осуществляется процедурой отключения питания, которая хранит информацию, необходимую при аварийных действиях.
А.10.4 Пороговые сообщения от термодатчиков и условная тревога
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.11).
Цель: показать, что системы, связанные с безопасностью, работают также за пределами допусков по температуре.
Описание: измеряется температура, а при ее выходе из заданного диапазона выдается аварийный сигнал.
А.10.5 Соединение устройства принудительного охлаждения воздуха и индикатора состояний
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.11).
Цель: не допустить перегрева путем искусственного воздушного охлаждения.
Описание: измеряется температура. Если температура превышает заданный предел, то включается искусственное воздушное охлаждение. Пользователь информируется об измеренном значении температуры.
А.11 Обмен и запоминающее устройство большой емкости
Главная цель: контроль отказов в процессе обмена между внешними источниками и запоминающим устройством большой емкости.
А.11.1 Отделение линий электрического питания от информационных линий
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.13).
Цель: минимизировать перекрестные помехи информационных линий, индуцируемые сильным током системы питания.
Описание: линии, обеспечивающие электрическое питание, отделяются от линий, переносящих информацию. Электрическое поле, которое может индуцировать на информационных линиях всплески напряжения, уменьшается с увеличением расстояния.
А.11.2 Пространственное разделение групповых линий
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.13 и А. 17).
Цель: минимизировать перекрестные помехи, индуцируемые током системы питания в групповых линиях.
Описание: линии с дублирующими сигналами отделяются друг от друга. Электрическое поле, которое могут
индуцировать броски напряжений в групповых линиях, уменьшается с увеличением расстояния. Это отделение
линий снижает также отказы по общей причине.
А.11.3 Повышение устойчивости к электромагнитным воздействиям
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.13, А.17 и А.19).
Цель: минимизировать электромагнитные влияния на систему, связанную с безопасностью.
Описание: создание таких методов, как экранирование и фильтрация, для уменьшения чувствительности
систем, связанных с безопасностью, к электромагнитным полям, которые могут наводиться на линии питания или
сигнальные линии, либо возникать в результате электростатических разрядов [7].
Литература:
Noise Reduction Techniques
in Electronic Systems. H. W. Ott, John Wiley Interscience, 2nd Edition, 1988.
EMC for Product Designers,
Tim Williams, Newnes, 1992, ISBN 0-7506-1264-9.
Grounding and Shielding
Techniques in Instrumentation. John Wiley & Sons, New York, 1986.
Principles and Techniques
of Electromagnetic Compatibility. С Christopoulos, CRC Press, 1995.
Gestaltung von
Maschinensteuerungen unter Berücksichtigung der elektromagnetischen Verträglichkeit. F. Börner,
Sicherheitstechnisches Informations-und Arbeitsblatt 330260, BIA-Handbuch. 20.
Lfg. V/93, Erich Schmidt Verlag, Bielefeld.
A.11.4 Передача неэквивалентных сигналов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицы А.13 и А.17).
Цель: обнаружение одинаковых индуцированных напряжений в групповых линиях передачи сигналов.
Описание: вся дублируемая информация передается с антивалентными сигналами (например логические
1 и 0). Ошибки по общей причине (например, вызванные электромагнитными излучениями) могут быть обнаружены антивалентным компаратором.
Литература:
Elektronik in der
Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches
Informations-und Arbeitsblatt 330220, BIA-Handbuch. 20. Lfg. V/93, Erich Schmidt
Verlag, Bielefeld.
A.12 Датчики
Главная цель: обнаружение отказов в датчиках систем, связанных с безопасностью.
А.12.1 Эталонный датчик
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.14).
Цель: обнаружение отказа датчика.
Описание: для контроля работоспособности датчика используется независимый эталонный датчик. Все
входные сигналы в подходящие временные интервалы проверяются эталонным датчиком для обнаружения отказов в работе проверяемого датчика.
Литература:
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
A.12.2 Положительно-управляемый переключатель
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.14).
Цель: разомкнуть контакт с помощью непосредственного механического соединения между кулачком переключателя и контактом.
Описание: положительно управляемый переключатель размыкает свои обычно замкнутые контакты непосредственным механическим соединением между кулачком переключателя и контактом. Разомкнутость контактов
переключателя обеспечивается всякий раз, когда кулачок переключателя находится в рабочем положении.
Литература:
Verriegelung beweglicher
Schutzeinrichtungen. F. Kreutzkampf, К. Becker, Sicherheitstechnisches Informations-und Arbeitsblatt 330210,
BIA-Handbuch. 1. Lfg. IX/85, Erich Schmidt Verlag, Bielefeld.
А.13 Оконечные элементы (приводы)
Главная цель: обнаружение отказов в оконечных элементах систем, связанных с безопасностью.
А.13.1 Мониторинг
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.15).
Цель: обнаружение отказа привода.
Описание: операции привода контролируются (например положительно управляемыми контактами реле; см. контроль релейных контактов в А.1.2). Избыточность, вносимая этим контролем, может быть использована для
переключения на аварийный режим.
Литература:
Zusammenstellung und
Bewertung elektromechanischer Sicherheitsschaltungen für Verriegelungseinrichtungen. F. Kreutzkampf, W.
Hertel, Sicherheitstechnisches Informations-und Arbeitsblatt 330212,
BIA-Handbuch. 17. Lfg. X/91, Erich Schmidt Verlag, Bielefeld.
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
A.13.2 Перекрестный контроль групповых приводов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.15).
Цель: обнаружение отказов в приводах путем сравнения результатов контроля.
Описание: каждый групповой привод контролируется своим аппаратным каналом. При обнаружении различий вырабатывается аварийное действие.
А.14 Средства против физического воздействия окружающей среды
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (см. приложение А, таблицу А.17).
Цель: предотвратить влияние физической окружающей среды (влажности, пыли, коррозийных субстанций), вызывающих отказы.
Описание: покрытия оборудования должны противостоять чрезмерным внешним воздействиям [2].
Примечание - Многие методы, представленные в данном приложении относятся и к программным
средствам, но в приложении С они не описаны.
В.1 Общие методы и средства
В.1.1 Управление проектами
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 -
В.6).
Цель: устранение отказов с использованием организационной модели, правил и средств по разработке и
тестированию систем, связанных с безопасностью.
Описание: наиболее значимыми и лучшими средствами являются:
-
создание организационной модели в основном для обеспечения качества (см. стандарты серий ИСО
9000-1 -
ИСО 9004-1 или аналогичные им), описанное во многих работах по обеспечению качества, и
-
установление правил и определение средств для создания и подтверждения соответствия систем, связанных с безопасностью, в руководствах по взаимосвязанным и отдельным проектам.
Для управления проектами установлены следующие важные базовые принципы:
- при выборе проектной организации определяются:
задачи и ответственности подразделений конкретной организации,
полномочия департаментов по обеспечению качества,
независимость гарантии качества (при выполнении внутренней проверки) от разработки;
- план последовательных действий (модель действий) формируется как:
определение действий по выполнению проекта, включая внутренние проверки и график их проведения,
обновление проекта;
- стандартная последовательность для внутренней проверки определяется как:
планирование, проведение и контроль проверки (теория проверки), использование различных механизмов проверок для составных частей, сохранение результатов повторных проверок;
- управление конфигурацией реализуется как:
администрирование и проверка версий, выявление результатов модификаций, проверки согласованности после модификаций;
- вводятся количественные оценки для средств обеспечения качества в виде:
установления требований, статистики отказов;
- вводятся автоматизированные универсальные методы, инструменты и средства обучения персонала.
Литература:
IEEE: Software Engineering
Standards. lEEE/Wiley-lnterscience, New York, 1987.
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN
1-85166-203-0.
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.1.2 Документация
Примечания
1 Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.1 -
В.6).
2
См.
также МЭК 61508-1 (раздел 5 и приложение А).
Цель: устранение отказов и упрощение процедуры оценки безопасности с помощью систем документирования каждого шага процесса разработки.
Описание: во время процедуры оценки, наряду со всеми составляющими, включенными в разработку, необходимо также уделять внимание эксплуатационным характеристикам и безопасности. В процессе разработки и
обеспечения в любой момент времени проверки доказательств безопасности особое внимание уделяется документации на систему [17].
Основными общими подходами к документированию являются введение руководящих принципов создания
документов и использование автоматизации, в том числе:
- руководящие принципы:
определяют структуру документа,
используют таблицы контрольных проверок для формирования содержания документа и
определяют формат документа;
-
автоматизация управляет документированием и создается структурированная библиотека проекта.
К конкретным методам создания документов относятся:
-
разделение в документации описаний:
требований,
системы (документация пользователя) и
разработки (включая внутреннюю проверку);
-
группирование разработанной документации в соответствии с жизненным циклом безопасности;
-
определение стандартных модулей документации, из которых могут быть скомпилированы документы;
-
ясная идентификация составных частей документа;
-
формализованное обновление версий;
-
выбор ясных и понятных средств описания:
формализованная нотация для определений,
естественный язык для введений, обоснований и представления намерений,
графическое представление для описания примеров,
семантическое определение для графических элементов и
терминологические справочники.
Литература:
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.
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).
Цель: снижение сложности во время эксплуатации систем, связанных с безопасностью.
Описание: правильность эксплуатации систем, связанных с безопасностью, в определенной степени зависит от оператора. Рассматривая конкретные проекты системы и рабочего места, разработчик систем, связанных
с безопасностью, должен предусмотреть:
-
необходимость минимального вмешательства человека;
-
необходимое вмешательство наиболее простым;
-
возможность минимального ущерба от ошибок оператора;
-
эргономические требования при проектировании средств вмешательства и индикации;
-
простые, имеющие четкую маркировку и удобные для использования средства оператора;
-
неперенапряженность оператора даже в экстремальной ситуации;
-
адаптированность обучения процедурам и средствам процесса вмешательства к уровню знаний и мотивации обучаемого пользователя.
B.4.3 Удобство общения с обслуживающим персоналом
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.4).
Цель: упрощение процедуры обслуживания систем, связанных с безопасностью, и проектирование необходимых средств для эффективной диагностики и ремонта.
Описание: профилактическое обслуживание и ремонт часто проводятся в сложных условиях давления
предельных сроков. Поэтому разработчик систем, связанных с безопасностью, должен предусмотреть чтобы:
-
средства, относящиеся к обслуживанию безопасности, требовались как можно реже или вообще не требовались;
-
использовались достаточно чувствительные и легко управляемые диагностирующие инструменты для неизбежных ремонтов; эти инструменты должны включать в себя все необходимые интерфейсы;
-
было достаточно времени (если отдельные инструменты диагностики необходимо разработать или приобрести).
B.4.4 Сокращение работ на стадии эксплуатации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.4 и В.6).
Цель: снизить эксплуатационные возможности для обычного пользователя. Описание: этот подход снижает эксплуатационные возможности путем:
-
ограничения операций в рабочих режимах, например коммутаторами ключей;
-
ограничения числа используемых в работе элементов;
-
ограничения числа возможных в общем случае рабочих режимов.
Литература:
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.4.5 Эксплуатация только квалифицированным оператором
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.4 и В.6).
Цель: исключение отказов, обусловленных ошибками оператора.
Описание: оператор системы, связанной с безопасностью, обучен до степени, соответствующей сложности
и степени безопасности систем, связанных с безопасностью. В обучение входит изучение основ процесса производства и взаимосвязей между системами, связанными с безопасностью и EUC.
Литература:
Guidelines for Safe
Automation of Chemical Processes. CCPS, AlChE, New York, 1993.
B.4.6 Защита от ошибок оператора
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.6).
Цель: защита системы от всех видов ошибок оператора.
Описание: ложные входные сообщения (значение, время, и т.д.) обнаруживаются проверками достоверности или контролем EUC. Для того, чтобы объединить эти средства в проекте, необходимо на самом раннем этапе
определить, какие из входных сообщений возможны и какие допустимы.
B.4.7 (Не используется)
B.4.8 Защита от модификаций
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица А.18).
Цель: защита системы, связанной с безопасностью, от модификаций аппаратных средств техническими
способами.
Описание: модификации или манипуляции обнаруживаются автоматически, например проверками достоверности сигналов датчиков, обнаружением техническим процессом и автоматическим запуском тестирования. При обнаружении модификации выдается аварийный сигнал.
B.4.9 Подтверждение ввода
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы А.18 и А.19).
Цель: обнаружение ошибки во время работы самим оператором до активизации EUC.
Описание: информация, вводимая в EUC через систему, связанную с безопасностью, представляется оператору до передачи в EUC с тем, чтобы оператор имел возможность обнаружить и исправить ошибки. Проектируемая система должна реагировать на неправильные, самопроизвольные действия оператора и учитывать нижние/верхние пределы скорости и направление реакции оператора. Это позволит исключить, например, более
быстрое, чем предполагается, нажатие клавиш оператором, и настроить систему воспринимать двойное нажатие
клавиши как одинарное или двойное за счет того, что система (изображение на экране) слишком медленно реагирует на разовое нажатие клавиши. Последовательное нажатие одной и той же клавиши при вводе критических
данных должно восприниматься системой как одноразовое; нажатие клавиш «ввод» (enter) или «да» (yes) неограниченное число раз не должно приводить к нарушению безопасности системы.
Должны быть предусмотрены процедуры формирования временных пауз с возможностью выбора разных
ответов (да/нет и т.п.) с тем, чтобы обеспечить возможность для размышления оператору, а системе - режим
ожидания.
Любая перезагрузка PES, связанной с безопасностью, делают систему уязвимой, если программные/аппаратные средства не спроектированы с учетом этой ситуации.
Литература:
DIN V VDE 0801: Grundsätze für Rechner in Systemen mit
Sicherheitsaufgaben (Principles for Computers in Safety-Related Systems)
Beuth-Verlag, Berlin, 1990.
B.5 Интеграция E/E/PES
Главная цель: исключение отказов системы на стадии интеграции и обнаружение любых отказов во время
этой и предыдущей стадий.
В.5.1 Функциональное тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3 и В.5) и в МЭК 61508-3 (таблицы А.5 -
А.7).
Цель: обнаружение отказов на стадиях создания спецификации и проектирования. Исключение отказов во
время реализации и интеграции программных и аппаратных средств.
Описание: в процессе функционального тестирования определяется, достигнуты ли заданные характеристики системы. В систему поступают входные данные, которые адекватно характеризуют обычное выполнение
операций. Наблюдаемые выходные результаты сравниваются с заданными в спецификации. Отклонения от спецификации и указания на неполноту спецификации документируются.
Функциональное тестирование электронных компонентов, предназначенных для многоканальной архитектуры, обычно включает в себя промышленные компоненты, каждый из которых поставщик уже протестировал и
предварительно подтвердил соответствие. Помимо этого рекомендуется, чтобы покупные промышленные компоненты были протестированы в сочетании с другими компонентами поставщика из той же партии, чтобы выявить
неисправности группового типа, которые в противном случае остались бы невыявленными.
Также о достаточных рабочих возможностях системы см. руководящие материалы (приложение С, подраздел С.5.20).
Литература:
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.5.2 Тестирование методом «черного ящика»
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3, В.5 и В.6) и
в
МЭК 61508-3 (таблицы А.5 -
А.7).
Цель: проверка динамического поведения системы в реальных условиях функционирования. Выявление
несоответствия функциональной спецификации и оценка ее полезности и устойчивости.
Описание: функции системы или программы выполняются в заданном окружении с заданными данными
тестирования, которые систематически формируются из спецификации в соответствии с установленными критериями. Это позволяет поведение системы сравнить с ее спецификацией. При проведении тестирования никакие
сведения о внутренней структуре системы не используются. Основная цель состоит в том, чтобы определить, правильно ли выполняет функциональный модуль функции, требуемые спецификацией. Метод формирования
эквивалентных классов служит примером критерия тестирования данных методом «черного ящика». Массив входных данных подразделяется на конкретные диапазоны входных значений (эквивалентные классы) на основе
спецификации. После этого формируются тестовые примеры из:
-
данных из допустимых диапазонов;
-
данных из недопустимых диапазонов;
-
данных предельных значений диапазонов;
-
экстремальных значений и
-
комбинаций из перечисленных выше классов.
Могут оказаться эффективными также другие критерии выбора тестовых примеров в различных режимах
тестирования (модуля, интеграции и системы). Например, критерий «экстремальные эксплуатационные условия»
используется при тестировании системы в процессе подтверждения соответствия.
Литература:
Functional Testing and
Analysis. W. E. Howden, McGraw-Hill Book Comppany, New York, 1987.
Software Testing and
Validation Techniques. E. Miller, W. E. Howden, IEEE Computer Society, New
York, 1978.
The Art of Software
Testing. G. J. Myers, Wiley & Sons, New York, 1979.
Methodik systematischen
Testens von Software. K. Grimm, 30 (4), 1988.
VDI-Gemeinschaftsausschuβ Industrielle
Systemtechnik: Software-Zuverlässigkeit. VDI-Verlag, 1993.
B.5.3 Статистическое тестирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3, В.5 и В.6).
Цель: проверка динамического поведения системы, связанной с безопасностью, и оценка ее полезности и
устойчивости.
Описание: при этом подходе тестируется система или программа с входными данными, выбранными в соответствии с предполагаемым статистическим распределением реальных эксплуатационных входных данных -
эксплуатационный профиль.
Литература:
Software Testing via
Environmental Simulation (CONTESSE Report). Available until December 1998 from:
Ray Browne, CIID, DTI, 151 Buckingham Palace Road, London, SW1W 9SS, UK, 1994.
Aspects of Development and
Verification of Reliable Process Computer Software. W. Ehrenberger, IFAC-IFIP
Conference Proceedings, 35-48, 1980.
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.
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN
1-85166-203-0.
Dependability of Critical
Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN
1-85166-544-7.
B.5.4 Полевые испытания
Примечания
1
См. также приложение С, подраздел С.2.10 - аналогичные средства, а в приложении D - статистический подход - то и другое в контексте программного обеспечения.
2 Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.3 и В.5).
Цель: использование полевых испытаний из различных областей применения в качестве одного из средств
исключения сбоев во время интеграции E/E/PES и/или в процессе подтверждения соответствия безопасности
E/E/PES.
Описание: использование компонентов или подсистем, которые при их использовании показали путем
испытаний отсутствие или наличие только несущественных ошибок и существенно не изменялись в течение достаточно длительного периода времени во многих различных применениях. В частности, для сложных компонентов
с множеством функций (например, операционной системы интегральных схем) разработчик должен обратить
внимание на функции, которые были фактически протестированы методом полевых испытаний. Например, должны быть рассмотрены подпрограммы самотестирования для обнаружения сбоев: при отсутствии сбоев аппаратных средств в период эксплуатации о подпрограммах нельзя сказать, что они протестированы, поскольку они
никогда не выполняли функций обнаружения своих сбоев.
При использовании полевых испытаний должны быть соблюдены следующие требования:
-
неизменность спецификации;
-
наличие 10 систем в различных применениях;
-
длительность работы 105 ч и, по меньшей мере, один год сервисной поддержки.
Полевые испытания документируются поставщиком и/или эксплуатирующей организацией; документация
должна, по меньшей мере, содержать:
-
точное обозначение системы и ее компонентов, включая управление версиями аппаратных средств;
-
сведения о пользователях и времени применения;
-
отработанное время в часах;
-
процедуры выбора системы и прикладные программы, использованные при испытаниях;
-
процедуры обнаружения и регистрации сбоев, а также процедуры устранения их последствий и причин
возникновения.
Литература:
DIN V VDE 0801 А1: 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.
B.6 Подтверждение безопасности E/E/PES
Главная цель: Подтвердить, что система Е/Е/РЕ, связанная с безопасностью, соответствует спецификации
требований безопасности E/E/PES.
В.6.1 Функциональные испытания в условиях окружающей среды
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблица В.5).
Цель: оценка защищенности системы, связанная с безопасностью, от типовых воздействий окружающей
среды.
Описание: систему помещают в различные условия окружающей среды (например, в соответствии со стандартами серии МЭК 60068 или серии МЭК 61000) и оценивают способности системы выполнять функции безопасности (на соответствие требованиям стандартов, указанных выше) [1],
[5].
Литература:
Dependability of Critical
Computer Systems 3. P. G. Bishop et al, Elsevier Applied Science, 1990, ISBN
1-85166-544-7.
B.6.2 Испытания на устойчивость к пиковым выбросам внешних воздействий
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6).
Цель: проверка способности систем, связанных с безопасностью, справляться с пиковыми выбросами внешних воздействий.
Описание: в систему загружается типичная прикладная программа и все периферийные линии (цифровые, аналоговые и последовательные интерфейсы, шины, источники питания и т. д.) подвергаются воздействию стандартных шумовых сигналов. Для того, чтобы получить их количественную оценку, целесообразно внимательно
подходить к предельным значениям выбросов внешних влияний. Класс помех считается выбранным неверно, если функция системы не выполняется [6].
B.6.3 (Не используется).
B.6.4 Статический анализ
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.5 и В.6) и в МЭК
61508-3
(таблица А.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.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 Общие положения
Цель: основная цель методов анализа структуры (структурных методов) состоит в обеспечении качества
разработки программного обеспечения. Данные методы в основном используются на ранних стадиях жизненного цикла создаваемой системы. Структурные методы используют как точные, так и интуитивные процедуры и
нотации (поддерживаемые компьютерами), а также определяют и позволяют документировать требования и
возможности реализации в логической последовательности и структурированным способом.
Описание: существует достаточно много структурных методов. Некоторые из них созданы для выполнения
традиционных функций обработки данных и транзакций, другие (MASCOT, JSD, Yourdon в режиме реального
времени) - в большей степени ориентированы на процессы управления и задачи реального времени (для систем, реализующих такие задачи, характеристика безопасности является более критичной, чем для других систем).
Структурные методы можно считать «интеллектуальными инструментами», предназначенными для обобщенного восприятия и структуризации конкретной проблемы или системы. К их основным свойствам относятся:
-
использование логики в рассуждениях и выводах, декомпозиция сложной проблемы на управляемые
стадии;
-
анализ и документирование общей системы, включая окружающую среду, а также разрабатываемую систему;
-
декомпозиция данных и функций в разрабатываемой системе;
-
использование контрольных таблиц, то есть списков типов объектов, нуждающихся в анализе;
-
малая интеллектуальная перегрузка - простота, интуитивность и практичность при представлении проблемы или системы.
Нотации, используемые для анализа и документирования проблем и объектов системы (например, на
основе процессов и потоков данных), ориентированы на строгость, однако нотации для выражения функций
обработки выполняемых этими объектами являются более неформальными. В то же время некоторые методы
частично используют формальные нотации (например, JSD использует регулярные выражения; Yourdon, SOM и SDL используют теорию конечных автоматов). Увеличение точности нотации не только повышает уровень понимания, но и обеспечивает возможность автоматизированной обработки.
Другим преимуществом структурных нотаций является их наглядность, которая позволяет пользователю
интуитивно проверять возможности спецификации или проекта при неполной информации.
Настоящее приложение содержит подробное описание пяти структурных методов: представление требований, разработка системы по Джексону, MASCOT, Yourdon для систем реального времени и методология структурного анализа и проектирования (SADT).
Литература:
Software Design for
Real-time Systems. J. E. Cooling, Chapman and Hall, 1991.
Structured Development for
Real-Time Systems (3 Volumes). P. T. Ward and S. J. Mellor, Yourdon Press,
1985.
Essential Systems Analysis.
St. M. McMenamin, F. Palmer, Yourdon Inc, New York, 1984.
The Use of Structured
Methods in Development of Large Software-Based Avionic Systems. D. J. Hatley.
Proc. DASC, Baltimore, 1984.
C.2.1.2 CORE - представление требований
Цель: обеспечение требований, определений и формулировок.
Описание: данный метод должен устранить пробел между потребителем/конечным пользователем и аналитиком. Он не основан на математически строгой теории, а является средством коммуникации. Метод CORE создан для представления требований, а не для спецификаций. Данный метод является структурированным, все
его представления проходят через различные уровни уточнений. Метод CORE используется для широкого круга
проблем, учитывает сведения об окружающей среде, в которой система функционирует, а также различные точки
зрения разных типов пользователей. Метод CORE содержит руководящие материалы и тактические подходы для
того, чтобы упростить сложный проект. Такое упрощение может быть скорректировано, либо явным образом
идентифицировано и задокументировано. Таким образом, спецификации могут быть неполными, однако выявленные нерешенные проблемы и области высокого риска должны быть рассмотрены при последующем проектировании.
Литература:
Software Design for
Real-time Systems. J. E. Cooling, Chapman и Hall, 1991.
C.2.1.3 JSD - метод разработки системы по Джексону
Цель: разработка метода, охватывающего создание программных систем от стадии формирования требований до стадии кодирования, специально для систем реального времени.
Описание: метод JSD представляет собой поэтапную процедуру разработки, в которой разработчик моделирует поведение реального мира, на котором основываются функции системы, определяет эти функции, вводит
их в модель и преобразует образовавшуюся в результате спецификацию в одну из надежно действующих в заданной окружающей среде. Поэтому данный метод охватывает традиционные этапы, такие как создание спецификаций, проектирование и разработка, но несколько отличается от традиционных методов и не является методом нисходящего проектирования.
Данный метод уделяет большое внимание выявлению на ранней стадии сущностей реального мира, относящихся к создаваемой системе, а также моделированию этих сущностей и того, что может с ними произойти. Как
только анализ «реального мира» будет выполнен и создана его модель, анализируются функции системы с тем, чтобы определить, как они вписываются в модель «реального мира». Модель результирующей системы дополняется структурным описанием всех процессов модели и затем преобразуется в программы, которые могут работать в заданной программно-аппаратной среде.
Литература:
An Overview JSD. J. R.
Cameron. IEEE Transactions on Software Engineering, SE-12, No. 2, February
1986.
System Development. M.
Jackson, Prentice-Hall, 1983.
C.2.1.4 MASCOT - модульный метод построения, эксплуатации и тестирования программных средств
Цель: проектирование и реализация систем реального времени.
Описание: MASCOT представляет собой модульный метод проектирования, который поддерживается программно. Данный метод описывает структуры систем реального времени способом, не зависящим от типа аппаратных средств или языка реализации. MASCOT высокоорганизованно реализует проектирование, что порождает строго модульную структуру, обеспечивая близкое соответствие между функциональными элементами проекта
и элементами конструкции, появляющимися при интеграции системы. Система представляется в терминах сети
конкурирующих процессов, которые взаимодействуют через каналы. Каналами могут быть либо совокупности файлов, либо очереди (конвейеры) данных. Управление доступом к каналу описывается независимо от процессов в
терминах механизмов доступа, которые также активизируют правила планирования процессов. Последняя версия MASCOT была спроектирована с учетом реализации языка программирования ADA.
MASCOT обеспечивает стратегию приемлемости, основанную на тестировании и верификации как отдельных программных модулей, так и более крупных совокупностей функционально взаимосвязанных программных
модулей. Реализация MASCOT ориентирована на ядро MASCOT - набор примитивов планирования, которые
лежат в основе реализации и обеспечивают механизмы доступа.
Литература:
MASCOT 3 User Guide MASCOT
Users Forum. RSRE, Malvern, England, 1987.
C.2.1.5 Метод Йордона (Yourdon) для систем реального времени
Цель: спецификация и проектирование систем реального времени.
Описание: данный метод реализует процесс разработки системы, состоящий из трех этапов. На первом
этапе происходит создание «сущностной модели», которая описывает поведение системы в целом. На втором
этапе строится модель реализации, описывающая структуру и механизмы, которые, будучи реализованными, отражают требуемое поведение системы. На третьем этапе происходит фактическое построение аппаратных и
программных средств системы. Три этапа строго соответствуют традиционным спецификации, проектированию и
разработке, но главное, что разработчик на каждом этапе должен активно заниматься моделированием.
Сущностная модель состоит из двух частей:
-
модели окружающей среды, содержащей описание границ между системой и ее окружением, а также
внешних событий, на которые должна реагировать система;
-
модели поведения, которая содержит схемы, описывающие преобразования, выполняемые системой в
ответ на события, и описание данных, которые система должна содержать для выдачи ответов.
Модель реализации подразделяется на две подмодели, описывающие распределение отдельных процессов в процессорах и декомпозицию процессов на программные модули.
Для создания сущностной модели и модели реализации данный метод использует множество хорошо
известных подходов: построение диаграмм потоков данных, преобразование графов, структурированный английский язык, диаграммы переходов состояний и сети Петри. Кроме того, данный метод обеспечивает средства
моделирования предложенного проекта системы в письменном или механическом виде из отображенных моделей.
Литература:
Structured Development for
Real-Time Systems (3 Volumes). P. T. Ward and S. J. Mellor. Yourdon Press,
1985.
Strategies for Real-time
System Specification. D. Hatley, E. Pirbhai, Dorset Publishing House, 1988.
C.2.1.6 SADT - методология структурного анализа и проектирования
Цель: моделирование и анализ на уровне информационных потоков процессов принятия решений и задач
управления в сложных системах, представленных в виде диаграмм.
Описание: в методологии SADT концепция активностных диаграмм играет главную роль. Активностная диаграмма состоит из активностей, сгруппированных в так называемые «блоки действий». Каждому блоку действий
присваивается простое имя, и он связывается отношениями (изображаются стрелками) с другими блоками действий, которым также присваиваются уникальные имена. Каждый блок действий может быть иерархически декомпозирован на блоки действий более низкого уровня и отношения между ними. Каждая из четырех сторон блока
действий имеет определенное в методологии SADT особое назначение: входы, управления, механизмы и выходы:
-
вход - указывается стрелкой, входящей в блок действий слева. Входы могут быть представлены материальными или нематериальными объектами и предназначены для обработки одним или несколькими блоками
действий;
-
управление - обычно это инструкция, процедура, критерий выбора и т. п. Управление реализует выполнение действий и изображается стрелками сверху блока действий;
-
механизм - ресурс в виде персонала, организационного подразделения или описания, необходимый к
действию для выполнения своих задач;
-
выход - все, что вырабатывается в результате действия; изображается стрелкой с правой стороны блока
действий.
Если действия связаны между собой большим числом отношений, то лучше объединить эти действия в
единую группу, поместить в один блок действий, не детализируя в дальнейшем его содержание. Основополагающий принцип группирования действий в блоки действий состоит в том, что образуемые в результате блоки действий должны соединяться между собой только небольшим числом отношений.
Декомпозиция моделей активностных диаграмм реализуется до тех пор, пока не потеряет смысл дальнейшая детализация блоков действий. Этот этап достигается, если действия внутри блоков становятся неразделимыми или если последующая детализация действий внутри блоков выходит за область анализа системы.
Литература:
Structured Analysis for
Requirements Definition. D. T. Ross, K. E. Schoman Jr. IEEE Transactions on
Software Engineering, Vol. SE-3, 1, 6-15, 1977.
Structured Analysis (SA): A
Language for Communicating Ideas. D. T. Ross. IEEE Transactions on Software
Engineering, Vol. SE-3, 1, 16-34, 1977.
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.
C.2.2 Диаграммы потоков данных
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.5 и В.7).
Цель: программная поддержка описания потока данных в виде диаграмм.
Описание: диаграммы потоков данных описывают преобразование входных данных в выходные для каждого компонента схемы, представляющего различные преобразования. Диаграммы потоков данных состоят из трех компонентов:
-
аннотированные стрелки - обозначают поток данных, входящих и исходящих из блоков преобразования
с кратким описанием этих данных;
-
аннотированные кружки - обозначают блоки преобразования с кратким описанием преобразований;
-
операторы (and, xor) - эти операторы используются для связи аннотированных стрелок.
Каждый аннотированный кружок на диаграмме потока данных может рассматриваться как самостоятельный блок, который при появлении на его входах данных преобразует их в выходные. Одним из основных преимуществ является то, что они показывают преобразования, не предполагая, как они реализуются. Чистая диаграмма
потоков данных не включает в себя управляющую информацию или информацию о последовательности процесса, так как управление реализуется в расширениях для реального времени, как в методе Йордона для систем
реального времени (см. С.2.1.5).
Создание диаграмм потока данных является наилучшим подходом при анализе систем в направлении от
входов к выходам. Каждый кружок на диаграмме должен обозначать разное преобразование - его выходы
должны отличаться от его входов. Не существует правил определения общей структуры диаграммы, и создание
диаграммы потока данных является одним из творческих аспектов создания проекта системы в целом. Подобно
всем проектам, процедура, уточняющая начальную диаграмму для создания конечной, является итеративной [20],
[22].
Литература:
Software Engineering. I.
Sommerville, Addison-Wesley, 3rd Edition, 1989.
C.2.3 Структурные диаграммы
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.5).
Цель: представление структуры программы в виде схемы.
Описание: структурные диаграммы дополняют диаграммы потоков данных. Они описывают программируемую систему и иерархию ее компонентов, а также отображают их графически в виде дерева. Структурные диаграммы описывают способ реализации элементов диаграммы потоков данных в виде иерархии программных
модулей.
Структурная диаграмма показывает взаимоотношения между программными модулями, не указывая при
этом порядок активизации программных модулей. Структурные диаграммы изображаются с использованием
следующих четырех символов:
-
прямоугольника с именем модуля;
-
линии, соединяющей эти прямоугольники, формирующие структуру;
-
стрелки, отмеченной незаштрихованным кругом, с именем данных, передаваемых в направлении элементов структурной диаграммы и обратно (обычно такая стрелка изображается параллельно линиям, соединяющим
прямоугольники схемы);
-
стрелки, отмеченной заштрихованным кругом, с именем сигнала управления, проходящего в структурной
диаграмме от одного модуля к другому, и эта стрелка также изображается параллельно линии, соединяющей два
модуля.
Из любой нетривиальной диаграммы потока данных можно создать множество различных структурных
диаграмм.
Диаграммы потоков данных отображают взаимоотношение между информацией и функциями системы. Структурные диаграммы отображают способ реализации элементов системы. Оба метода представляют собой
действующие, хотя и различные точки зрения на конкретную систему.
Литература:
Software Engineering. I.
Sommerville, Addison-Wesley, 3rd Edition, 1989.
Structured Design. L. L.
Constantine and E. Yourdon, Englewood Cliffs, New Jersey, Prentice Hall, 1979.
Reliable Software Through Composite
Design. G. J. Myers, New York, Van Nostrand, 1975.
C.2.4 Формальные методы
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.1, А.2, А.4 и В.5).
С.2.4.1 Общие положения
Цель: разработка программных средств, основанных на математических принципах. К этим средствам относятся методы формального проектирования и формального кодирования.
Описание: на основе формальных методов разработаны средства описания системы для решения отдельных задач на этапах спецификации, проектирования или реализации. Создаваемое в результате описание представляет собой строгую нотацию, математически анализируемую для обнаружения различных видов несогласованностей или некорректностей. Более того, такое описание может быть в некоторых случаях проанализировано
автоматически по аналогии с проверкой компилятором синтаксиса исходной программы или, с целью показать
различные аспекты поведения описываемой системы, использована анимация. Анимация может дать дополнительную уверенность в том, что система соответствует как реальным, так и формально специфицированным
требованиям, поскольку это улучшает восприятие человеком специфицированного поведения системы.
Формальный метод обычно предлагает нотацию (как правило, используется один из методов дискретной
математики), метод вывода описания в данной нотации и различные методы анализа описания для проверки
корректности различных свойств системы.
Примечание - Приведенное выше описание содержится также в В.2.2.
Ряд формальных методов CCS, CSP, HOL, LOTOS, OBJ, временная логика, VDM и Z описан в подпунктах
настоящего пункта. Следует заметить, что другие методы, например метод конечных автоматов (см. В.2.3.2) и сети
Петри (см. В.2.3.3), в зависимости от корректности использования методами соответствующего строгого математического аппарата, могут рассматриваться как формальные.
Литература:
The Practice of Formal
Methods In Safety-Critical Systems. S. Liu, V. Stavridou, B. Dutertre, J.
Systems. Software 28, 77-87, Elsevier, 1995.
Formal Methods: Use and
Relevance for Development of Safety-Critical Systems. L. M. Barroca, J. A.
McDermid, The Computer Journal 35 (6), 579-599, 1992.
How to Produce Correct
Software - An Introduction to Formal Specification and Program Development by
Transformations. E. A. Boiten et al, The Computer Journal 35 (6), 547-554, 1992.
C.2.4.2 CCS - расчет взаимодействующих систем
Цель: описание и анализ поведения систем, реализующих параллельные коммуникационные процессы.
Описание: CCS - это математический аппарат, описывающий поведение систем. Проект системы моделируется в виде сети независимых процессов, реализующихся последовательно или параллельно. Процессы могут
взаимодействовать через порты (аналогичные каналам CSP), и взаимодействие осуществляется только при готовности обоих процессов. Отсутствие детерминизма может быть смоделировано. Начиная с описания всей
системы на высоком уровне абстрагирования (трассирование), можно выполнять пошаговое уточнение системы
(стратегия сверху вниз) в рамках композиции взаимодействующих процессов, общее поведение которых формирует также поведение всей системы. В равной степени можно выполнять и стратегию снизу вверх, комбинируя
процессы и получая в результате необходимые свойства формируемой системы, используя правила вывода
композиционного типа.
Литература:
Communication and
Concurrency. R. Milner, Prentice-Hall, 1989.
The Specification of
Complex Systems. B. Cohen, W. T. Harwood and M. I. Jackson, Addison Wesley,
1986.
C.2.4.3 CSP - взаимодействующие последовательные процессы
Цель: спецификация конкурирующих программных систем, то есть систем, процессы которых реализуются
одновременно.
Описание: метод CSP обеспечивает язык для системных спецификаций процессов и подтверждения соответствия реализации процессов их спецификациям (описанным как «трасса
- допустимая последовательность событий»).
Система моделируется в виде сети независимых процессов, составленных последовательно или параллельно. Каждый независимый процесс описывается в терминах всех его возможных поведений. Независимые
процессы могут взаимодействовать (синхронно или обмениваться данными) через каналы, и взаимодействие
происходит только при готовности обоих процессов. Может быть промоделирована относительная синхронизация событий.
Теоретические положения метода CSP были непосредственно включены в архитектуру транспьютера INMOS, а язык OCCAM позволил непосредственно реализовывать на сетях транспьютеров системы, специфицированные в языке CSP.
Литература:
Communicating Sequential
Processes. С A. R. Hoare, Prentice-Hall, 1985.
С.2.4.4 HOL - логика высшего порядка
Цель: спецификация и верификация аппаратных средств.
Описание: HOL представляет собой разработанную в компьютерной лаборатории Кембриджского университета конкретную логическую нотацию и систему, которая ее автоматически поддерживает. Логическая нотация
взята в основном из простой теории типов Черча, а машинная реализация основана на теории LCF (логике вычислимых функции).
Литература:
HOL: A Machine Orientated
Formulation of Higher Order Logic. M. Gordon, University of Cambridge Technical
Report, No. 68, 1985.
Specification and
Verification Using Higher-Order Logic: A Case Study, F. K. Hanna and N. Daeche,
in: Formal Aspects of VLSI Design: Proceedings of 1985 Edinburgh Workshop on
VLSI, pp. 179 - 213, G. Milne and P. A. Subrahmanyam (Eds.), North Holland, 1986.
Application of formal
methods to VIPER microprocessor. W. J. Cullyer, С H. Pygott, Proc. IEEE 134, 133 - 141, 1987.
C.2.4.5 LOTOS
Цель: описание и анализ поведения систем, реализующих параллельные коммуникационные процессы.
Описание: LOTOS (язык для спецификации процессов, упорядоченных во времени) основан на CCS с
дополнительными возможностями из близких алгебраических теорий CSP и CIRCAL (теория цепей). LOTOS преодолевает недостатки CCS в управлении структурами данных и представлении значений выражений, объединяя его со вторым компонентом, основанным на языке абстрактных типов данных ACT ONE. Процесс описания
компонентов в LOTOS может быть также использован для других формальных методов при описании абстрактных типов данных [24].
С.2.4.6 OBJ
Цель: обеспечение точной спецификации системы в процессе диалога с пользователем и подтверждение
соответствия системы до ее реализации.
Описание: OBJ представляет собой алгебраический язык спецификаций. Пользователи определяют требования в терминах алгебраических выражений. Системные аспекты (поведение или конструктивы) специфицируются в терминах операций, действующих над абстрактными типами данных (ADT). ADT подобен языку ADA, где
поведение оператора наблюдаемо, однако подробности реализации скрыты.
Спецификация OBJ и последующая пошаговая реализация подвергаются тем же формальным методам
проверки, что и другие формальные методы. Более того, поскольку конструктивные аспекты спецификации OBJ автоматически исполнимы, существует непосредственная возможность подтверждения соответствия системы на
основе самой спецификации. Исполнение - это по существу оценка функций системы путем подстановки выражений (перезаписыванием), которая продолжается до тех пор, пока не будут получены конкретные выходные
значения. Эта исполнимость позволяет конечным пользователям рассматриваемой системы получать «облик»
планируемой системы на этапе ее спецификации без необходимости знакомства с методами, лежащими в основе формальных спецификаций.
Как и все другие методы ADT, метод OBJ применим только к последовательным системам или к последовательным аспектам параллельных систем. Метод OBJ применяют для спецификации как малых, так и крупных
промышленных приложений.
Литература:
An Introduction to OBJ: A
language for Writing and Testing Specifications. J. A. Goguen and J. Tardo,
Specification of Reliable Software, IEEE Press 1979, reprinted in Software
Specification Techniques, N. Gehani, A. McGrettrick (eds), Addison-Wesley,
1985.
Algebraic Specification for
Practical Software Production. С Rattray,
Cogan Press, 1987.
An Algebraic Approach to
the Standardisation and Certification of Graphics Software. R. Gnatz, Computer
Graphics Forum 2 (2/3), 1983.
C.2.4.7
Временная логика
Цель: непосредственное выражение требований к безопасности и эксплуатации, а также формальное представление сохранения этих качеств на последующих этапах разработки.
Описание: стандартная предикатная логика первого порядка не содержит концепций
времени. Временная логика расширяет логику первого порядка добавлением модальных операторов (например, «с этого момента» и
«случайно»). Эти операторы могут использоваться для уточнения суждений о системе. Например, свойства безопасности могут потребовать использовать модальный оператор «с этого момента», но может потребоваться, чтобы и другие необходимые состояния системы были достигнуты «случайно» из некоторого другого начального
состояния. Временные формулы интерпретируются последовательностями состояний (поведениями). Представление состояния зависит от выбранного уровня описания. Оно может относиться ко всей системе, системным
компонентам или компьютерной программе.
Квантифицированные временные интервалы и ограничения во временной логике не обрабатываются явно. Абсолютное время обрабатывается путем образования дополнительных временных состояний, что является
частью описания состояния.
Литература:
Temporal Logic of Programs.
F. Kroger. EATCS Monographs on Computer Science, Vol. 8, Springer Verlag, 1987.
Design for Safety using
Temporal Logic. J. Gorski. SAFECOMP 86, Sarlat, France, Pergamon Press, October
1986.
The Temporal Logic of
Programs. A. Pnueli, 18th Annual Symposium on Foundations of Computer Science,
IEEE, 1977.
Verifying Concurrent
Processes Using Temporal Logic, Hailpern, T. Brent, Springer Verlag, 1981.
C.2.4.8
VDM, VDM++ - метод разработки Vienna
Цель: систематическая спецификация и реализация последовательных (VDM) и параллельных (VDM++) программ реального времени.
Описание: VDM - это математический метод спецификации и уточнения реализаций, который позволяет
доказать их корректность относительно спецификации.
В этом основанном на модели методе спецификации состояние системы моделируется в терминах теоретико-множественных структур, в которых описаны инварианты (предикаты), а операции над этим состоянием
моделируются путем определения их пред- и пост- условий в терминах системных состояний [29].
Операции могут
проверяться на сохранение системных инвариантов.
Выполнение спецификаций осуществляется путем реализации состояния системы в терминах структур
данных в заданном языке и уточнения операций в терминах программы на заданном языке. Этапы реализации
и уточнения позволяют логически вывести свойства, устанавливающие корректность этих этапов. Выполняются
или нет эти свойства, определяет разработчик.
В принципе VDM используется на этапе создания спецификации, но может также использоваться на этапах
проектирования и реализации исходного кода. VDM может быть также применен к последовательно структурированным программам или к последовательным процессам в параллельных системах.
Объектно-ориентированное и параллельное для реального времени расширения VDM, VDM++ представляют собой язык формализованных спецификаций, основанный на языке VDM-SL, созданном в ИСО, и на объектно-ориентированном языке Smalltalk.
VDM++ имеет широкий диапазон конструкций, что позволяет пользователю формально специфицировать
параллельные системы реального времени в объектно-ориентированной среде. В VDM++ полная формальная
спецификация содержит совокупность спецификаций классов и отдельных характеристик рабочего пространства.
К средствам описания реального времени на языке VDM++ относятся:
-
временные выражения, предусмотренные для представления, как текущего момента, так и момента вызова метода внутри тела метода;
-
выражение, описывающее синхронизирующий сигнал, которое может быть добавлено к методу для спецификации верхних (или нижних) пределов времени исполнения для корректности реализаций;
-
переменные непрерывного времени, которые должны быть введены. С условными операторами и операторами действия допускается специфицировать отношения (например, дифференциальные уравнения) между
этими временными функциями, что оказалось очень полезно при спецификации требований к системам, действующим в среде с непрерывным временем. Уточняющие шаги приводят к дискретным программным решениям для
программ реального времени.
Литература:
Conformity Clause for
VDM-SL, G. I. Parkin and B. A. Wichmann, Lecture Notes in Computer Science 670,
FME' 93 Industrial-Strength Formal Methods, First International Symposium of
Formal Methods in Europe. Editors: J. С Р. Woodcock and P. G. Larsen. Springer Verlag,
501-520.
Major VDM+ - Language
characteristics: http://www.ifad.dk/products/vdmlangchar.html
Systematic Software
Development using VDM. С. В. Jones. Prentice-Hall. 2nd Edition, 1990.
Software Development - A
Rigorous Approach. С. В. Jones. Prentice-Hall, 1980.
Formal Specification and
Software Development. D. Bjorner and С. В. Jones, Prentice-Hall, 1982.
The Specification of
Complex Systems. B. Cohen, W. T. Harwood and M. I. Jackson. Addison Wesley,
1986.
C.2.4.9 Z
Цель: Z - это нотация языка спецификаций для последовательных систем и метод проектирования, позволяющий разработчику выполнять работу, начиная со спецификации на языке Z до исполнительных алгоритмов, обеспечивая при этом доказательство их корректности по отношению к спецификации.
Язык Z в принципе используется на этапе спецификации, однако данный язык был разработан для использования от этапа составления спецификации до проектирования и реализации систем. Более всего он подходит
для разработки последовательных систем, ориентированных на данные.
Описание: как и в VDM, в методе спецификации, реализованном в языке Z, состояние системы моделируется в терминах теоретико-множественных структур, в которых описаны инварианты (предикаты), а операции над
этим состоянием моделируются путем определения их пред- и пост- условий в терминах системных состояний. Операции допускается проверять на сохранение системных инвариантов для демонстрации их согласованности. Формальная часть спецификации подразделяется на схемы, которые обеспечивают возможность структурирования спецификаций путем их усовершенствования.
Обычно спецификация Z представляет собой сочетание формального текста на языке Z и неформального
пояснительного текста на естественном языке. Формальный текст сам по себе может оказаться слишком сжатым
для простого восприятия и часто его смысл необходимо пояснять, тогда как неформальный, естественный язык
может оказаться неоднозначным и неточным.
В отличие от VDM язык Z представляет собой скорее нотацию, чем завершенный метод. Однако был разработан близкий метод (метод В), который может быть использован в сочетании с языком Z. Метод В основан на
принципе пошагового уточнения.
Литература:
The Z Notation - A Reference Manual. J. M.
Spivey. Prentice-Hall, 1992. Specification Case Studies. Edited by I. Hayes,
Prentice-Hall, 1987.
The В Method. J. R. Abrial et al, VDM '91 Formal
Software Development Methods, (S. Prehen и W. J. Toetenel, eds), Springer Verlag, 398 - 405, 1991.
Specification of the UNIX
Filestore. С Morgan and B. Sufrin. IEEE Transactions on
Software Engineering, SE-10, 2, March 1984.
C.2.5
Программирование с защитой
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.4).
Цель: создание программ, выявляющих во время их исполнения аномальные потоки управления, данных
или значения данных и реагирующих на них заранее определенным и приемлемым способом.
Описание: в процессе разработки программ допускается использовать разные методы для проверки аномалий в потоках управления или данных. Эти методы могут применяться систематически в процессе программирования системы для снижения вероятности ошибочной обработки данных.
Существуют два пересекающихся множества методов защиты. Внутренние методы защиты от ошибок проектируются в программных средствах для преодоления недостатков в процессе создания этих программных средств. Эти недостатки могут быть обусловлены ошибками при проектировании или кодировании, либо ошибочными
требованиями. Ниже перечислены некоторые из рекомендаций по защите:
-
проверка диапазона значений переменных;
-
проверка значений переменных на их достоверность (если возможно);
- проверка типа, размерности и диапазона значений параметров процедур на входе процедур.
Представленные три рекомендации помогают гарантировать допустимость значений, обрабатываемых в
программах, как с точки зрения терминов программных функций, так и физических значений переменных.
Параметры «только для чтения» и параметры «для чтения-записи» должны быть разделены, и доступ к ним
должен проверяться. Программные функции должны рассматривать все параметры в качестве параметров «только
для чтения». Символьные константы не должны быть доступны для записи. Это помогает обнаруживать случайные перезаписи или ошибочное использование переменных.
Устойчивые к ошибкам программные средства проектируются в «предположении», что ошибки существуют в
самой программной среде, либо используются выходящие за номиналы значения условий или используются
предполагаемые условия, но программные средства ведут себя заранее определенным способом. В этом случае
применяют следующие проверки:
-
проверку на достоверность физических значений входных и промежуточных переменных;
-
проверку влияния выходных переменных, предпочтительно путем прямого наблюдения соответствующих
изменений состояния системы;
-
проверку самими программными средствами своей конфигурации, включая наличие и доступность предполагаемых аппаратных средств, а также завершенность самих программ, что особенно важно для поддержки
полноты безопасности в процессе их эксплуатации.
Некоторые из методов защиты программ, например проверки последовательности потока управления, также справляются и с внешними ошибками.
Литература:
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN
1-85166-203-0.
Dependability of Critical
Computer Systems 2. F. J. Redmill, Elsevier Applied Science, 1989, ISBN
1-85166-381-9.
Software Engineering
Aspects of Real-time Programming Concepts. E. Schoitsch, Computer Physics
Communications 41, North Holland, Amsterdam, 1986.
C.2.6 Стандарты по проектированию и кодированию
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.4).
С.2.6.1
Общие положения
Цель: упрощение верификации, с тем чтобы поддержать групповой объективный подход и установить стандартный метод проектирования.
Описание: в самом начале между участниками проекта должны быть согласованы необходимые правила, охватывающие рассмотренные ниже методы проектирования и разработки (например, JSP, MASCOT, сети Петри, и т.д.), а также соответствующие стандарты кодирования (см. С.2.6.2).
Данные правила создаются для облегчения разработки, верификации, оценки и эксплуатации. При этом
должны учитываться доступные инструментальные средства, в частности, для аналитиков и развитие средств
проектирования [4].
Литература:
Dependability of Critical
Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988. ISBN
1-85166-203-0.
Verein Deutscher
Ingenieure. Software-Zuverlassigkeit - Grundlagen, Konstruktive Mass-nahmen,
Nach-weisverfahren. VDI-Verlag, 1993, ISBN 3-18-401185-2.
С.2.6.2 Стандарты кодирования
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.1).
Цель: упростить верификацию разработанного кода.
Описание: до выполнения кодирования должны быть согласованы подробные правила, которых следует
придерживаться. К таким правилам обычно относят:
-
иметь подробные сведения о модульности, например о виде интерфейса, размерах программных модулей;
-
использовать инкапсуляцию, наследование (ограниченное по глубине) и полиморфизм в случае объектно-ориентированных языков;
-
исключать или использовать ограниченно некоторые языковые конструкции, например «goto», «equivalence», динамические объекты, динамические данные, структуры динамических данных, рекурсию, указатели и т. п.;
-
ограничивать прерывания, допустимые при выполнении критичного для безопасности кода;
-
распечатывать программный код (формировать листинг);
- исключать безусловные переходы (например «goto») в программах на языках высокого уровня.
Данные правила созданы для облегчения процессов тестирования программных модулей, верификации, оценки и обслуживания. При этом должны учитываться доступные инструментальные средства, в частности, для
аналитиков.
Примечание - Более подробная информация по этим правилам приведена в С.2.6.3 -
С.2.6.7
С.2.6.3 Отказ от динамических переменных или динамических объектов
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.1).
Цель: исключить:
-
нежелательные или необнаруживаемые наложения в памяти;
-
узкие места ресурсов в процессе (связанном с безопасностью) выполнения программы.
Описание: в случае применения этого метода динамические переменные и динамические объекты получают определяемые во время выполнения программы определенные и абсолютные адреса в памяти. Объем
(размер) распределяемой памяти и ее адреса зависят от состояния системы в момент распределения памяти и
не могут быть проверены компилятором или другим автономным инструментом.
Так как число динамических переменных и объектов и существующее свободное пространство памяти для
размещения новых динамических переменных или объектов зависит от состояния системы в момент их размещения, то при размещении или при использовании переменных или объектов возможны сбои. Например, если
объем свободной памяти, распределяемый системой, недостаточен, то содержимое памяти другой переменной
может быть неумышленно стерто. Если динамические переменные или объекты не используются, то появление
этих ошибок исключено.
С.2.6.4
Проверка создания динамических переменных или динамических объектов при
выполнении программы
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.1).
Цель: убедиться в том, что память, в которой должны быть размещены динамические переменные и объекты, свободна до ее загрузки, а размещение в ней динамических переменных и объектов во время выполнения
программы не повлияет на уже существующие в ней переменные, данные или коды.
Описание: в случае применения этих средств к динамическим переменным относят те переменные, которые имеют свои конкретные и абсолютные адреса в памяти, устанавливаемые во время выполнения программы
(в этом смысле динамические переменные являются также атрибутами экземпляров объектов).
Аппаратными либо программными средствами память проверяется на то, что она свободна до размещения в ней динамических переменных или объектов (например, для того, чтобы исключить переполнение стека). Если размещение не разрешается (например, если памяти по конкретному адресу недостаточно), должны быть
предприняты соответствующие действия. После использования динамических переменных или объектов (например, после выхода из подпрограммы) вся используемая ими память должна быть освобождена.
Примечание - Альтернативным методом является демонстрация статического распределения памяти.
С.2.6.5
Ограниченное использование прерываний
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.1).
Цель: сохранение верифицируемости и тестируемости программного обеспечения.
Описание: использование прерываний должно быть ограничено. Прерывания могут использоваться, если
они упрощают систему. Использование программных средств для обработки прерываний должно быть запрещено в критических ситуациях для выполняемых функций (например, критичность по времени, критичность изменений данных). Если прерывания используются, то непрерываемые фрагменты должны иметь специфицированное максимальное время вычисления с тем, чтобы можно было вычислить максимальное время, в течение которого прерывание запрещено. Использование прерываний и их маскирование должны подробно документироваться.
С.2.6.6 Ограниченное использование указателей
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.1).
Цель: исключение проблем, связанных с доступом к данным без предварительной проверки типа и диапазона указателя. Обеспечение модульного тестирования и верификации программных средств. Ограничение последствия отказов.
Описание: в прикладных программных средствах указатель арифметических операций может быть использован на уровне исходного кода только в случае, если тип и диапазон значений указателя данных (для гарантии
того, что ссылка указателя находится внутри корректного адресного пространства) будут проверены перед доступом. Связи между задачами в прикладных программах не должны осуществляться с помощью непосредственных
ссылок между задачами. Обмен данными должен осуществляться через операционную систему.
С.2.6.7 Ограниченное использование рекурсий
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.1).
Цель: исключение неверифицируемого и нетестируемого использования вызовов подпрограмм.
Описание: если используется рекурсия, то должен быть определен четкий критерий, который делает глубину
рекурсии предсказуемой.
С.2.7 Структурное программирование
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.4).
Цель: проектирование и реализация программы с использованием практического анализа программы без
ее выполнения. Программа может содержать только абсолютный минимум статистически нетестируемого поведения.
Описание: для минимизации структурной сложности программы следует применять следующие принципы:
-
разделять программу на подходящие небольшие минимально связанные программные модули, все взаимодействия между которыми точно специфицированы;
-
составлять поток управления программными модулями с использованием таких структурированных конструкций, как последовательности, итерации и выбор;
-
обеспечивать небольшое число возможных путей через программные модули и возможно более простые
отношения между входными и выходными параметрами;
-
исключать сложные ветвления и, в частности, безусловные переходы (goto) при использовании языков
высокого уровня;
-
по возможности, связывать ограничения цикла и ветвление с входными параметрами;
-
исключать использование сложных вычислений в ветвлении и цикле.
Свойства языков программирования, которые способствуют указанному выше методу, следует использовать, предпочитая их другим свойствам, которые (как утверждают) более эффективны, за исключением случаев, когда эффективность приобретает абсолютный приоритет (например, некоторые критичные к безопасности системы).
Литература:
Notes on stuctured
programming. E. W. Dijkstra, Stuctured Programming, Academic Press, London,
1972, ISBN 0-12-200550-3.
A Discipline of
Programming. E. W. Dijkstra. Englewood Cliffs NJ, Prentice-Hall, 1976.
A Software Tool for
Top-down Programming. D. С Ince. Software - Practice and Experience, Vol. 13, No. 8, August
1983.
Verification - The Practical Problems. J.
T. Webb and D. J. Mannering, SARSS 87, Nov. 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.
C.2.8 Ограничение доступа/инкапсуляция информации
Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.9).
Цель: предотвращение непреднамеренного доступа к данным или процедурам и обеспечение тем самым
качественной структуры программных средств.
Описание: общедоступные для всех программных компонентов данные могут быть случайно или некорректно модифицированы любым из этих компонентов. Любые изменения этих структур данных могут потребовать
подробной проверки программного кода и серьезных исправлений.
Ограничение доступа представляет собой общий метод к минимизации указанных выше проблем. Ключевые структуры данных «скрыты», и с ними можно работать только через конкретный набор процедур доступа, это
позволяет модифицировать внутренние структуры данных или добавлять новые процедуры и при этом не оказывать влияния на функциональное поведение остальных программных средств. Например, имя директории может
иметь процедуры доступа «вставить», «удалить» и «найти». Процедуры доступа и структуры внутренних данных
могут быть изменены (например, при использовании различных методов просмотра или запоминании имен на
жестком диске), не оказывая влияния на логическое поведение остальных программных средств, использующих
эти процедуры.
В данном случае следует использовать концепцию абстрактных типов данных. Если непосредственная проверка не предусмотрена, может оказаться необходимым проверить, не было ли абстрагирование случайно разрушено.
Литература:
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).
Цель: повышение вероятности выполнения программой, в конечном счете, своих заданных функций.
Описание: некоторые различные разделы программы, которые часто пишутся независимо, предназначены
для выполнения одной требуемой функции. Из таких разделов конструируется окончательная программа. Сначала выполняется первый раздел, называемый первичным. Далее происходит тестирование его результатов. Если
проверка проходит успешно, результат принимается и передается следующим разделам