Источник

По данным IoT Analytics в 2016 году больше всего проектов (22% от общего количества), связанных с применением интернета вещей, было реализовано для промышленных объектов. Это подтверждает развитие и распространение технологий заявленных в доктрине Industry 4.0.

Таким образом, на наших глазах возник новый класс кибер-физических систем, получивший название Industrial Internet Control Systems (IICS) или Industrial Internet of Things (IIoT).

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

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

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



Рисунок 1. Структура требований к ИБ и ФБ

«Большой» жизненный цикл

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

Взглянем, что по этому поводу говорит МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems). В первой части этого стандарта содержится «эпический» рисунок, относящийся к жизненному циклу промышленного объекта. Названия этапов говорят сами за себя. Непосредственно к АСУ ТП относятся следующие этапы (отмечены на Рисунке 2 зелеными звездочками):

— 1 Concept;
— 9 Electrical/electronic/programmable electronic (E/E/PE) system safety requirement specification;
— 10 E/E/PE system realization;
— 12 Overall installation and commissioning;
— 14 Overall operation, maintenance and repair;
— 15 Overall modification and retrofit;
— 16 Decommissioning or disposal.



Рисунок 2. IEC 61508-1, Figure 2 – Overall safety lifecycle
(«*» отмечает этапы, применимые к АСУ ТП)

V-образный («малый») жизненный цикл

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

Далее, МЭК 61508 раскрывает структуру этапа «10 E/E/PE system realization» (см. Рисунок 3). Структура процесса реализации предлагается, как для программного, так и для аппаратного обеспечения, причем для последнего различается программируемая составляющая (например, ПЛИС, программируемые интегральные схемы) и непрограммируемая составляющая.



Рисунок 3. IEC 61508-2, Figure 4 – Relationship between and scope of IEC 61508-2 and IEC 61508-3

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

Таким образом, одна из проблем МЭК 61508 заключается в том, что в нем отсутствует в явном виде жизненный цикл, который мог бы непосредственно быть применен к компьютерным системам управления, будь то АСУ ТП, встроенные системы или уровень устройств «интернета вещей».

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



Рисунок 4. IEC 61508-3, Figure 6 – Software systematic capability and the development lifecycle (the V-model)

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



Рисунок 5. Жизненный цикл информационной и функциональной безопасности

Модель жизненного цикла включает в себя следующие последовательно выполняемые этапы (на Рисунке 5 этапы обозначены именами итоговых документов):

— разработка концепции (Concept);
— разработка спецификации требований по безопасности (Safety Requirements Specification, SRS), описывающей систему в виде «черного ящика», то есть, «что выполняется», а не «как выполняется»;
— обзор спецификации требований по безопасности (SRS Review), является этапом процесса верификации и валидации;
— разработка проекта архитектуры системы (System Architecture Design, SAD), описывающей систему в виде «белого ящика», то есть, «как выполняется», а не «что выполняется»;
— обзор проекта архитектуры системы (SAD Review), является этапом процесса верификации и валидации;
— разработка проекта аппаратных средств (Hardware Design), в русскоязычной терминологии эта составляющая называется конструкторской документацией (КД), в нее входят, как проекты электронных плат, так и чертежи механических конструкций и электрической части (так называемой «обвязки»), включающей кабели, компоненты электроснабжения и сопряжения с полевым оборудованием (датчиками и исполнительными механизмами;
— обзор проекта аппаратных средств (Hardware Design Review), является этапом процесса верификации и валидации;
— анализ видов, последствий и критичности отказов (Failure Mode, Effect and Criticality Analysis, FMECA), является этапом процесса верификации и валидации; при выполнении FMECA в первую очередь учитывается структура аппаратных средств, однако, принимается во внимание также механизмы диагностирования и отказоустойчивости, реализуемые в программном обеспечении;
— проектирование программного обеспечения (Software Design);
— обзор проекта программного обеспечения (Software Design Review), является этапом процесса верификации и валидации;
— разработка кода программного обеспечения (Software Coding);
— статический анализ программного кода (Static Code Analysis);
— тестирование программного обеспечения на соответствие требованиям проекта (Software Testing) включает в себя как юнит-, так и интеграционное тестирование, как функциональное, так и структурное тестирование; перед началом тестирования разрабатывается план и спецификация тестирования программного обеспечения (Software Test Plan and Specification, TP&S), результаты тестирования документируются в отчете о тестировании программного обеспечения (Software Test Report, TR);
— тестирование методом засева дефектов в аппаратные средства и программное обеспечение (Fault Insertion Testing), входом для которого являются результаты FMEDA в части анализа реализации самодиагностики; перед началом тестирования разрабатывается план и спецификация тестирования методом засева дефектов (Fault Insertion TP&S), результаты тестирования документируются в отчете о тестировании методом засева дефектов (Fault Insertion TR);
— интеграционное тестирование интегрированных программно-аппаратных компонентов на соответствие требованиям к архитектуре (Integration Testing); перед началом тестирования разрабатывается план и спецификация интеграционного тестирования (Integration TP&S), результаты тестирования документируются в отчете об интеграционном тестировании (Integration TR);
— валидационное тестирование интегрированной системы на соответствие спецификации требований по безопасности (Validation Testing); перед началом тестирования разрабатывается план и спецификация валидационного тестирования (Validation TP&S), результаты тестирования документируются в отчете об валидационном тестировании (Validation TR); учитывая важность данного заключительного этапа жизненного цикла, МЭК 61508 требует, чтобы план валидационного тестирования был составлен сразу после окончания разработки спецификации требований по безопасности (SRS); валидация может включать в себя кроме функционального тестирования также тестирование на устойчивость к экстремальным воздействиям окружающей среды (температурно-влажностным, механическим, электромагнитным, радиационным и т.д.).

Фазы жизненного цикла

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

Таблица 1. Фаза Concept



Таблица 2. Фаза Safety Requirements Specification



Таблица 3. Фаза Safety Requirements Specification Review



Таблица 4. Фазы System Architecture Design, System Architecture Design Review



Таблица 5. Фазы Hardware Design, Hardware Design Review



Таблица 6. Фаза Failure Mode, Effect and Criticality Analysis



Таблица 7. Фазы Software Design, Software Design Review, Software Coding, Static Code Analysis



Таблица 8. Фаза Software Testing



Таблица 9. Фаза Fault Insertion Testing



Таблица 10. Фаза Integration Testing



Таблица 11. Фаза Validation Testing

Трассировка требований

Трассировка требований является одним из процессов более обширной области знаний, называемой инженерия требований (Requirements Engineering).

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

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

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

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



Рисунок 6. Пример трассировки требований

Слева представлен фрагмент Safety Requirements Specification. Документ разработан в табличном виде. Для каждого из требований введен идентификатор, в данном случае это EIR.01, требования к интерфейсу электропитания. Сканирование документа для трассировки выполняется инструментальным средством DEUS компании exida. DEUS представляет собой макрос MS Office. Начало требования определяется идентификатором, а окончание требование символом [/]. В поле Allocation указывается документ нижнего уровня, куда трассируются требования спецификации. В данном случае это System Architecture Design. В System Architecture Design также должна быть выполнена разметка требований тегами. Кроме того, для каждого из требований должен быть указан его источник в документе верхнего уровня, так называемое родительское требование. Для нашего требования получилось отношение один-ко-многим, то есть требование к электропитанию отобразилось в требования и к базовой концепции продукта, и к шасси, и ко всем модулям. Далее каждое из требований SAD трассируется в Hardware Design & Software Design. Окончательные результаты трассировки могут быть представлены в виде набора матриц, отражающих соотношения между требованиями документов. Обратная трассировка требований выполняется от документов нижнего уровня к документам верхнего уровня чтобы убедиться в том, что в продукте не появился лишний недокументированный функционал.

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

Выводы

Четвертая индустриальная революция (Industry 4.0) формирует вызовы, связанные с обеспечением информационной и функциональной безопасности для нового типа систем, Industrial Internet Control Systems (IICS) или Industrial Internet of Things (IIoT). В связи с этим представляется важным учитывать в комплексе требования к ИБ и ФБ. Как часть стратегии по реализации требований к ИБ и ФБ, в настоящей статье описана структура и содержание этапов для Safety & Security Life Cycle.

Еще одним вызовом является подготовка специалистов, способных разрабатывать, оценивать и эксплуатировать новый класс систем (IICS, IIoT). Очевидно, что такие специалисты должны владеть технологиями в двух доменах: АСУ ТП и интернет вещей. Наши вузы таких специалистов пока массово не готовят, а на рынке АСУ ТП и интернет вещей, как единый стек технологий, пока еще не «дружат», хотя этот вопрос времени.

P.S. Для объяснения основных аспектов функциональной безопасности разрабатывается следующий цикл статей:
— Введение в тематику функциональной безопасности;
— Стандарт МЭК 61508: терминология;
— Стандарт МЭК 61508: структура требований;
— Взаимосвязь между информационной и функциональной безопасностью АСУ ТП;
— Процессы управления и оценивания функциональной безопасности;
— Жизненный цикл информационной и функциональной безопасности;
— Теория надежности и функциональная безопасность: основные термины и показатели;
— Методы обеспечения функциональной безопасности.