comtemichel (comtemichel) wrote,
comtemichel
comtemichel

Об проект NIST CPS Framework -- безопасность в киберфизических системах, сквозное рассмотрение

Оригинал взят у ailev в Об проект NIST CPS Framework -- безопасность в киберфизических системах, сквозное рассмотрение
Проект NIST CPS Framework (http://www.cpspwg.org/Portals/3/docs/CPS%20PWG%20Draft%20Framework%20for%20Cyber-Physical%20Systems%20Release%200.8%20September%202015.pdf -- 227 страниц) ещё совсем не окончателен, но я таки выскажусь.

Появился он не от хорошей жизни: киберфизическими системами главным образом под именем "интернета вещей" (IoT) занялись в десятке разных организаций стандартизации. И NIST сообразил, что никакого общего интернета вещей не будет, если не смогут хоть как-то "одинаково" обсуждать самые разные киберфизические системы, опирающиеся на самые разные стандарты. И поэтому в основу там положили ISO 42010 и ISO 15288 (т.е. системный подход и системную инженерию) как средство потенциально договориться самым разным специалистам, самым разным инженерам и менеджерам, самым разным стейкхолдерам.

В NIST CPS Framework всё изложение выстроено как матрица между:
-- описанием жизненного цикла ("грани", facets -- вместо "стадий" для набора практик жизненного цикла, т.е. activities and work products). Это позволяет обсуждать практики вне зависимости от времени их применения, и даже вне зависимости от системы, к которой они применяются, когда речь идёт об обеспечивающих и использующих системах).
-- описанием различных аспектов (aspects, они же "сквозные интересы", cross-cutting concerns), группирующих более специфические интересы в рамках этих сквозных интересов. При этом интересы (в том числе сквозные) даже не ортогональны: в одних из них интересуются объектами других, это ничего.



Опора на stakeholder concerns как first class object очень правильна. В CPS Framework пытаются пройти по линии, намеченной Rich Hilliard в http://web.mit.edu/richh/www/writings/hilliard-AD-in-the-large.pdf -- разные "жанры" архитектуры (genres -- архитектура предприятия, системы, софта) для разных предметных областей (domains) можно различить, сравнивая основных стейкхолдеров и их интересы. Это прямая линия от ISO 42010, но редко проводимая в жизнь. Поскольку нужно было определять инженерию киберфизических систем в её отличии от других инженерий, определять киберфизические системы в их отличии от других систем, то были выписаны специфические интересы.

Как всегда, основные типовые стейкхолдеры не попали в схемы CPC Framework (меня тоже это всегда удивляло: интересы оказываются главнее, чем стейкхолдеры -- стейкхолдеры со временем меняются, типа как "вебмастер" рассыпается на десяток разных других стейкхолдеров, а интересы-то остаются!). Но зато типовые интересы составили костяк для всего изложения, позволяя обсуждать какие-то проблемы до того момента, как выбраны методы описания (viewpoints) и тем более даны какие-то описания систем в рамках этих методов. Ибо методы описания оформляют (frame) интересы, если нет интереса, то и описаний не нужно, и их методы тогда тоже не нужны. Это огромный плюс CPS Framework.

Что интересно, так это похожесть интересов для киберфизических систем на интересы для "просто системной инженерии" -- я думаю, это совершенно не случайно, ибо вся системная инженерия сейчас по факту занимается киберфизическими системами. Сам список интересов мне кажется очень полезным и нетривиальным: там аспекты functional, business, human, trustworthiness, timing, data, boundaries, composition, lifecycle. Обратите внимание, timing (всяческие синхронизации и описания "тормозов" -- подробно со страницы 116) представляет собой отдельный аспект со многими интересами!

Но вот если брать интересы какой-нибудь "инженерии предприятия" или "инженерии психики", или "инженерии [систем] машинного обучения", то можно будет видеть резкое изменение и типовых стейкхолдеров (хотя я не ожидаю тут глубоких прозрений) и типовых интересов. Так, в инженерии предприятий не принято говорить о "функциональности" предприятия или какой-нибудь manufacturability предприятия, а для инженерии машинного обучения важен интерес отсутствия переобучения/генерализации, в инженерии психики очень важен вопрос экологичности/безопасности для психики -- он формулируется совсем не так, как формулируются интересы безопасности для того же предприятия или киберфизических систем. Этот ход на выпячивание интересов при обсуждении классов систем, сохранение в явном виде знаний на уровне интересов, я бы считал положительным. Опять же, Rich Hilliard призывает иметь контрольные точки/вопросы для интересов в явном виде -- для чего интересы документировать, трассировать к ним все частные описания системы. В больших проектах это явное моделирование интересов необходимо.

В части множественности описаний -- безусловный прогресс! Для каждого интереса делается попытка назвать стандарты, которые могли бы оформить этот интерес (т.е. дать метод описания интереса). Такого развёрнутого систематического хода на concerns и от них viewpoint я ещё не встречал.

Очень хорош также ход на представление в виде "граней" (facets) практик жизненного цикла (activity+artifacts) по типу того, что был сделан в OMG Essence в виде area of concerns (при этом в CPS Framework грани ортогональны интересам!). Но там очень хитро:
-- концептуализация имеет дело с использующей системой (хотя в тексте говорится о "модели CPS"). По сути там развёрнуто описание инженерии требований как системноинженерной дисциплины.
-- воплощение (realization) имеет дело с воплощением CPS и её описаниями, начиная с архитектуры и мультифизических моделей. По сути, тут архитектура и все остальные инженерии, включая производство и даже эксплуатацию и вывод из эксплуатации.
-- обоснование (assurance) имеет дело с соответствием описаний и воплощения. Это проверки и приеёмки.

Для меня этот "треугольник" (который кривовато выводят из V-диаграммы) положителен тем, что впервые в явном виде все призывы "обратить особое внимание на V&V как системноинженерную дисциплину" был реализован. И это деление очень, очень близко к тому, что я обычно пишу про системную инженерию -- разве что "грань" системноинженерного менеджмента там пропущена, но она вошла по факту в realization (из которой сделали большую помойку, примерно по тому же принципу, по которому сейчас делают большую помойку в OMG Essence вокруг альфы "система").

С другой стороны, этот "треугольник" концептуализации-воплощения-обоснования крив. Например, при всех ссылках на ISO 15288 в CPS Framework не делается попыток различить работу с миссией/стратегией, потребности стейкхолдеров, требования стейкхолдеров и требования к системе. Это всё "концептуализация", слово requirements там обозначает и needs, и stakeholder requirements, и system requirements, и constraints. И ещё там вовсю используются non-functional requirements. Я понимаю, что хотелось подчеркнуть в "концептуализации" model-based conceptual design (http://ailev.livejournal.com/1160014.html), прединженерные стадии, но так уж получилось, что заодно туда криво засунули работы инженерии требований и даже кусок работы с архитектурой (ибо logical models с функциями компонент согласно CPS Framework как раз в концептуализации -- это они признают, что не потребности-требования, но функциональную декомпозицию и логические модели приписывают как "родственников"). А вот работа с мультифизикой и модульный синтез -- это уже "воплощение". То есть "концептуализация" -- это такой полупрозрачный ящик получается, а не "чёрный ящик". Но нужно приглядеться внимательней: там ведь влёгкую "logical models" могут оказаться не logical architecture!

И вообще, в явном виде инженерии системной архитектуры (центральная ведь практика!) не обнаружно: слово "архитектура" по факту не используется, в отличие от слова "требования" (которое, как мы помним, используется чрезвычайно широко).

Делается также стандартная ошибка выстраивания иерархий: разные уровни иерархии имеют разные названия, число уровней предписано. Например:
-- аспекты (aspects, хотя и говорят, что это "сквозные интересы", cross-cutting concerns) и интересы (concerns). Уровней всего два, названия у них разные, дальше невнятно говорят о декомпозиции интересов.
-- грани (facets), которые на самом деле практики (activities и их work products/artifacts, где-то "внизу" по иерархии становясь из activities "процессами", process). Тоже уровней два, в явном виде понятия практики не вводится, хотя объединяющие activity и work products квадратики для facets рисуются, но дальше всё лирически дробится на activities.

Если приглядеться, то силовики (занимающиеся security) и чиновники (занимающиеся safety) написали бОльшую часть текста: у этих ребят всегда есть время писать стандарты, директивы, предписания и фреймворки. У остальных инженеров времени для написания качественных своих разделов было явно меньше, это хорошо видно. Про "умность" мы не находим ничего, но зато подробные рассказы про Stuxnet и недопустимость раздельного учёта safety, reliability, privacy, cybersecurity, resilience -- только вместе, только в комплексе! Я думаю, в следующем CPS Framework до безопасников дойдёт и волна машинного интеллекта, и к развёрнутым примерам Stuxnet добавится ещё и обсуждение Skynet, на десятки страниц. И даже когда мы читаем про аспект data, основное внимание там уделяется firewall, permissions и прочим аспектам безопасности (хотя и есть попытка что-то рассказать про data fusion и моделирование данных).

А вот основные инженерные аспекты оказались описаны по полстранички (буквально!) каждый -- composition (Concerns related to the ability to compute selected properties of a component assembly from the properties of its components. Compositionality requires components that are composable: they do not change their properties in an assembly. Timing composability is particularly difficult. Namely: adaptability, complexity, constructivity, discoverability) и lifecycle (deployability, disposability, engineerability, maintainability, operability, procureability, producibility).

Дальше там идут примеры использования CPS Framework, чтобы рассуждать о сложных CPS типа "мониторинг энергоэффективности завода". Учитывая, что примеров системной инженерии в Сети можно найти крайне мало, наличие этих use case examples крайне полезно. Там, например, можно найти такие картинки:



Там есть и другие примеры, главным образом как делать стадию концептуализации (какие таблички заполнять, чтобы описать киберфизическую систему так, чтобы её описание было хоть как-то сравнимо с другими описаниями -- ведь именно для этого и затеян весь CPS Framework).

Руководителем рабочей группы по справочной архитектуре (reference architecture) там Janos Sztipanovits -- http://www.nist.gov/cps/cpspwg_refarch.cfm. Я когда-то даже писал про его воззрения в 2009 году по теме Convergence: Model-Based Software, Systems And Control Engineering (http://ailev.livejournal.com/673824.html и http://ailev.livejournal.com/675208.html). И это его предложения легли в методологическую основу CPS Framework. Он все эти годы занимался проектом инструментария интеграции моделей OPENMeta для программы Adaptive Vehicle Make (AVM) DARPA, вот типичный его отчёт по этой программе: http://www.isis.vanderbilt.edu/sites/default/files/The%20META%20Toolchain_Accomplishments%20and%20Open%20Challenges.pdf. И именно в этой программе он отрабатывал всю эту механику с aspects-facets, например смотри его апрельскую 2015г. презентацию в сборничке презентаций тут (начиная с 72 слайда) -- http://www.cpspwg.org/Portals/3/pdfs/CPS%20PWG%20April7%202015%20Morning%20Opening%20through%20Reference%20Architecture%20presentations.pdf, терминология там была ещё другая (например, не conceptual facet, а system facet), но зато дан дополнительный пример из программы AVM DARPA, включая Meta Programmable Tools и Semantic Backplane с языком интеграции моделей CyPhyML. Этот пример сам по себе интересен как попытка пройти по линии интеграции инженерных моделей максимально далеко в рамках текущего мейнстрима технологий model-based systems engineering (например, интенсивного использования Modelica). Обратите внимание, что в презентация Sztipanovits отнюдь не перегружена соображениями безопасности и защиты (даром что сам пример абсолютно военный, этот adaptive vehicle вполне себе бронетранспортёр).

Итого: CPS Framework -- хороший пример системноинженерного методологического рассуждения. Просмотреть его было бы полезно всем любителям ISO 42010 и ISO 15288, но при этом нужно чётко понимать, что там сейчас дико переразвитая часть по безопасности и защитам и почти ничего не сказано про собственно инженерное содержание, кроме некоторых примеров по концептуализации/начальным стадиям инженерии требований. И практически не помянут системноинженерный менеджмент из практик системной инженерии. И ничего про "ум" в этих "умных" (smart) системах.

С нетерпением жду выхода конечной версии. А пока я бы назвал этот документ "Безопасность и защита в кибер-физических системах, сквозное рассмотрение".

Tags: ИТ, аналитика, интернет, интернет вещей, компьютеры, перепост
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments