Interoperability between SE tools (HUBx)
Now you have the possibility to download “Extended Interoperability: A Methodological Approach” as an E-book:
Extended Interoperability: A Methodological Approach
Current needs in the field of Systems Engineering
Systems Engineering is a demanding discipline that aims at orchestrating the activities of many professionals, from different disciplines, using a wide variety of file formats and tools, in most cases from dvariousvendors, and not always designed to provide seamless connectivity. Therefore, most Systems Engineering projects involve many tools, file formats, modeling languages, and other diverse aspects which pose the challenge of integrating all the assets to maintain the digital thread and ensure traceability across the system life cycle.
This becomes even more challenging when considering our complex organizations, and interactions with third-party entities, partners, customers, and suppliers.
Braking silos between tools, repositories, disciplines, lifecycle stages, departments, and even organizations represents a must in any modern systems engineering project and requires a change of mindset when it comes to the definition of the toolchains.
The larger the number of disciplines involved in a digital project, the more complicated it is to design and maintain a digital thread connecting all of them. Furthermore, the idea of minimizing the number of dependencies just by concentrating different sorts of information into one single tool has also been demonstrated to be an even bigger problem, since the tools required by every discipline need to be very specialized so that the expected features can be offered to the engineers.
Engineers do not need another new tool with more capabilities, but a way to interconnect and interoperate all the existing tools. That is, the different pieces of information forming a complete systems engineering project do not need to be centralized, they must persist in their repositories, managed by the best possible tool to cope with this particular type of information (ASoT – Authoritative Source of Truth) and, on top of that, an interoperability layer – the Interoperability Hub – needs to be implemented to connect and synchronize all the different sources (SSoT – Synchronized Source of Truth).
This Interoperability layer, the SSoT, shall provide not only connectivity among the different involved tools, formats, and repositories, but it should also provide a series of services such as semantic authoring tools to help authors cope with the principle “right the first time”, quality inspection for different types of artifacts, verification & validation, global change control and configuration management, cost-to-cost traceability including matrices and impact analysis, risk analysis for different sorts of information, information and knowledge management…. and several transversal processes that can be understood as Technical Management Processes.
How a SMART interoperability system can help meet these needs
Let us now identify the pillars that might uphold all this infrastructure. According to our approach, there are 6 main pillars.
These 6 pillars represent the core of the INTEROPERABILTY Hub promoted by The REUSE Company and aiming at offering a passport towards a digital thread without frontiers. Let’s discuss, one by one, all these pillars.
Pillar 1 – Connectivity
The first pillar of the Interoperability Hub corresponds to the ability of SES ENGINEERING Studio to connect to +50 different tools. From Requirements Management to MBSE tools, through ALM, PLM, MS Office, PDF, and others… This Hub avoids point-to-point connectivity by providing a standard representation of the sources and maintaining a SSoT (Synchronized Sources of Truth).
The Hub represents a canonical representation for different sorts of artifacts such as requirements, risks, tests, conceptual models, physical models for different disciplines (Mechanics, Thermal, Electronics, Software…), simulation models… This canonical representation must be always in-sync with the real source, therefore, as soon as a document is connected into SES ENGINEERING Studio, a synchronization/reconciliation must be always done, highlighting changes, and offering other operations to deal with changes (as will be presented in the next sections):
Connecting a tool to the Hub represents the implementation of a bi-directional transformation from the corresponding tool (or file format), into the canonical representation model of the Hub. When possible, this transformation will use the APIs provided by the target tool; furthermore, the Hub implements mechanisms to promote a quick implementation of the transformation for other additional tools, so that this list can be easily extended when new tools require to be part of the Hub.
Pillar 2 – Semantic Traceability
Starting with the set of connectors to different tools, the Interoperability Hub relies on SES ENGINEERING Studio which features a complete traceability module, that allows to establish and manage traces among any of the tools and formats that can be connected in the first pillar.
That is, do you receive regulation from a regulatory body in PDF format? The Hub includes semantic modules to provide SMART parsing of unstructured sources, identifying the meaningful blocks, and transforming those blocks into configuration items into the Hub. From this moment on, you can trace a piece of regulation to one of your system-level requirements into a tool such as PTC Codebeamer or other RMS, then derive this requirement into a sub-system requirement, connect a model developed in Capella and trace your requirements to Capella elements, generate your test plan into a tool such as V&V Studio1, MS Excel, or any other testing tool and trace your tests to your requirements. All these traces can be created with the click of a button, connecting to the real source of each of the items, and keeping the traces into the ontology that conforms the core of the Interoperability Hub.
Changes, that are inevitable and will sooner or later pop up, will alert about the suspicious links generated in the Hub. Therefore, the traceability capability of the Interoperability Hub and SES ENGINEERING Studio feature a graphical representation of the change impact.
This traceability capability is not only offering the possibility to create traces among multiple different tools and repositories, but it also offers the typical impact analysis, traceability matrices… Furthermore, this tool has been designed on top of a semantic ontology and embracing different artificial intelligence methods capable of suggesting new traces, thus easing the required but demanding traceability activities.
Pillar 3 – Synchronization of sources
Traces created among different sources minimize the need for making copies of a set of artifacts in a tool, to be copied into another tool (most of the types only with the purpose of establishing traces).
Anyhow, there are still multiple scenarios that requires information in a tool to be somehow transferred (copied, appended, synchronized) to other tools.
An example of this synchronization of information is found when two different partners are collaboration in the same project. Consider now that the first partner is using a tool like Capella to do conceptual modelling, but the other partner is using any other tool. With the synchronization capability of the Interoperability Hub information in a modelling tool can be easily transformed into a different modelling tool. Furthermore, when both partners contribute to the same model, the Hub implements a sync mechanism to reconcile all these changes, thus allowing to close the change/Sync loop as many times as needed.
The mapping between source and target is fully customizable. Along with the items themselves, one or more attributes in the source can be synchronized with the target. Also, the Hub allows to filter the synchronized elements using attributes, types of objects, stereotypes, the location of the item within a specific package, or even the presence in a specific type of diagram… In such a way, the elements that match the filter in the source can be transformed into a specific element in the target, while other similar objects from the source, but not meeting the filter, could be transformed into a different way. This represents an answer to the flexibility that real-life documentation (mainly models) normally require.
Another interesting example could be the implementation of the so-called Zig-Zag model. In this model, despite the fact that the Interoperability Hub allows traces between different tools, some engineers prefer to develop requirements into a Requirements Management System, to be than transferred into a modeling tool where the logical architecture is defined. Into the MBSE tool, requirements (the “copy” from the real requirements, still in the RMS) are traced to model elements (components, functions, states/modes…), this architectural definition might provoke the need for additional requirements derived from the architectonic decisions, as well as some other changes to other of the already existing requirements. Once the first layer of architecture is finish, including the traces requirements-models, the Interoperability Hub can take a delta of the requirements document (the edited requirements, the new requirements derived from architecture…), together with the traces, and reconciliate this delta with the real source-of-truth of the requirements, still into the RMS.
As the recursiveness is applied to continue with the different layers of decomposition of the system, this process of exchange and synchronization between requirements and models is executed over and over; this is the source of the name zig-zag model.
Pillar 4 – Transformations
In the cases described above, there is no need for any further semantic transformation; that is, the metamodel of the requirements in the source, the RMS, remains the same in the target, the MBSE tool. Same for the MBSE transformation described at the beginning of the previous section.
However, this doesn’t have to be always the same. The Interoperability Hub also takes advantage of a semantic engine, empowered by an ontology, to deal with more sophisticated transformations. An example of this could be the transformation between Capella models, and another SysML-based MBSE tool; since Capella is not using the SysML language, transforming a Capella model into another SysML model requires some sort of semantic transformation. The Interoperability Hub implements, out-of-the-box, all the typical transformations defined by the Arcadia method, but it also provides the possibility to more precise transformation.
Other example of transformation implemented into the Hub is, for instance, the generation of textual requirements starting with a model. In the figure below a state chart is transformed from a MBSE tool into a textual specification into a requirements management system.
The opposite transformation, where models into a MBSE tool are generated automatically from a textual specification into an RMS is also possible with the Interoperability Hub.
Other transformations are also possible. Here are just some examples:
- Automatic re-writing of requirements to meet with the rules in the INCOSE Guide to Writing Requirements
- Generation of test cases from textual requirements
- Extraction of controlled vocabulary from a textual specification
- Translation of Requirements between different languages
P5 – Binding
Semantic binding represents one more step in combination with the semantic traceability or the transformations (that also generate implicitly a trace relationship between the source and the target element). A binding represents the possibility to propagate changes when a linked element is changed.
Let’s focus on a very simple yet powerful example. A traceability module between a requirements document and a model is generated; within this module, either manually or semantically/automatically a requirement is traced/bound to a model element. If the architect modifies the name of the element in the model, the tool will start by showing what is the impact of this change, that is, what are the elements affected because they are connected through traces to the modified element. Once the architect agrees with the impact of the change, he or she will be offered with the possibility to propagate this change in the name of the element, that is, all the textual requirements even into a different tool (a RMS) shall be modified according to the change in the name of the model element.
Pillar 6 – Proxy
This represents the final pillar of the Interoperability Hub. However, being the last one does not mean that it was less important. All the bindings, traces, transformations… mentioned in the previous pillars are not easy without a semantic tool; however, life is normally even more complicated than this when the tools to be connected are in different infrastructures.
Let’s assume that a company has a complete set of tools suitable for different disciplines, and another division within the same company has decided to implement a slightly different set of tools. The Synchronization and transformation Operations defined in the paragraphs above shall require the interconnection of different networks and IT infrastructures. That is why this Proxy layer of the Interoperability Hub allows synchronizations and transformations where one of the ends acts as a Server, and opens the possibility for granted users of the Client side to connect and operate.
And this could be complicated even more: what if the interoperability operations are required between two different partners working on the same project, or even between a customer (let’s say, an OEM) and providers (the tier-1 companies)?
The combination of the SES ENGINEERING Studio acting as Proxy (the server side) and allowing remote connections in the client side, allows to synchronize local documents with remote documents to promote concurrent editing of documents across different departments or organizations.
Even the technological frontiers between companies are not a problem for the Interoperability Hub, what allows a Passport towards a Digital Thread without frontiers.
A passport towards a Digital Thread without frontiers: need for TMPs
All this approach requires some additional layers before it can be considered as a complete Digital Thread enabler.
As mentioned above, a series of Technical Management Processes shall enrich the operations with the Interoperability Hub itself, and with the different tools conforming the tool ecosystem. Some of the enriching TMP are the following:
Quality Inspection
Every work product generated all along the lifecycle shall conform with a set of drafting rules agreed between the quality department and the engineering departments. This being a must for every item, it is even more important when those items are to be shared across different departments or different organizations.
SES ENGINEERING Studio includes a module called QUALITY Studio. This module allows for the definition of checking rules for requirements, logical models, physical models… Starting with rules stated in well-known standards and guidelines (INCOSE, ISO, ECSS, NASA…), the tool allows a complete tailoring of the rules, and the agreement of different of rules for the different documents if necessary.
Thus, prior to any exchange, the Interoperability Hub methodology reinforces the idea of checking that every artifact meets with the agreed drafting recommendations.
More information about the QUALITY Studio: https://www.reusecompany.com/rqa-quality-studio
SMART Authoring Assisstants
Considering the importance of adherence to drafting standards, the sooner this can be checked, the better. That is why SES ENGINEERING Studio also includes an add-in, not to inspect a document once it is baselined, but from the very first writing of the document.
This is the notion behind the RAT – Rich Authoring Tool, that assists, in real-time, with the rules mentioned and established in the previous section, plus the help of requirements patterns (aka boilerplates) to guide users in combination with the controlled vocabulary that might come either from the domain ontology, from a model, or from both at the same time.
This SMART Authoring Assistants not only helps authors in the demanding activity of creating requirements or architectures, but also minimizes the time required for both formal and informal inspections.
More information about the REQUIREMENTS Authoring: https://www.reusecompany.com/rat-authoring-tools
Verification and Validation
Once a work product has been produced with the help of a SMART Authoring Assistant, and the quality control team has determined automatically whether it conforms with the minimum sets of quality characteristics, a more manual V&V process shall be performed.
This process is fully implemented into the V&V Studio module of SES ENGINEERING Studio, and covers the typical stages required to capture and manage evidences such as: 1) Prepare for inspection, 2) perform inspections, 3) report inspection evidence
More information about the V&V Studio: https://www.reusecompany.com/v-v-studio-verification-and-validation
Decision Management
When all the information for a given project is connected within the same Interoperability Hub, the possibilities to include Artificial Intelligence algorithms with different purposes grows exponentially.
SES INGENEERING Studio includes a Decision Management module that represents a workbench that includes many well-known AI methods. Those methods can be combined into workflows that permits to pipeline operations such as the collection of data, the introduction of additional parameters, the execution of one or more pipelined algorithms, and the preparation of reports including the evidence used to obtain such conclusions.
Examples of operations with the DMS module of SES ENGINEERING Studio might be:
- The automatic extraction of a domain specific vocabulary starting with a set of textual requirements
- The classification of requirements according to multiple criteria
- The identification of mismatching information in a project
- The trade-off analysis of different architectural decisions
- …
Configuration Management
Configuration Management is a must in every project. That is why most of the tools already used by the engineering companies already provide such capability. However, there might be two possible problems for these tools:
- When engineers are using other non-engineering-oriented tools or file formats such as MS Office, PDF…
- Configuration management represented as a whole, for a complete project, and not as a document-oriented or tool-oriented concept
For this reason, SES ENGINERING Studio offers Configuration Management capabilities at two levels, first for any of the source connected to the Hub, but also it can manage a global configuration for an entire project.
More information about Configuration Management, a capability within SES ENGINEERING Studio: https://www.reusecompany.com/ses-engineering-studio
Information Management
Every piece of information exchange along the Interoperability Hub is subject to be retrieved and reused. Once a work product has been successfully inspected to demonstrate that it meets the drafting rules attached to it, it will be semantically indexed and stored in the semantic search engine of the Interoperability Hub. This will enable authorized individuals to query the system and obtain those work products thare are relevant to his/her query.
Transferring the retrieved item into a new project involves a series of steps: 1) verifying whether this item also conforms with the quality rules agreed for the target project, 2) select which pieces of the retrieved element are to be transferred, 3) follow traceability links to try to discover other items also valuable for the target project…
Digitalizing the Project Workflow: the cherry on the Interoperability cake
As a final orchestrator for all these activities, SES ENGINEERING Studio is offering the possibility to manage the flow of the different activities in a project.
Each of the activities is defined in the tool. Every input and every output for a given activity is represented by means of one connector in the Interoperability Hub. In this way, all the activities shall be under control, and enriched with all the Technical Management Process mentioned in the previous section.
