Доклад Анатолия Левенчука "Системо-системная инженерия: основные методы и инструменты" на секции "Интеллектуальная энергетика как система систем: от концепции к платформе с открытой архитектурой" конференции UpGrid, 31 октября 2013г.
2. Понятие системы
• Деятельностная субъективность (действующие
лица и исполнители).
• Функционал (внешнее поведение) против
конструктива (строение из
взаимодействующих частей): два разных
объекта, отражающих дуальность холона.
• Идеальное против материального
(моделирование: определение и воплощение)
• Жизненный цикл (с выделенной стадией
эксплуатации) и классификация систем.
2
3. Международные стандарты системного подхода
• обобщенный с архитектурного описания до описания определения
системы ISO 42010: множественность описаний и деятельностный
подход. Это "поворот мозгов" от редукционистского подхода
одного всеохватного описания к системному
подходу, подразумевающему множественность связанных
описаний, находящихся в различных информационных системах.
• обобщенный с программной до системной инженерии OMG
Essence: описание жизненного цикла и его практик
(системноинженерный менеджмент). Метод контрольных
вопросов в управлении жизненным циклом.
• ISO 81346 для минималистичного описания структуры и системы
обозначения сложных инженерных объектов (принципы
инженерного кодирования). Это фундамент для управления
конфигурацией в ходе жизненного цикла.
• ISO 15926 для моделирования данных развёрнутых (полных)
описаний инженерных объектов. Обеспечивает федерирование
развёрнутых описаний в различных информационных системах
жизненного цикла.
3
6. Критерии Maier
• Независимое управление элементов (нет, кому
скомандовать общее развитие)
• Независимая работа элементов (нет, кому
скомандовать работу в общем сервисе)
• Эмерджентность от объединения в систему
• Эволюционное развитие (требует
исследований, нет точки, которая знает as built для
всех)
• Географическое распределение элементов
• Вывод: никакой обычной системной инженерии.
Capability engineering, capability
development, capability change – затем operation.
6
7. Как говорят о системах систем
•
•
•
•
Отрасль (industry)
Эко-система (еco-system)
Распределенная работа (distributed work)
Федерирование (federation)
• Capability
• Networked
7
8. Виды системы систем
• управляемые (directed), в которых есть назначенный
архитектор, который может выдавать приказы
составляющим системам и распоряжается ресурсами.
• подтвержденные (acknowledged), в которых
признаваемый архитектор есть, но он может только
уговаривать составляющие системы самоизмениться
согласно разработанной им архитектуре.
• сотрудничающие (collaborative), в которых все системы
договариваются друг с другом по каждому чиху, но
архитектора, менеджера проекта или аналогичного
выделенного органа управления нет.
• виртуальные (virtual), в которых системы вообще не
знают друг о друге ничего и не влияют друг на друга
(например, современный интернет. Smart Grid тоже
собирается быть такой системой).
8
9. Системы систем: никаких чудес
• Никаких своих понятий
• Заимствования из гуманитарных наук:
социологии, политологии, психологии, мене
джмента, конфликтологии, …
• Поскольку независимое финансирование
проектов, независимые планы развития, то
единственный путь «системо-системной
инженерии» – это совместная асинхронная
эволюция.
9
10. Определение и воплощение системы
(обобщение ISO 42010)
Подальфы
технологии
(задаются
стандартами)
10
11. Нужно как-то договориться:
у разных систем разные методы описаний
у разных систем разные онтологии
«Функция»
«Процесс»
«Деятельность»
Консультант
Аналитик
«Процедура»
Менеджер
по качеству
31-Oct-13
Менеджер
«Шаблон проекта»
Планировщик
По материалам
компании FutureModels
11
12. Принципы обеспечения взаимодействия
• ISO 11354-1 Advanced automation
technologies and their applications —
Requirements for establishing
manufacturing enterprise process
interoperability — Part 1: Framework for
enterprise interoperability
• В пункте 5.4.1:
There are three approaches to achieve
enterprise interoperability:
-- integrated, [не случай системы систем]
-- unified, [если специально предпринять
меры]
-- and federated. [самый частый случай]
These three approaches were first identified in ISO 14258.
12
13. ISO 11354-1 – unified
(открытые архитектуры)
•
•
•
•
У военных: open systems architectures (OSA)
Стандартизация (классическая)
Открытые API («cтандарты де-факто»)
Обмен описаниями систем (в каком
формате готовить описания?
Необходимость семантики).
13
14. Семантический формат данных ISO 15926:
проблемы и решения
Расширяемость
Факт-ориентированность и семантика
Поддержка онтологии
Общая картина мира
Понятие системы «из коробки»
Простота: паттерны
Инструменты: разные реализации стандарта
Наличие доступных справочных данных
14
16. Агенты
• В ситуации федерирования
• Агент – всегда есть принципал, для
которого
• Агент – это «очень умный адаптор»
• Стандарты для агентов: это шаг от unified к
автоматизации federated подхода.
16
17. Спасибо за внимание
Анатолий Левенчук,
http://ailev.ru
ailev@asmp.msk.su
Президент Русского отделения INCOSE
Член исполкома Русского отделения SEMAT
Виктор Агроскин
vic5784@gmail.com
Член экспертной группы ISO TC184/SC4/WG3 (Industrial data / Oil, Gas, Process and
Power)
TechInvestLab.ru
+7 (495) 748-53-88
Член POSCCaesar Association
17
Editor's Notes
5.4.2 Integrated approachIn the integrated approach a common form shall be used to represent the exchanged entities. This common form shall be sufficiently expressive to capture those details that affect interoperability of the items to be exchanged, rather than the process or system as a whole. The common form is not necessarily an International Standard, but needs to be agreed by participating enterprises in order to elaborate these entities and build systems accordingly.EXAMPLE Examples of developing interoperability using an integrated approach are ISO 10303, ISO 19440 and OASIS/UNCEFACT ebXMLThe integrated approach assures consistency and coherence of the interoperating subsystems by focusing on the components that need to interact. These components are then designed and implemented using a common form (or standard) so that interoperability is seen as a designed-in quality. Interoperation between these various components is therefore obtained a priori without any interfacing effort. Subsystems that are integrated in this way have distinct and individual structure, behaviour, or boundaries, but their combined behaviour is perceived to be as one entity and is achieved by collaboration and coordination through the use of the common form.5.4.3 Unified approachIn the unified approach, a common meta-model, which is applicable for the participating entities and used as a common reference to map existing models’ syntax and semantics, shall be identified and detailed. This meta-model provides at least a reference vocabulary, but could be a complete ontology. Such a meta-model is not an executable entity. Instead, it s hall provide a means for semantic equivalence to enable mapping between entities. Using this meta-model, a translation between the constituent entities is then possible. However, that translation might involve the loss of some informati on because the participating entities can have different extensions or instantiations of the same meta-model.NOTE 1 The unified approach is particularly suitable when developing interoperability for collaborative or networkedenterprises. To be interoperable with networked business partners, a new company maps its own model or system to the neutral meta-model without the necessity to make changes on its own model or system. This approach has an advantage over the integrated approach because of the reduced efforts, time and cost in implementation. It is also suitable for a situation where a large company needs to interoperate with SMEs. Normally an SME works with more than one large company; to interoperate with different companies, the unified approach can be a suitable solution in that it facilitates coordination without requiring conformance to potentially conflicting processes or environments.NOTE 2 In the re-engineering situation, syntactic alignment can be achieved through a unified approach that uses a mapping function to create missing elements of the exchange items, but semantic alignment between partners can be very difficult. Therefore, re-engineering is more applicable to developing intra-enterprise interoperability.5.4.4 Federated approachIn the federated approach, there is no sufficiently capable common form or meta-model to guide the interaction between enterprises that need to interoperate . The lack of capability is often related to different terminologies or methodologies that need to be resolved by business entity interaction. While there can be a common understanding between the business entities, in the federated approach, no business entity imposes their own models, languages and methods of work.To establish interoperability, parties shall accommodate and adjust their operations. Interoperation can be supported by providing a priori information about the capabilities of the entities to be involved in the exchange or by employing agents to discover the needed information. Support for the a priori case can be provided by establishing entity capability profile s that hold syntactic and semantic information on both entity inputs and outputs. Interoperability can be established by mapping corresponding input and output information of the entities and identifying inconsistencies. Any remaining inconsistencies shall be resolved by manual interventions.This approach is more suitable for peer-to-peer situations, where each enterprise has resources for negotiation and compromise. The approach is particularly adapted to virtual enterprises, where diverse companies combine their resources and knowledge to manufacture a product for a limited duration.NOTE Using the federated approach to develop enterprise interoperability is most challenging. A main research area is development of a mapping factory that can generate on-demand customized “anybody-anywhere-anytime” mapping agents among existing systems. It is worth noting that a specific support for the federated approach is seen in entity profiles, which identify particular entity characteristics and properties relevant for interoperation (e.g. ISO 15745 and ISO 16100).