Structure and Architecture

The high-level data flow of the Digital Engineering Hub, is based on E-TM-10-25 Annex C2 and C3. The overall architecture foresees a Digital Engineering Hub based on the hub-and-spokes pattern for Domain Specific Tool (DST) integration. A DST is an application used to run some form of analysis or simulation or do architecting with and exchange input/output with a Site Instance E-TM-10-25 source. The bi-directional exchange between the E-TM-10-25 source and the DST is taken care of by the DST Adapter. Capella is one of the DST's for which this software is an adapter. There are different types of DST Adapters, the Capella Adapter is a plugin adapter for Capella.

Common principles of adapters are

• Make use of an E-TM-10-25 SDK to provide the proper abstraction layer to interact with the E-TM-10-25 source, both in terms of Annex A (the meta-model) and Annex C.2 (the JSON REST API).

• Make use of the ExternalIdentifierMap and IdCorrespondence classes from E-TM-10-25 Annex A to map and keep track of the mapping between instances in the E-TM-10-25 Source and the DST.

• Make use of a DST/E-TM-10-25 MappingEngine and MappingRules which maps DST classes/types to E-TM-10-25 Annex A/B classes/types.

• DST Model and E-TM-10-25 Model, which is part of an E-TM-10-25 SDK, loaders to load the data and have in-memory representations that can be operated and queried on.

• Advanced UI to allow a user to visualize and navigate/browse the content of the DST and E-TM-10-25 models, view net exchange previews and allow selective transfer.

Every E-TM-10-25 Iteration can store an ExternalIdentifierMap per DST that it interacts with. Each map contains the reference to the tool, version and the DST model. Furthermore, it has a set of 0 to many IdCorrespondence elements, each creating a link between any E-TM-10-25 Thing in that Iteration and a string reference to the any sort of identification of the externally mapped element. After the first exchange when the mapping was established during operation of the DST adapter, this mapping can be saved to the hub. Upon every consequent exchange, the adapter can check whether previously established mappings exist, and if they do, use them. If any mapping change due to the user’s action, they will be updated. These concepts establish the mechanism of instance mapping.

Capella allows for runtime interaction with the adapter through the Capella libraries. The adapter is a plugin adapter written in Java 11. More specifically, using OpenJDK 11. It relies on an instance of Capella running. Conceptual mapping is established inside the MappingRules component of the adapter itself. This provides the lookup mechanism of which E-TM-10-25 concept maps to the DST concept and vice versa, as well as how their properties are exchanged.

The UserInterface component houses the business logic to handle the loading, exploration as well as the different viewpoints and all business logic associated with them. It interacts directly to the MappingEngine which processes the models. Externally, they interact with both the DST API as well as the E-TM-10-25 SDK, written in the language that is most appropriate for the type of plugin being implemented. Notable is the presence of the CommonUserInterface component which allows for segregation of non-DST-specific UI and functionality. Capella manages the DST meta-model in memory and take care of correct bidirectional interaction of the DST model. As discussed earlier, the information mapping and the interface with the E-TM-10-25 source will be handled by their respective components.

The Capella DST adapter will need to facilitate frequent exchange of large amounts of data between the adapter and the digital engineering hub. The nature of E-TM-10-25 Annex C predicts updates ranging from a few kB to several hundreds of MB. A full study is estimated to contain in the order of 1 GB of data according to analysis performed in design of OCDT. The largest transaction usually takes place upon opening a specific Iteration, which request all engineering model data at that point in time. Depending on the engineering model, at user session start-up a few hundreds of MB of data may need to be loaded by each client from the hub. Subsequent updates are transferred in the form of deltas between the current local revision and the latest server revision.

The communication with the digital engineering hub and the adapter will be facilitated using the common dynamic concepts:

REST (Representational State Transfer) because it provides the simplest clean webserver-like interface that natively uses HTTP or HTTPS. This makes it straightforward to configure, including for connections through the corporate firewalls of concurrent design facilities.

JSON (JavaScript Object Notation) provides the optimal compromise between expressiveness, object orientation, excellent support through OSS libraries for any programming language, self-description, reflection, flexibility, human readability.

As a fully integrated plugin to Capella, the adapter will not need any external extra libraries to facilitate interfacing to the DST. All the features will be available through the exposed plugin API, allowing to query and insert architectural elements. Integration into Capella will conform to normative plugin design specification outlined in Capella documentation here and the established interface described above. The new DST plugin class must extend have as dependencies org.polarsys.capella.core.model.helpers and org.polarsys.capella.core.model.handler packages and declare a so-called Feature. As such the new plugin class shall serve as the entrypoint to both the HubController and the DstController components.