Our software-intensive and cyber-physical systems are becoming more complex because of added features. Model-Based Systems Engineering helps to manage the complexity by introducing models and analyses in a top-down design of the system. Appropriate formalisms and tools are used at each abstraction level to model requirements, architecture and behaviour. Most of these tools o er di erent visualisations of the models. However, there is not a lot of support in the visualisation of the design that spans di erent modelling formalisms and tools. In this paper we propose a solution based on domain-speci c languages. Our language de nes the operational steps needed to combine ( ltered) model elements together from di erent tools and map the resulting graph or tree to a visualisation template.
Our software-intensive and cyber-physical systems are becoming more complex because of added features such as autonomous decision making, energy e ciency, and safety requirements. This results in a systems design process where the number of requirements (and thus later in the process, the number of components) is increasing, the heterogeneity of the components that need to be combined is bigger, and the number of stakeholders involved in the design is larger.
Model-Based Systems Engineering tries to help in managing the complexity by introducing models and analyses in a top-down design of the system. Architectural models are used during the decomposition of the system while simulation at di erent levels of abstraction/approximation allows for system-level evaluations. However, the heterogeneity in the design results in a broad set of formalisms being used, usually implemented in their own tool. For example, geometric models to allow for nite element analysis can be modelled in NX Nastran, requirements are modelled within tools such as Polarion, AMESim for 1D multiphysics modelling of the plant, etc. Each of these tools o ers their own visualisation of the model and/or its behaviour.
Nonetheless, di erent stakeholders would often bene t from creating customised visualisations that span multiple models and tools. For example, a safety engineer might bene t from a visualisation that shows a combination of safety requirements linked to changes in the architecture to immediately see which parts of the architecture are changed in recent developments and how this might impact the safety functions. A quality engineer might bene t from a visualisation that links requirements, architecture, and test results and metrics that allows him/her to see where problems in quality might occur. Mid level managers might want to see requirements or architecture models together with data from version control systems to evaluate which parts are worked on by whom.
However, the exibility of creating visualisations over di erent models, modelling tools, and other process data sources is quite low. Visualisations are often o ered within a single tool environment where the link with other artefacts within the design project is hard or even impossible. This initial work tries to provide a small domain-speci c language that allows stakeholders to create their own personal visualisation based on a simple set of operations.
The rest of this paper is organised as follows: Section 2 introduces the running example used throughout the paper. Afterwards, Section 3 describes our preliminary approach to create stakeholder speci c visualisations. Next, we discuss our approach and its current implementation in Section 4. Section 5 provides an overview of related work. Finally, we conclude in Section 6. 2
New aircraft designs have shown a tendency towards More Electric Aircraft
(MEA) for some decades now [
In electro-mechanical actuators, an electric motor is directly responsible for
the drive of an actuator. Because of safety regulations in aeronautics, it is
important to develop jam-free EMA technologies in order to bene t from its
advantages and role in reducing production and maintenance costs [
Our running example is to create a domain-speci c visualisation for a safety engineer in the development an aeronautical actuator for load alleviation in aircraft wings. This visualisation allows the engineer to see the evolution of the requirements between di erent versions/time-stamps. This choice was guided by a the safety expert working on the electromechanical actuator to check whether to allow him to do change impact analysis on the de ned hazards and its rami cations on the architecture and safety functions.
In our running example, the Polarion tool captures the requirements. Polarion
is an Application Lifecycle Management (ALM) tool by Siemens with support
for iterative development, continuous integration and automated testing. 'Work
item' is an encompassing general term in Polarion for requirements, architectural
components and test cases alike [
At the time of writing, there are 983 requirements for the design of the actuator. An example of such requirement is as follows: The Ball Screw of the Electro-Mechanical Actuators of Wing Ailerons should have a weight of less than x grams. 3
Other models and tools (e.g. architecture models, etc.)
Visualisation Template Library graph
Title Attributes_list tree size color
The goal of this work is to develop a method to generate meaningful visualisations that span a multitude of formalisms and tools of the design of a complex system. Our approach uses a domain-speci c language to empower stakeholders in visualising their speci c concerns. Figure 1 shows an overview of of our domain-speci c visualisation approach.
The approach starts by identifying various data sources. The data can range from design contracts, speci cations, models, and repositories with a collection of various data. These sources are in short the providers of the model elements and all the data that can be traced to them. After this, a domain-speci c language (DSL) provides support of di erent operations to be performed on the subset of work items. The selection of elements to keep or remove is modelled by the stakeholder. Next, the remaining model elements (or data) from the di erent sources has to be linked to each other. Afterwards, the linked data (graph, forest, tree, etc.) have to mapped to the visualisation template and its attributes. Finally, the stakeholder-speci c visualisation is created, which is representative of his concerns. In our case, the visualisation in python code. 3.1
The visualisation library templates implement a number of general approaches for visualising the combined model elements. They are exible in the sense that the stakeholder can either de ne one themselves, or build up on existing templates. Figure 2 shows di erent visualisations using di erent visualisation templates. Figure 2a shows an impact analysis of a changed safety requirement. It includes the automatic simulation and testing of the safety properties to evaluate if the system is still safe. The template is a tree-layout where the properties that can change are the labels of the boxes and the color of the boxes. Figure 2b shows another type of impact analysis where the size of the impact is re ected in the size of the circle. The template is a graph template with di erent shapes. The color, size and label are attributes of the visualisation elements. (a)
Fig. 2: Visualisation template examples
INES_2
INES_1 Changed workitem Size of changed workitem is relative to the amount of impacted workitems
INES_0 INES_7 (b)
INES_4 INES_3
INES_5
INES_6 3.2
Using a domain-speci c language allows for problems to be solved closer to
the problem domain, instead of the solution domain. As such, a stakeholder
with their particular domain knowledge can generate a meaningful visualisation,
without having to understand the underlying workings of visualisations, which
is the solution domain. This means that the gap between a user's mental model
requires fewer steps to get to the result. It will form a more intuitive approach to
requesting the visualisations one is interested in. Rather than having a transformation
expert study the domain space, it is easier for the domain expert to become an
expert given the right tools. DSLs try to close this cognetive gap between the
problem and the solution [
Filter onProperty:string value:string
Source source:string type:enum
SVNDiff start_version:int end_version:int … 0..*
Block
MapToTemplate
MergeModels TraceabilityModel
BaysianReasoner
Figure 3 shows our initial language de nition for the visualisation tool.
The concept is based on causal-block diagrams [
The Source block allows to acquire the data that we need to create the heterogeneous model views. In our current approach we created custom parsers for the di erent modelling tools involved in the visualisation approach. Polarion is our primary source for requirements. It integrates a PostgreSQL database for the server its back-end data storage and provides di erent interfaces for other tools to interact with. The Polarion approach to requirements management has support for text-based, tool-centric as well as a hybrid de nition of requirements. The change logs of Subversion are parsed with regular expressions in order to detect which work items are adapted and what their location is within the repository.
MergeModel blocks allows us to combine the di erent heterogeneous
datasources. An explicit traceability model allows for the linking of the same elements
together. In our case the name of the requirement is explicitly traced to a le with
the same name (and hierarchy) in the SVN. If no such trace model is available,
reasoners such as a Baysian reasoner could be used to link the data together [
Di erent operation blocks are available to modify the context of the model. For example, the Filter block allows the modeller to lter out speci c blocks in the model based on an attribute or expression. In our running example, the lter is applied to lter out only the items that are tagged with \Author" tag in the Polarion requirements tools. The SVNDi block looks at the SVN-data that has been linked with a requirement and compares di erent versions. It tags the elements with a property "new, modi ed, unchanged or deleted" that can be visualised later.
Finally, the MapToTemplate allows the engineer to specify how the element types and properties map to visualisation types (e.g. shapes) and visualisation properties (e.g. size, color, text, etc.). In our visualisation, the forest of ltered requirements are mapped to a tree visualisation. The label of the box is mapped to the requirement ID. The color of the box is mapped to the SVNDi properties: green represents a new requirement, orange represents a modi ed requirement, red marks that the requirement is deleted and grey shows that the requirement is unchanged between two di erent versions. 3.3
We have chosen to generate code to visualise the di erent model elements and its template. Because of its rapid deployment and eased maintenance, we have chosen to use Python. This interactive visualisation tool is developed and implemented using a modi ed Cairo 4 library and the GTK+ library. Listing 1.1 shows the generated code for ltering Polarion requirements based on the speci ed properties in the model. In the example, only workitems that are of four speci c types are kept in the model.
Listing 1.1: Requirements Filter def filter main reqs ( workitems index ): for v in g[ workitems index ]. vertices (): if "sslrequirement" not in n workitems[ workitems index ][int(v)]. type and n "colrequirement" not in n workitems[ workitems index ][int(v)]. type and n "ailrequirement" not in n workitems[ workitems index ][int(v)]. type and n "syslrequirement" not in n workitems[ workitems index ][int(v)]. type:
hidden[ workitems index ][v] = True g[ workitems index ]. set vertex filter (hidden[ workitems index ], inverted=True) 4 https://www.cairographics.org 3.4
In our running example, we used the needs of a safety engineer as reference. The model for generating the visualisation is shown in Figure 4The visualisations and functionalities presented below re ect this decision. Our running example aimed at visualising the di erence between di erent versions of a subset of the requirements. Figure 5 shows the generated visualisation of the running example. The template is a tree-template, as it matches the hierarchy of the requirements. The colors shows the modi ed, deleted and added requirements in a single visualisation. This removes the burden on the safety engineer to go through the change logs or requirements repository. 4
When acquiring data, more attempts should be made towards using standardized
data exchange formats. In our case, we de ned custom parsers for acquiring the
SVN data and the Polarion data. De ning custom parsers for each available tool
is not viable. Therefore, standard exchange methods should be used to get the
data from the di erent tools. Open Services for Lifecycle Collaboration (OSLC)
is such a data linking technology [
The rst version of our domain-speci c language is very adapted towards solving certain visualisation problems within the scope of the safety engineer. However, the language should be adapted so it contains a lot more operations that are useful to the engineers de ning a visualisation. For example, even complex operations such as running the integrations tests or running a simulation and getting its results are useful to visualise. More templates should also be added, e.g. a template with gauges can show the progress of certain work-parts or the passing of tests. We will extend the language with these operations as new case studies for visualisation are done.
The usability of the language is not very high at this point. The engineer has
to pay attention that the properties to lter on are correctly spelled. Our syntax
directed editing tool, created with AToMPM [
The work closest to our approach is presented by Basole et al. [
Lastly, Weber and Weisbrod note the importance of user-adaptable views
to guide the speci cation process [
Stakeholder-speci c visualisations over the bounds of tools are useful for engineers to immediately observe important aspects of the design. However, currently there are not a lot of methods or tools available to allow such visualisations. In this work we tried to mend this gap by providing engineers with a domain-speci c language to visualise their interests in the design. While, it is still a preliminary language and implementation, we have shown that complex visualisations can be created. Our approach uses a data- ow language to shape the di erent models and merge them. Finally, the resulting graph or tree is mapped to a visualisation template such that model elements and its properties are mapped to visualisation elements and its properties.
This work is partially supported by the European Eureka project : Innovations in the development of electronic systems for Aeronautics (INES) and the Flemish VLAIO project INES.