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

Вместе с тем компании и индивидуальные пользователи имеют возможность создавать сетевые сервисы, используя не только инфраструктуру интернета, но и опубликованные сервисы других владельцев. Например, вставляя чужие фреймы в свой публичный или корпоративный портал. По сути, таким способом формируется множество виртуальных SoS со слабоорганизованными взаимодействиями: действительно, ведь в нашем примере ответственность за работоспособность «чужого» сервиса лежит на том, кто его вставил в свой портал, если нет специального контракта с владельцем сервиса. То есть в данном случае репутация владельца становится решающей. Естественно, такая виртуальная SoS будет существовать в течение того временного отрезка, на котором она решает поставленную задачу.

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

• «транспорт – управление воздушным движением, Европейская железнодорожная сеть, интегрированное управление наземным транспортом, грузовым транспортом, управление скоростными магистралями и космические системы;

• энергетика – умные сети, умные дома и интегрированное производство/потребление;

• здравоохранение – системы управления областными учреждениями, аварийно-спасательными службами и управления персональным здоровьем;

• управление природными ресурсами – окружающей средой, региональными водными ресурсами, лесным хозяйством и рекреационными ресурсами;

• реагирование на катастрофы – ответы на стихийные бедствия, включая лесные пожары и наводнения, а также нападения террористов;

• потребительские товары – интегрированные развлечения и интеграция бытовых изделий;

• бизнес – банковское дело и финансы;

• средства массовой информации – кино, радио и телевидение» 153 [22].

Различия между системами (из систем/подсистем) и системами систем существенным образом влияют на принципы использования системной инженерии (см. табл. 2.1).

Таблица 2.1. Различия между системами и системами систем с точки зрения системной инженерии. Источник: SEBoK v1.8 [22, Systems of Systems (SoS)]

Системная инженерия SoS, в отличие от традиционной, имеет дело не с функциями систем, а с возможностями. Заказ на систему систем осуществляется в терминах возможностей (capabilities), а не функций (functions) систем. То есть заказчики хотят приобрести возможность достижения новых (супер)целей, а не функции собственно системы, реализующие эти возможности. Системы уже куплены, существуют, у них есть владельцы и все необходимые функции. Но заказчику нужны возможности, которые можно достичь при совместной работе этих систем. Возможности формулируются следующим образом: данная система должна обеспечивать возможность (и далее хотя бы один глагол того действия, которое она должна давать возможность сделать).

Структурированный и эффективный стандарт системной инженерии SoS, который определял бы необходимые процедуры управления SoS «на основе требований постоянного технологического развития в сложной динамической среде» [19], пока не разработан. В настоящее время идет работа над руководством по принципам использования системной инженерии для SoS 154 , активно исследуются методологические подходы и набор инструментов системной инженерии SoS, в первую очередь на основе сетевых методов [38, 20]. В 2018 году состоялась уже 13-я международная конференция по системной инженерии SoS 155 .

Тем не менее, в действующем стандарте по системной инженерии ГОСТ Р 57193–2016 [15н] уделено специальное внимание (Приложение G) тому, какие «вышеперечисленные характеристики SoS имеют последствия при применении каждого из четырех видов процессов жизненного цикла системы».

Процессы соглашения, в соответствии с ГОСТ Р 57193–2016 [15н], имеют крайне важное значение для SoS, потому что они устанавливают способы управления разработкой и эксплуатацией среди организаций, ответственных за SoS. Составляющие системы, приобретаемые и управляемые различными организациями, часто поддерживают первоначальные цели, которые могут не совпадать с целями SoS. За исключением случая целевых SoS задачи организациям, управляющим составляющими системами, не могут быть поставлены без сотрудничества с ними. В общепризнанных или коллаборативных SoS эти задачи сбалансированы в сравнении с задачами составляющей системы. А для виртуальных SoS процессы согласования могут быть неформальными или приниматься во внимание только для целей анализа.

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