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: ИТ, аналитика, интернет, интернет вещей, компьютеры, перепост
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments