суббота, 27 мая 2017 г.

Онлайн курс «Функциональная безопасность компьютерных систем»

источник

Вашему вниманию предлагается статья о том, как был создан онлайн курс по тематике «Функциональная безопасность». Сервисы онлайн обучения располагают студийным оборудованием для записи высококачественного звука и видео. А если вдруг представить, что доступа у вас к подобным ресурсам нет, а учебный материал надо подготовить для использования в онлайн режиме? Автор решил поделиться собственным опытом и раскрыть следующие вопросы:
- мотивация или зачем и кому это надо;
- инструменты подготовки и записи;
- содержание Massive Online Open Course (MOOC) по функциональной безопасности;
- дальнейшие шаги по развитию продукта.

Мотивация: зачем это делалось?

Будучи вовлеченным в образовательный процесс, пришлось решать задачу дистанционного обучения студентов направления «Кибербезопасность» на кафедре компьютерных систем и сетей Национального аэрокосмического университета «Харьковский авиационный институт». Дистанционность эта образовалась по причине моей географической удаленности.

Были и другие мотиваторы. Хотелось попробовать силы в новой для меня технологии преподавания, и посмотреть, как это работает.

Еще была задача подготовить консалтинговые материалы для коллег из индустрии, с которыми приходится обсуждать вопросы сертификации. Порог входа «с нуля» в эту тематику порой оказывается достаточно высоким, а, просмотрев материалы, можно приобрести достаточный уровень знаний, чтобы начать работать в проекте по сертификации. Поэтому, изначально ставилась цель сделать курс проблемно-ориентированным, то есть направленным на решение практической задачи: подготовка к сертификации на соответствие требованиям МЭК 61508 (либо других подобных стандартов по функциональной безопасности).

Таким образом, слушатели курса получили весь набор преимуществ пользователей MOOC: слушаем небольшими информационными блоками, изучаем в удобное время, если что-то не поняли или пропустили, то «прокручиваем» повторно и т.п. Очень подходит для студентов старших курсов, которые уже хотят решить вопрос с трудоустройством, и объясняют этим пропуск занятий.

В предметной области ориентир был сделан, в первую очередь, на АСУ ТП, но затрагивались и другие архитектуры систем управления: встроенные системы, интернет вещей и промышленный интернет вещей (Industrial IoT or Industrial Internet Control Systems).

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

Еще одна особенность видеолекций состояла в том, что слайды представлены на английском, а аудио записано на русском языке. Предполагаю, что части аудитории может не понравиться подобный «тяни-толкай», но все же попытаюсь объяснить, что с переводом специфической терминологии на русский язык не все обстоит гладко. Смотрим, например, терминологию из МЭК 61508, часть 4. Validation (3.8.2) переводится как «подтверждение соответствия», и это не единственный пример.

Подготовка и запись курса

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

Затем был проведен обзор доступных (на начало 2017 года) ресурсов в сети, которые бы частично или полностью соответствовали тому, что планировалось сделать. Оказалось, что курсов в формате MOOC, посвященных ФБ, не существует, хотя по ИБ, например, их множество. Однако, студентам похожие дисциплины читают. Наиболее похожим оказался курс MIT System Safety (преподает профессор Nancy Leveson). Однако, на сайте MIT доступны лишь учебные материалы, поэтому этот курс не являет MOOC в полном смысле слова. Еще один идеологически близкий курс, Software Security Engineering, был обнаружен в программе Software Engineering Institute (SEI), преподает его Nancy Mead. Таким образом, гипотеза об уникальности записываемого материала была подтверждена, то есть, ниша для MOOC по функциональной безопасности оказалась свободна.

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

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

Вводный ролик был записан на видеокамеру в формате HD. Все остальные материалы записывались с демонстрацией слайдов и голосом за кадром, без появления лектора на экране.

Для захвата видео и звука использовалась программа oCam. Никаких хлопот с ее установкой и применением не возникало. Видео записывалось в формате ISO MPEG-4 в целях последующей обработки видеоредактором YouTube. Как оказалось, видеоредактор YouTube еще и несколько улучшает качество нестудийного звука.

Содержание MOOC «Функциональная безопасность компьютерных систем»

Курс включает шесть лекций или, в терминологии MOOC, шесть недель обучения.

Лекции выложены на канале YouTube в виде следующих плейлистов (содержание плейлистов-лекций показано на рисунке 1):
Лекция 1. Введение в функциональную безопасность
Лекция 2. Требования стандарта МЭК 61508
Лекция 3. Управление функциональной безопасностью
Лекция 4. Жизненный цикл функциональной и информационной безопасности
Лекция 5. Оценивание показателей функциональной безопасности
Лекция 6. Методы обеспечения функциональной безопасности



Рисунок 1. Структура MOOC «Функциональная безопасность компьютерных систем»

Самостоятельная работа студентов реализуется по четырем направлениям:
- ответ на контрольные вопросы (quiz);
- чтение рекомендованной литературы;
- при желании – изучение дополнительных материалов, превышающих объем программы;
- и, самое главное, – индивидуальный проект.

Индивидуальный проект является главным результатом изучения курса, где важно не только найти заранее известные ответы на контрольные вопросы, а, прежде всего, необходимо решить прикладную задачу, основанную на получаемых знаниях. Такой задачей является разработка собственного документа, охватывающего оценивание ФБ по направлениям, изучаемым в лекционном материале. Называется этот документ Assurance Case (или «обоснование безопасности» в смысловом, а не в прямом переводе). Разработка Assurance Case применяется в практике оценивания и сертификации ИБ (Security Case) и ФБ (Safety Case). В качестве объектов оценивания предлагаются компоненты АСУ ТП: контроллеры, исполнительные механизмы и датчики. Студентам выдается шаблон Assurance Case, и они его поэтапно заполняют, основываясь на материале каждой из лекции. Структура шаблона показана на Рисунке 2.



Рисунок 2. Структура индивидуального задания (Assurance Case), выполняемого в ходе изучения MOOC «Функциональная безопасность компьютерных систем»

Выводы

Запись MOOC является увлекательным занятием, которое требует серьезных временных инвестиций. У каждого своя скорость проговаривания текста и его написания. Мои оценки говорят о том, что тысячу знаков текста (это полстраницы формата А4 с 14-м шрифтом через полуторный интервал) можно озвучить приблизительно за одну минуту. То есть, например, для подготовки записи получасовой лекции надо написать приблизительно 30 тысяч знаков (15 страниц текста).

Но, зато, этот текст легко скомпоновать в статью. Именно так и появился цикл статей по функциональной безопасности, он разрабатывался параллельно с онлайн курсом.

Судя по обратной связи от студентов, этот формат они восприняли позитивно. Многие статистические исследования в области по MOOC говорят, что на успешность усвоения материала влияет не онлайн / офлайн форма, а, в первую очередь, мотивация студентов. Те, кто хотел, прекрасно справились с индивидуальным заданием.

Работая над курсом, я почувствовал, насколько все-таки медленно возможности технологий осваиваются некоторыми вузами. А реалии таковы, что мало кому удается повлиять на этот процесс. Как говаривал Вильям Гибсон, “the future is already here – it’s just not very evenly distributed”.

Разумеется, что предлагаемый набор плейлистов YouTube пока не может считаться полномасштабным MOOC, и после пилотной версии продукта необходимо выполнить еще ряд действий по доводке, а именно:
- добавить анимационные заставки;
- перенести курс в среду разработки MOOC (рассматривается edX);
- разработать онлайн тесты;
- разместить курс на одной или нескольких платформах онлайн обучения;
- набрать и обучить группу;
- а также, в перспективе, записать англоязычный вариант курса.
Этим и займемся в ближайшее время.

среда, 3 мая 2017 г.

Функциональная безопасность компьютерных систем управления, часть 8. Методы обеспечения информационной и функциональной безопасности


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

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

Набор анализируемых методов базируется на требованиях МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems). В части специфики обеспечения информационной безопасности АСУ ТП за основу взят NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security», рассмотренный в одной из предыдущих статей.

МЭК 61508: Методы и средства обеспечения функциональной безопасности


При выполнении сертификации на соответствие требованиям МЭК 61508 к тому или иному уровню SIL (Safety Integrity Level), важно продемонстрировать,  что, во-первых, в продукт заложен необходимый и достаточный механизм обеспечения функциональной безопасности (ФБ), а, во-вторых, что необходимый и достаточный набор методов обеспечения ФБ применялся в процессе разработки. Исходя из этого, условно разделим методы обеспечения ФБ на технические и организационные.

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

При этом, большинство методов являются комплексными, то есть, один и тот же метод в той или иной мере направлен на защиту и от случайных, и от систематических отказов.
Описание методов обеспечения ФБ содержится в МЭК 61508-7 «Методы и средства». Однако, чтобы разобраться в требованиях к применению того или иного метода, одной только части 7 недостаточно.

В части 2 МЭК 61508, которая посвящена обеспечению ФБ систем и аппаратных средств, и в части 3, содержащей требования к ПО, есть три существенных приложения, которые определяют методы и средства по защите от случайных и систематических отказов. Структура МЭК 61508 такова, что детально методы и средства описаны в части 7. Таким образом, требования к защите от отказов из частей 2 и 3 МЭК 61508 трассируются в описания методов и средств по обеспечению ФБ в части 7. Эта взаимосвязь представлена на Рисунке 1.



Рисунок 1. Структура методов обеспечения безопасности согласно МЭК 61508

Приложение А части 2 МЭК 61508 рассматривает контроль отказов аппаратных средств в ходе эксплуатации, причем подразумевается, что это могут быть как случайные, так и систематические отказы. Детальное описание методов защиты от случайных отказов содержится в Приложении А части 7 МЭК 61508. Методы защиты от случайных отказов разделены на категории, в зависимости от типа рассматриваемых аппаратных средств, например, электрические компоненты, электронные компоненты, процессорные модули, память и т.д.

Приложение В части 2 МЭК 61508 рассматривает методы защиты от систематических отказов аппаратных средств на протяжении жизненного цикла. Следует отметить, что МЭК 61508 рассматривает в качестве источников систематических отказов аппаратных средств ошибки проектирования, ошибки эксплуатации и внешние экстремальные воздействия (климатические, механические, радиационные и другие). Детальное описание соответствующих методов содержится в Приложении В части 7 МЭК 61508. Структура изложения методов защиты от систематических отказов аппаратных средств имеет свои особенности, например, в категорию B.1 General measures and techniques входят такие разные методы, как Project Management, Documentation, Separation, Diversity. Далее методы распределены по этапам жизненного цикла.

Приложение А части 3 МЭК 61508 содержит руководство по выбору методов разработки и тестирования программного обеспечения с целью достижения полноты безопасности. Детальное описание соответствующих методов содержится в приложении С части 7 МЭК 61508. Здесь в категории С.1 General вообще не описываются никакие методы. Далее методы распределены по категориям: требования и детальный дизайн, архитектурный дизайн, инструментальные средства и языки программирования, верификация и модификация, оценивание ФБ.

Чтобы проиллюстрировать изложение вышесказанного в МЭК 61508, рассмотрим простейшую таблицу, которая определяет методы, применяемые для обеспечения функциональной безопасности программного обеспечения на этапе разработки спецификации требований (см. Рисунок 2).



Рисунок 2. МЭК 61508-7, Table A.1 – Software safety requirements specification

Допустим, нас интересует уровень полноты безопасности SIL3. Те методы, которые в графе "SIL3" обозначены, как HR (Highly Recommended), должны обязательно применяться. Во всяком случае, сертифицирующему органу будет практически невозможно объяснить, почему не использовался тот или иной обязательно рекомендованный метод. Методы, обозначенные, как R (Recommended), могут применяться, однако, от них также можно обоснованно отказаться. С Таблицей А1 (SIL3) здесь все достаточно просто. Рекомендуется применение формальных методов, однако, приоритет применения полуформальных методов выше (Highly Recommended). Поэтому, если применяются полуформальные методы, то от формальных можно отказаться. Применение прямой и обратной трассировки также является обязательным (про трассировку требований уже было сказано в предыдущих публикациях). Применение программного обеспечения для поддержки трассировки и разработки спецификации является очевидным.

Как мы уже говорили, методы обеспечения безопасности целесообразно разделить на организационные и технические. Рассмотрим теперь эти две группы.

Организационные методы обеспечения информационной и функциональной безопасности


Фактически организационные меры уже рассматривались в предыдущих публикациях этой серии. К ним относится управление ФБ, управление проектами, управление жизненным циклом, методы разработки и тестирования. Составим небольшое резюме этих методов согласно структуре МЭК 61508. Все эти методы могут быть в равной мере применены как к обеспечению функциональной, так и информационной безопасности.

Управление проектами

Применение методов управления проектами позволяет обеспечить требуемый уровень безопасности, то есть удержаться в так называемом «треугольнике качества». «Свод знаний по управлению проектами» или PMBOK содержит рекомендации по внедрению процессов на всех этапах жизненного цикла проекта.

Документирование

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

Жизнненный цикл ИБ и ФБ

Реализация жизненного цикла ИБ и ФБ является требованием, которое уже подробно рассматривалось в предыдущих публикациях. В МЭК 61508 особый акцент делается на такие аспекты, как:
- реализация процесса верификации и валидации, заключающаяся в поэтапном выполнении обзоров, анализа и тестирования;
- сопровождение продукта после релиза с учетом обратной связи по результатам эксплуатации.

Использование лучших практик и стандартов кодирования

МЭК 61508 требует внедрять безопасное использование языков программирования, которое заключается в применении языков со строгой типизацией и поддержкой структурного программирования, при этом рекомендуется использовать ограниченное множество конструкций языка. Например, для микроконтроллеров систем безопасности предпочтение отдается языку С, а не С++. Для определения правил кодирования и запрещенных конструкций используются соответствующие стандарты, например MISRA.

Стандарты кодирования и лучшие практики определяют ряд соглашений (coding conventions), которые используются при разработке ПО в качестве требований к коду. Такие соглашения включают в себя правила наименования и комментирования, правила отступов и оформления кода, ограничения по сложности и т.д.

Распространенной практикой является так называемое защитное программирование, когда при возникновении какой-либо критической проблемы программное обеспечение завершает работу заранее предусмотренным образом, т.е. переводит систему в безопасное состояние.

Использование сертифицированных компиляторов и библиотек

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

Контроль качества при производстве аппаратных средств

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

Использование формальных и полуформальных нотаций

Еще одним организационным методом, требуемым МЭК 61508, является применение формальные и полуформальных нотаций для разработки спецификации требований и проектов систем, а также программных и аппаратных компонентов. В настоящее время наиболее распространенными полуформальными нотациями для проектирования программируемых систем являются IDEF и UML.
Для программируемых логических контроллеров разработаны и описаны в стандарте МЭК 61131-3 типовые языки программирования, поддерживаемые большинством сред разработки. Наиболее распространенным является графический язык FBD (Function Block Diagram), который фактически является формальной нотацией для проектирования программного обеспечения.

Технические методы обеспечения ФБ


Начнем с рассмотрения архитектуры АСУ ТП (см. Рисунок 3). В состав системы входят:
- компоненты электроснабжения;
- полевое оборудование (датчики и исполнительные механизмы);
- программируемые логические контроллеры, включая модули ввода и вывода и управляющие модули;
- сетевое оборудование, сервера и компоненты человеко-машинного интерфейса.



Рисунок 3. Типовая архитектура АСУ ТП (источник: ISA/IEC 62443)

Резервирование

Теперь рассмотрим, каким образом для АСУ ТП может быть реализовано резервирование (redundancy).
Резервирование может реализовываться как для отдельных компонентов или их групп, так и для системы в целом. Именно такой случай предлагается вашему вниманию (см. Рисунок 4).



Рисунок 4. Дублирование компонентов АСУ ТП

Начнем с электропитания. В идеале, максимальная независимость обеспечивается при электропитании независимых каналов системы от независимых источников. На схеме показано, что первый канал питается от источника переменного тока, а второй канал – от постоянного тока. Тогда, при проблемах с питанием в одной из систем энергоснабжения будет обесточиваться только один из каналов. Обеспечение непрерывности и качества электропитания даже в экстремальных условиях является жизненно важным аспектом обеспечения безопасности систем управления.

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

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

Разнообразие (диверсность) при резервировании

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



Рисунок 5. Снижение количества отказов по общей причине при использовании различных (диверсных) дублированных каналов (источник: МЭК 61508)

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

Независимость и разделение компонентов

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




Рисунок 6. Физическая и электрическая независимость каналов (источник: МЭК 60709)

Самодиагностика

Самодиагностику цифровых устройств упрощенно можно описать следующим образом (см. Рисунок 7).



Рисунок 7. Реализация диагностики в системах управления

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

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

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

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

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

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

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

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

Защита от воздействий окружающей среды

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

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

Специальные стандарты АТЕХ применяются для конструирования взрывобезопасных систем. Стандарты IP применяются для конструирования систем, защищенных от воздействия пыли и влаги.

Защита от ошибок персонала

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

Особенности обеспечения информационной безопасности
АСУ ТП


При рассмотрении методов, направленных на обеспечение ФБ, важно также обеспечить ИБ. В МЭК 61508 на этот счет содержится лишь несколько общих слов. Мы остановимся на нескольких особенностях АСУ ТП, которые определяют подход к обеспечению ИБ таких объектов. На Рисунке 8 рассмотрены потенциальные уязвимости, исходя из которых формируются векторы атак.



Рисунок 8. Уязвимости в АСУ ТП (источник: Byres Research Inc.)

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

Сегментирование сети

Основой обеспечения ИБ для АСУ ТП является сегментирование сети и зонирование размещения оборудования (эта тема обсуждалась здесь).
Рекомендуется реализовывать в АСУ ТП, как минимум, одну демилитаризованную зону (DMZ), разделяющую корпоративную и управляющую локальные сети.



Рисунок 9. Структура сети АСУ ТП с DMZ (источник: NIST 800-82)

Контроль доступа

Еще одной особенностью обеспечения ИБ АСУ ТП является активное использование контроля доступа, который может быть реализован несколькими способами.

Шкафы с оборудованием снабжаются замками и контактными датчиками открытия дверей, которые выдают сигналы на табло сигнализации.

Мониторинг и сохранение большого объема диагностических данных, в том числе, связанных с ИБ, предоставляет широкие аналитические возможности.

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

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

Выводы


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

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

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

Специальные методы предотвращения атак для систем управления включают в себя управление доступом и сегментацию сети.

P.S. Данная статья завершает цикл публикаций на тему функциональной безопасности. Основной целью публикаций являлось знакомство с азами серии стандартов МЭК 61508 и подходам к сертификации систем управления на соответствие требованиям МЭК 61508. Параллельно публикациям был подготовлен и записан видеокурс по функциональной безопасности (аналогов в мире не имеет). Тема безопасности остается неисчерпаемой, и автор готовит новые публикации.

суббота, 18 марта 2017 г.

Функциональная безопасность, часть 7. Оценивание показателей функциональной безопасности и надежности


Источник

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

Мы рассмотрим следующие вопросы:

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

Атрибуты надежности, информационной и функциональной безопасности


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

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


Рисунок 1. Графическая интерпретация определения надежности

Про соотношение свойств dependability и reliability следует сказать отдельно, поскольку в области стандартизации этого свойства западная и советская наука в свое время пошли несколько различными путями. Корректный перевод термина надежность – это dependability, поскольку и надежность, и dependability рассматриваются, как комплексные свойства. Reliability – это правильный перевод для термина безотказность, которая является важной, но все же только одной из составляющих надежности. Безотказностью называется свойство объекта непрерывно сохранять работоспособное состояние в течение некоторого времени или наработки, т.е. безотказность можно обобщать с надежностью только для необслуживаемых систем.

Кроме безотказности, составными свойствами надежности являются ремонтопригодность (Maintainability), долговечность (Durability) и сохраняемость (Storability). Готовность (availability) является комбинацией безотказности и ремонтопригодности.

Все эти положения были изложены в одном из самых лучших по стройности изложения стандартов, которые я когда-либо держал в руках, ГОСТ 27.002-89. «Надежность в технике. Основные понятия. Термины и определения». К сожалению, «неселективная» адаптация западных стандартов в качестве ГОСТ Р привела к тому, что наработки советской школы надежности ныне позабыты (по крайней мере, в области формальной стандартизации). В 2009 году был выпущен стандарт ГОСТ Р 27.002-2009 (первоначальный номер у него почему-то был ГОСТ Р 53480-2009, затем историческая справедливость восторжествовала), представляющий собой копи-паст также достаточно древнего словаря Международной электротехнической комиссии, IEC 60050-191:1990. Прогресс не всегда происходит поступательно, и о качестве изложения вы можете судить сами, сравнив изложение основных терминов (Рисунок 2). В Украине ныне действует ДСТУ 2860-94, соответствующий ГОСТ 27.002-89.


Рисунок 2. Сравнительный анализ атрибутов надежности согласно версий ГОСТ 27.002 от 1989 г. и 2009 г.

Подчеркнем, что мы рассматриваем именно случайные отказы аппаратных средств, к которым может быть применен математический аппарат теории вероятностей. Теория надежности дает практичную картину мира, в которой можно строить надежные системы из не вполне надежных компонентов (как правило, методами резервирования и диагностирования). По-другому обстоит дело с систематическими отказами, которые, очевидно, не могут быть описаны в рамках теории надежности. Именно такие отказы составляют наибольшую проблему, поскольку они непредсказуемы. В 1980-90-е годы были попытки применить вероятностные модели для оценивания надежности программного обеспечения, ошибок оператора, а затем и показателей ИБ. До настоящего момента этот путь не дал практически применимых результатов.

Еще одним подходом к анализу атрибутов надежности являемся так называемый RAMS подход, который расшифровывается, как Reliability (безотказность), Availability (готовность), Maintainability (ремонтопригодность), and Safety (безопасность). Иногда к этой четверке атрибутов добавляется еще и Integrity, интегрированность или полнота, ибо именно так это слово переводится в русскоязычной версии МЭК 61508. Наиболее простыми определениями для этих свойств являются:

— Готовность – это пригодность к правильной эксплуатации;
— Безотказность – это непрерывность правильного обслуживания;
— Ремонтопригодность – это способность подвергаться модификациям и ремонту.
— Безопасность – это отсутствие катастрофических последствий для пользователя и окружающей среды;
— Интегрированность – это отсутствие ненадлежащих системных изменений.

Security (ИБ) представляет собой совокупность атрибутов конфиденциальности, интегрированности и готовности (так называемая триада CIA). Готовность или доступность рассматривается для авторизованных действий по доступу к информации, а интегрированность рассматривается для корректной работы с данными, исключающей их неавторизованное изменение. Конфиденциальность является дополнительным, по сравнению с надежностью, атрибутом, который означает отсутствие несанкционированного раскрытия информации. Таким образом, простейшая модель, описывающая dependability (т.е. надежность) и security (т.е. информационную безопасность) представлена всего шестью атрибутами (Рисунок 3).



Рисунок 3. Атрибуты RAMS & CIA

Теперь сделаем еще одну итерацию и попробуем представить все известные нам атрибуты в виде одной диаграммы (Рисунок 4).



Рисунок 4. Обобщенная таксономия атрибутов надежности, информационной и функциональной безопасности

Обычными линиями отмечены атрибуты и связи, соответствующие только что рассмотренной модели из шести атрибутов. Пунктиром добавлены дополнительные атрибуты. Одна из групп атрибутов относится к составляющим надежности (dependability). ФБ (Safety), согласно МЭК 61508, включает safety functions & integrity, причем, через функции безопасности ФБ связана с безотказностью, готовностью и надежностью, а интегрированность выполнения функций обеспечивает целый ряд свойств, в том числе, ИБ. Таким образом, между атрибутами надежности, ИБ и ФБ существуют взаимное влияние и определенные связи, которые мы будем учитывать при количественном оценивании.

Анализ рисков и показатели функциональной безопасности


Теперь обратимся к показателям безопасности. Базовым понятием и показателем ФБ является риск, представляющий собой комбинацию вероятности нежелательного события и его последствий.

Оценивание рисков бывает количественным и качественным, при качественном оперируют такими категориями, как «высокий», «средний», «низкий» и т.д.

Если нежелательное событие и ущерб от него зафиксированы, то риск становится численно равен вероятности P(t) возникновения фиксированного ущерба. Например, риск аварии атомной электростанции с выбросом радиоактивных веществ в атмосферу на сегодняшний день устанавливается не более, чем 10-7 1/год.

Широкое распространение для оценивания и управления рисками получил так называемый принцип ALARA (ALARP) (as low as reasonably applicable/practicable) – подход к управлению риском, который подразумевает его максимально возможное снижение, достигаемое за счет реально имеющихся (ограниченных) ресурсов (Рисунок 5).



Рисунок 5. Снижения риска на основе метода ALARP (as low as reasonably practicable), IEC 61508-5

Удобной моделью является граф рисков (Рисунок 6). Пример взят из стандарта по безопасности промышленного оборудования (EN ISO 13849-1 Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design). Кроме вероятности и последствий событий учтена еще возможность избегания опасностей и ущерба. Эти три категории имеют высокое и низкое значение, в итоге получаем шесть комбинаций, каждая из которых соответствует тому или иному Performance Level (PL), от а до е, который является аналогом Safety Integrity Level (SIL).



Рисунок 6. Граф рисков, EN ISO 13849-1

Таков качественный подход к оцениванию рисков, теперь рассмотрим, как в МЭК 61508 нормируются количественные значения показателей безопасности. Если рассматривать системы управления, то событиями, связанными с риском, являются отказы функций безопасности, поэтому логично, что в качестве показателей безопасности выбраны вероятности отказов для функций безопасности.

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

Одним из важнейших показателей является вероятность безотказной работы, под которой понимается вероятность того, что отказ не произойдет за установленное время MTTF, называемое наработкой до отказа:
P(t) = P{MTTF > t}. Как и любая вероятность, вероятность безотказной работы принимает значения от 1 до 0, причем единице она равна в начальный момент времени, а нулю равна при времени стремящемся к бесконечности.


Вероятностью отказа называется вероятность того, что отказ произойдет за установленное время T, т.е. вероятность отказа дополняет вероятность безотказной работы до единицы (отказ либо произойдет, либо нет, т.е. имеем полную группу событий): F(t) = 1 – P(t).

Интенсивность отказов – условная плотность распределения (т.е. производная по времени) наработки до отказа при условии, что отказ не произошел, имеет размерность 1/час: λ(t) = f(t)/P(t) = – [1/P(t)] • [dP(t)/dt] = – [1/(1 – F(t)] • [dF(t /dt]. При статистической оценке интенсивность отказов определяется как отношение количества отказавших однотипных изделий к продолжительности интервала времени, на котором эти отказы наблюдались (например, если за 1000 часов отказало 10 изделий, то λ = 10/1000 = 0,01 1/час).

Важным допущением теории надежности является применение так называемого экспоненциального распределения времени до отказа, когда интенсивность отказов считается постоянной во времени.

Наработка до отказа MTTF вычисляется как определенный интеграл в пределах от нуля до бесконечности для вероятности безотказной работы по времени:



Иногда MTTF трактуется как среднее или гарантированное время работы системы, но это не так, поскольку вероятность безотказной работы в момент времени MTTF равняется 1/е, что приблизительно равно 0,37. Это значит, что для единичного устройства вероятность того, что устройство останется в работоспособным по истечению MTTF составляет всего лишь 0,37. Для группы однотипных устройств это означает, что только 37% из них останется работоспособным по истечению MTTF.

Коэффициент готовности (availability) – это вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается. Рассчитывается коэффициент готовности, как отношения наработки до отказа к сумме наработки до отказа (MTTF) и среднего времени восстановления после отказа (MTTR):

A = MTTF / (MTTF + MTTR).

Для понимания соотношения между надежностью и безопасностью обратимся к классификации отказов, рассмотренной в МЭК 61508 (Рисунок 7). Отказы могут быть опасные и безопасные, а также диагностируемые и недиагностируемые. В рамках надежности рассматриваются все виды отказов. С точки зрения безопасности нас интересуют только опасные отказы, причем важно, чтобы такие отказы были диагностируемые, и при их обнаружении система могла перейти в безопасное состояние.



Рисунок 7. Классификация отказов и показатели безопасности согласно IEC 61508

МЭК 61508 говорит о следующих показателях безопасности.

Во-первых, это так называемая устойчивость к аппаратным отказам (Hardware Fault Tolerance, HFT). Это очень простой показатель, который говорит о том, сколько может произойти аппаратных отказов в системе до выхода ее из строя. По сути, это эквивалентно количеству дополнительных резервных каналов. Т.е., если система нерезервированная, то любой отказ выводит ее из строя, HFT = 0. Если в система два резервных канала, то один из них является дополнительным, избыточным. После единичного отказа система останется работоспособное, т.е. HFT = 1, и т.д.

Во-вторых, должна быть определена доля безопасных отказов (Safe Failure Fraction, SFF). В терминах МЭК 61508 это отношение интенсивности безопасных и опасных диагностируемых отказов к суммарной интенсивности отказов (см. Рисунок 7). Получается, что в терминах МЭК 61508 учитываются, в первую очередь опасные недиагностируемые отказы, а опасные диагностируемые отказы в доле безопасных отказов относятся к безопасным.

Соответственно, может быть определена доля опасных отказов (Dangerous Failure Fraction, DFF), дополняющая долю безопасных отказов до единицы и рассчитываемая, как отношение интенсивности опасных недиагностируемых отказов к суммарной интенсивности отказов (см. Рисунок 7).

Диагностическое покрытие (Diagnostic Coverage, DCD) в МЭК 61508 определяется только исходя из интенсивности опасных отказов, это отношение интенсивности опасных диагностируемых отказов к интенсивности опасных отказов (см. Рисунок 7).

В технической диагностике более привычным является подход, когда диагностическое покрытие (DC) определяется, как отношение интенсивности диагностируемых отказов к суммарной интенсивности отказов (см. Рисунок 7). Однако, МЭК 61508 декларирует диагностическое покрытие, исходя из доли уменьшения вероятности опасных отказов за счет встроенного диагностирования.

Исходя из полученного значения доли безопасных отказов (Safe Failure Fraction) может быть определен максимально достижимый уровень полноты безопасности SIL, в зависимости от резервированной либо нерезервированной конфигурации (Рисунок 8).



Рисунок 8. Максимально достижимый уровень SIL, исходя из показателей Safe Failure Fraction (SFF) и Hardware Fault Tolerance (HFT), IEC 61508-2

Например, для доли безопасных отказов 90%-99% для нерезервированной конфигурации (HFT=0) может быть достигнут максимальный уровень полноты безопасности SIL2. В дублированной системе (HFT=1) может быть достигнут SIL3, а в троированной – SIL4 (HFT=2). Обычно такой подход применяют разработчики ПЛК и другого оборудования для управляющих систем безопасности. Стойкость к случайным отказам аппаратных средств соответствует уровню SIL2 для нерезервированной конфигурации и уровню SIL3 для дублированной конфигурации. Однако, следует помнить, что при этом стойкость к систематическим отказам, обусловленная реализацией процессов жизненного цикла также должна соответствовать уровню SIL3.

Еще одной градацией, установленной в МЭК 61508, является разделение оборудования на типы А и В (Type A & Type B). К типу А относятся наиболее простые, преимущественно механические и электрические компоненты. Все программируемые электронные компоненты относятся к типу В.

Кроме рассмотренных требований, существуют еще требования к численным значениям показателей безопасности.

Из базовых определений МЭК 61508 вспомним, что существует три режима работы оборудования: с низкой частотой запросов (low demand mode), в котором частота запросов на выполнение функции безопасности не превышает одного в год, с высокой частотой запросов (high demand mode), в котором частота запросов на выполнение функции безопасности превышает один в год, и непрерывный режим (continuous mode). Оказывается, что МЭК 61508 рекомендует различные показатели надежности для этих режимов.

Для систем, работающих с низкой частотой запросов, в качестве целевого показателя должна быть определена средняя вероятность опасного отказа выполнения функции безопасности по запросу (Рисунок 9). Для уровня полноты безопасности SIL1 этот показатель не должен превышать 0,1. С повышением SIL каждый раз вероятность опасного отказа должна уменьшаться в 10 раз. Таким образом, для уровня полноты безопасности SIL4 вероятность опасного отказа должна составлять от 10-5 до 10-4.

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



Рисунок 9. Зависимость уровня SIL от значения средней вероятности опасного отказа выполнения функции безопасности по запросу (режим с низкой частотой запросов), IEC 61508-1

Для систем, работающих с высокой частотой запросов или в непрерывном режиме, определяется средняя частота (или интенсивность) опасных отказов функции безопасности (Рисунок 10). Для уровня полноты безопасности SIL1 этот показатель не должен превышать 10-5 1/час, что эквивалентно одному отказу в 11,4 лет. С повышением SIL каждый раз интенсивность опасного отказа должна уменьшаться в 10 раз. Для уровня полноты безопасности SIL4 интенсивность опасного отказа должна составлять от 10-9 до 10-8 1/час, т.е., не чаще, чем один отказ в 11 400 лет. Конечно, для единичной системы это звучит несколько абсурдно, но, если учесть, что в мире эксплуатируются тысячи однотипных систем, то даже с такой низкой интенсивностью отказов опасные отказы являются вполне вероятными, что мы наблюдаем в действительности.

Данный показатель эквивалентен интенсивности опасных недиагностируемых отказов.



Рисунок 10. Зависимость уровня SIL от значения средней интенсивности опасных отказов функции безопасности (режим с высокой частотой запросов и непрерывный режим), IEC 61508-1

Все задачи расчета показателей безопасности связываются воедино в рамках методологии анализа видов, последствий и критичности отказов (Failure Mode, Effect and Criticality Analysis, FMECA). Основные положения данной методики изложены в стандарте IEC 60812:2006 Analysis techniques for system reliability – Procedure for failure mode and effects analysis (FMEA). В Российской Федерации принят ГОСТ Р 51901.12-2007 «Менеджмент риска. Метод анализа видов и последствий отказов», являющийся адаптацией МЭК 60812.

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

Примеры расчета показателей функциональной безопасности и надежности


Теперь рассмотрим несколько примеров по определению показателей безопасности, я их несколько адаптировал на основе примеров, приведенных в «Справочнике инженера по АСУ ТП» Ю.Н. Федорова.

Пусть необходимо рассчитать безопасность простой системы управления технологическим процессом. У нас есть некий резервуар (например, бойлер) с датчиком давления, в который подается по трубе некоторая жидкость (Рисунок 11). При превышении заданного уровня давления должен сработать отсечной клапан и перекрыть подачу жидкости в резервуар. Для обработки сигнала от датчика и выдачи сигнала срабатывания на клапан применяется программируемый логический контроллер (ПЛК). Для конкретики зададим вероятности отказов, пусть для датчика и клапана мы имеем вероятность отказа 10-3. Чтобы было удобней исследовать подходы к резервированию полевого оборудования, вынесем ПЛК за «скобки», т.е. мы будем считать, что ПЛК абсолютно надежный и его влияние мы учитывать не будем.

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

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


Рисунок 11. Пример 1: Нерезервированная система
Определите вероятность опасного отказа и вероятность ложного срабатывания


Ответ для Рисунка 11
Опасный отказ происходит в случае, когда отказывает или датчик или клапан. В этом случае вероятности складываются, то есть для системы вероятность опасного отказа составляет 2•10-3. Вероятность ложного срабатывания определяется точно такой же схемой событий и также равна 2•10-3.

Теперь определим вероятности для различных видов резервирования. Сначала введем резервирование для датчика (Рисунок 12). Будем считать, что резервированные компоненты идентичны, то есть, вероятности их отказа равны. Попробуйте определить, каковы вероятности опасного отказа и ложного срабатывания для этого случая?


Рисунок 12. Пример 2: Резервирование датчиков
Определите вероятность опасного отказа и вероятность ложного срабатывания


Ответ для Рисунка 12
Опасный отказ происходит в случае, когда отказывает или оба датчика или клапан. Вероятности отказов датчиков перемножаются, поскольку для отказа должны произойти оба отказа. Затем результат умножения складывается с вероятностью отказа клапана, получаем в результате 10-6 + 10-3 = 1,001•10-3, то есть величина близкая к 10-3. Таким образом, резервирования только одного компонента системы позволила снизить вдвое вероятность опасных отказов. Теперь, что получается с ложными срабатываниями? Вероятность ложных срабатываний у нас увеличилась в полтора раза по сравнению с исходной схемой, поскольку ложное срабатывание может произойти для любого из трех компонентов, следовательно, вероятности складываются и получаем 3•10-3.

Теперь давайте рассмотрим, что получится, если резервируется не датчик, а клапан (Рисунок 13)? Чему равны вероятности?


Рисунок 13. Пример 3: Резервирование клапанов
Определите вероятность опасного отказа и вероятность ложного срабатывания


Ответ для Рисунка 13
Как и следовало ожидать, результат идентичен предыдущей схеме резервирования, вероятность опасных отказов равна 1,001•10-3, вероятность ложных срабатываний 3•10-3.

Теперь рассмотрим схему, где резервируются и датчики, и клапаны. Будем считать, что по данным каждого из датчиков формируется сигнал управления на каждый из клапанов (Рисунок 14). Что получаем?


Рисунок 14. Пример 4: Резервирование датчиков и клапанов (1-й способ)
Определите вероятность опасного отказа и вероятность ложного срабатывания

Ответ для Рисунка 14
Опасный отказ наступит, если отказали оба датчика или оба клапана. Таким образом, вероятности отказов для датчиков и для клапанов перемножаются, и эти результаты складываются, получаем
2•10-6, т.е. мы снизили вероятность опасных отказов в 1000 раз по сравнению с исходной нерезервированной системой. А вот ложное срабатывание произойдет при срабатывании любого из компонентов системы, т.е. все вероятности отказов складываются, и мы получаем 4•10-3. Т.е. как ни парадоксально звучит, но в системе безопасности резервирование снизило готовность системы в два раза по сравнению с исходной системой.


Для отсечного клапана возможен еще один вид резервирования, когда они устанавливаются параллельно, и тогда подача продукта в резервуар прекращается в том случае, когда сработали оба клапана (Рисунок 15). Как в этом случае определить вероятности опасного отказа и ложного срабатывания?


Рисунок 15. Пример 5: Резервирование датчиков и клапанов (2-й способ)
Определите вероятность опасного отказа и вероятность ложного срабатывания


Ответ для Рисунка 15
Опасный отказ происходит при отказе обоих датчиков либо любого из клапанов. Вероятности отказа датчиков перемножаются, вероятности отказа клапанов складываются. В итоге получаем вероятность опасного отказа 2,001•10-3. Для вероятности ложного срабатывания вероятности отказа датчиков складываются, вероятности отказа клапанов перемножаются, и мы получаем вероятность ложного срабатывания также равную 2,001•10-3. Если сравнить с исходной схемой, то опять-таки получается парадокс, ввели резервирование, увеличили в два раза объем оборудования, но никакого выигрыша при этом не получили.

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


Выводы


Сегодня мы рассмотрели, каким образом осуществляется количественное оценивание показателей ФБ.

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

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

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

Риск является универсальным показателем функциональной безопасности. В зависимости от типа системы, риск может быть трансформирован в целевые значение коэффициента готовности и интенсивности отказов, которая варьируются в зависимости от уровня полноты безопасности SIL.

Анализ видов, последствий и критичности отказов (FMECA) является наиболее эффективным подходом для количественной и качественной оценки безопасности.

Здесь можно посмотреть видеолекции по теме публикации