MODEL-BASED SYSTEMS ENGINEERING
Improve communication between engineers
What is Model-Based Systems Engineering?
Complexity arises when multiple system aspects are interconnected and need to be considered as a whole. Examples of tightly coupled system aspects are requirements, mechanics, electronics and software. Good communication between engineers from different disciplines is then the key to successfully designing complex systems. An efficient collaboration allows engineers to enhance their system understanding, to view and discuss ideas from different angles, to detect design flaws early on in the design process and to better understand the impact of changes.
Unfortunately, poor communication between engineers from different disciplines is still very common. Instead of focusing on the creation of better solutions, engineers often waste time trying to decode unclear system documentations and manually gathering information from multiple sources. Just as English is used for efficient communication between persons not sharing the same mother tongue, a common systems modeling language needs to be adopted for efficient communication between engineers from different disciplines.
How can you benefit from it?
The Systems Modeling Language (SysML) is an open standard for graphically describing, at a high level of abstraction, multiple system aspects including requirements, use cases, logical architecture, structure, behavior, and cross-cutting dependencies. SysML is supported by many modeling tools and is being used by more and more engineers for Model-Based Systems Engineering (MBSE).
MBSE is often tightly linked to activites such as trade-off studies and management of dependencies between models.
DEPENDENCIES BETWEEN MODELS
In complex systems design, models are not only used for documentation purposes but also for computer-based simulations allowing engineers to test system functions, validate requirements, detect design errors, and perform trade-off studies. Due to the complexity of each individual engineering discipline, engineers usually describe their knowledge in discipline-specific models. Examples of discipline-specific models are CAD models, dynamic system models and software models.
These discipline-specific models describe different aspects of the same system and therefore often share common information. As a result, discipline-specific models need to be viewed as a network of connected models in which a change in one model will have an impact on other models. The dependencies between the different models need to be formally defined in order to support traceability and consistency.
A central system model can describe parametric dependencies between different discipline-specific models. This allows engineers to visualize how a parametric change in one model will influence parameters in other models. Parametric dependencies defined in the central system model can be automatically solved by third-party mathematical tools in order to ensure consistency within the central system model. Other third-party tools can then synchronize a change in parameters in the central system model with the other discipline-specific models in order to ensure consistency across all models.
SysML is not only suitable for model-based systems engineering but also for the description of various discipline-specific models in a common central system model. Many discipline-specific models can be represented in a recognizable way in SysML allowing engineers to define dependencies between various discipline-specific models in a common central SysML model. Furthermore, SysML is an open standard in contrast to proprietary tool-specific modeling languages. As a result, engineers are able through a SysML-based integration framework to avoid tool vendor lock-in and save costs.
TRADE-OFF STUDIES
The preferred system configuration is usually the one that meets all requirements and constraints while being the most cost-effective. When systems can be composed of a wide range of different components, engineers need to evaluate different system alternatives in order to find the most suitable one. System alternatives are typically evaluated according to several criteria including performance, reliability, and cost. Designers can only select the most appropriate system configuration on the basis of reliable and precise information. For a complex system, the number of possible system alternatives as well as the effort to evaluate a system alternative can be extremely high. Designers can then no longer rely on intuition to find the best system configuration. Instead, engineers need to rely on computer-based simulations and automated processes for the efficient and precise evaluation of multiple system alternatives.
Typically, multiple models are created and simulated for the computer-based evaluation of a system. Performing trade-off studies requires the reconfiguration of models to describe and simulate new system alternatives. However, the manual reconfiguration of models by engineers is not efficient. Simulation models describe different aspects of the same system and therefore share common information. For example, changing parameter values in one model will require the update of parameter values in the other dependent models. Similarly, changing the structure of one model (e.g. adding/removing components) will require structural changes in the other dependent models. For the design of complex systems, simulation models are typically of large size and tightly coupled. The manual reconfiguration of models by engineers is then extremely time-consuming and error-prone. As a result, only few system alternatives can be evaluated and the chances of identifying the most suitable system configuration are dramatically reduced. Since trade-off studies require multiple model reconfigurations for the evaluation of multiple system alternatives, trade-off studies can only be performed efficiently if simulation models can be reconfigured efficiently.
Instead of relying on manual model reconfiguration, models can be efficiently reconfigured based on a common system description. A central system model, as described in the previous section on system data integration, can serve as a common system description capturing all shared simulation parameters as well as the parametric dependencies. As a result, a central system model can easily be used to ensure parametric consistency between different simulation models. Changes to parameter values in the central system model can be resolved through symbolic equation solvers provided by programs such as MATLAB, Mathematica, OpenModelica. The resolved parametric changes can then be propagated automatically to simulation models through (possibly standardized) synchronization tools. The central system model can thus efficiently support consistent parametric model reconfigurations and parametric trade-off studies.
In addition to parametric variability, system alternatives can also vary according to their topology (e.g. number of components and configuration). However, ensuring consistency between structures of different simulation models is not as easy as ensuring consistency between parameters of different simulation models. While parametric dependencies can be described through mathematical equations, structural dependencies are more complex to define. For example, adding a component in one model may require adding multiple components in other models in order to maintain consistency across all models. Depending on their complexity, structural dependencies may be defined either graphically within the central system model or textually in a separate code as in Java, the Atlas Transformation Language (ATL) or in the Query/View/Transformation (QVT) standard. Even though the definition and resolution of structural dependencies may be complex, the resolution of structural dependencies is facilitated by a central system model which can represent the reconfigurable structure of different simulation models in a common neutral format. Changes applied to the structure of the central system model can then be translated automatically and consistently to the various simulation models through (possibly standardized) synchronization tools. By supporting parametric as well as topological consistency between multiple simulation models, a central system model can efficiently support parametric and topological trade-off studies.
For the purpose of maintaining consistency between multiple simulation models, the central system model may have to integrate a lot of information. As a result, the central system model may become too cluttered and less understandable. A simpler description of a system configuration is then needed which only represents system components, component relationships and component parameters. This description, called the system architecture model, is easily understandable to engineers from different disciplines and is also easily reconfigurable since it is only composed of modular components specifically adapted to the reconfiguration needs of the trade-off study. In order to be computer-interpretable, the system architecture model should be described formally either in SysML or in a domain-specific modeling language. With the system architecture formally defined in a computer-interpretable language, maintaining consistency between multiple levels of abstraction in the representation of a system configuration can be performed in two steps. In a first step, the system architecture model is automatically translated into the central system model through a customized model transformation. In the second step, the central system model is automatically translated into the simulation models through standardized synchronization tools. By maintaining consistency between the system architecture model and the simulation models via a central system model, broad parametric and topological trade-off studies can be performed based on a more easily understandable and easily reconfigurable system architecture model.
A trade-off study is an iterative process composed of multiple steps: system alternative selection, system alternative modeling, model reconfiguration and model evaluation. As described in the sections above, each of these individual steps can be performed more efficiently through automation. Similarly, in order for a trade-off study to be performed more efficiently, the process itself needs to be automated. Software code can describe and automate a trade-off study. However, not many stakeholders will then be able to understand and customize the trade-off study. Since simulation models need to be reconfigured and evaluated in a specific sequence for each trade-off study (e.g. geometric model before dynamic system model), engineers would benefit from a graphical overview of trade-off study steps. In addition, engineers would like to easily control the degrees of freedom such as choice of variable parameters, range of parameter values and set of possible topological modifications (e.g. adding, removing and replacing components). A trade-off study should therefore be described graphically in a SysML/UML activity diagram or in a similar formal flowchart diagram representing both the sequence of process steps and the degrees of freedom. Customized software can then support the translation of the diagram into executable code in order to automatically run a trade-off study including multiple model reconfiguration and evaluation steps.
Why Koneksys?
Koneksys has extensive experience in using SysML to drive following processes:
- System Architecture Modeling
- Supporting Parametric Trade-Off Studies
- Supporting Topological Trade-Off Studies
- Visualizing and Automating Trade-Off Studies (executable activity diagrams)
- Translation of a system architecture model into simulation models (CAD, FEA, multibody-system models, controller models, etc.)
Have any question? Please get in touch!
PHONE
Don't hesitate to subscribe to our newsletter!
We provide software solutions and consulting based on state-of-the-art non-proprietary web technologies for data traceability, data integration, and data interoperability.