9.2 Case Study on Extensibility
The Liebherr Case Study was conducted within the SPES-XT project2. The study object was a flight control system. The purpose of the collaboration between Lieb-herr and fortiss was to develop methods that facilitate the synthesis of deployments for flight control systems. In particular, the automatic deployment generation for Liebherr flight controls was investigated. This deployment must fulfill various re-quirements with respect to safety, communication, storage and timing. For modeling and deployment generation, AutoFOCUS3 was used.
9.2.1 Study Object
Modern aircraft must satisfy strict requirements on safety, performance and secu-rity. New functionality in their software often requires additional hardware. Any increase in hardware must be accommodated within limited space. Furthermore, it increases production costs, aircraft weight and power requirements. To address these challenges, modern aircraft architectures include complex embedded cyber-physical systems. An example is the flight control system, which is responsible for the mov-able surfaces that control the aircraft’s direction in flight. The study object is a flight control system developed by Liebherr. For this case study, Liebherr provided a set of requirements that constrain the deployment of the flight control system. Based on these requirements, deployments had to be synthesized for different configurations of software applications and execution platforms.
9.2.2 Research Objectives
The goal of the part of the case study presented here was to show the extensibility of the MIRA artifact reference structure and tool. The Liebherr Case Study extended the MIRA artifact reference structure and its implementation in the MIRA tool to be able to specify domain-specific requirements and to trace these requirements to sub-sequent component architectures. In order to document the respective requirements, MIRA was extended with a set of templates for project-specific requirement types.
The extensibility of the MIRA artifact reference structure and tool regarding new re-quirement types was evaluated. This case study is presented more briefly compared to the first case study, as it only demonstrates this specific aspect of MIRA.
9.2.3 Study Design
The case study was conducted using the tool AutoFOCUS3. The MIRA tool is im-plemented as a plug-in for AutoFOCUS3. Accordingly, the requirement types were implemented and the requirements were modeled using AutoFOCUS3. A staff mem-ber of the same research group as the author conducted the implementation of the extensions.
2http://spes2020.informatik.tu-muenchen.de/spes_xt-home.html
9.2.4 Results
MIRA Extensions. In the scope of the Liebherr case study, four requirement types were distinguished; communication, storage, safety and timing. The MIRA artifact reference structure (implemented in the MIRA tool as an EMF model) for the new re-quirement types was developed by inheriting from the genericrequirement. Fig-ure 9.15shows the definition of the Liebherr requirements. The new requirement types were annotated with specific attributes, for example, a communication require-ment should contain the communication type and the amount of bandwidth needed.
No additional changes on the artifact reference structure were necessary.
Figure 9.15:EMF models for the Liebherr requirements
GUI Extensions. The new requirement types were included in the GUI of Auto-FOCUS3 by defining those elements which were required by the AutoAuto-FOCUS3 mod-eling framework. For the GUI representation of requirements only the detail section of the existing requirements template had to be extended with the specific Liebherr attributes. Figure 9.16shows the requirement menu that includes the Liebherr re-quirements.
Extension of MIRA Operations. No further extensions on the MIRA operations were necessary.
Size of the Case Study. Each software component of the Liebherr study object must satisfy several requirements and often more than one requirement of a particu-lar type. Figure9.17shows the requirements created for a software application. This component claims bandwidth on three distinct interconnects and also requires three
9.2 Case Study on Extensibility
Figure 9.16:Requirement menu
separate blocks of memory. In the Liebherr model, a component is always associated with at least seven to eight requirements. Based on these requirements, deployments could be synthesized for several configurations of software applications and execu-tion platforms. The largest configuraexecu-tion contained 25 software applicaexecu-tions with 190 requirements and 25 execution platforms.
Figure 9.17:Requirements of a control loop software application
Perceived Difficulty of the Extension. The work needed to extend the require-ment framework was simple and intuitive, mostly driven by the AutoFOCUS3 devel-opment conventions. It was sufficient to extend the requirements data model and the GUI as described above. No new functions needed to be implemented in AutoFO-CUS3 for the integration of the new requirement types. Moreover, for this case study the existing tracing links between requirements and components could be used. The case study could benefit from the fact that requirements of the same type could be modeled easily, which was an important feature that the MIRA framework offered.
9.2.5 Threats to Validity and Limitations
Experience with the MIRA Approach. The researcher was familiar with the MIRA approach, but not particularly experienced in the MIRA approach, in AutoFO-CUS3 development or involved in the previous development activities of MIRA.
Implementation Support. During the implementation, the researcher was sup-ported by the developers of the MIRA tool. The collaboration helped the researcher to identify the extension points more quickly. This may influence the perceived facil-ity of the extension.
Domain. The researcher evaluated the extensibility in one case study in the flight control system domain. In order to generalize the results, several case studies in different domains would need to be conducted.
Coverage of the MIRA Approach. The case study reflects the extensibility of new kinds of requirement types by adding additional templates for these types. No ad-ditional formal models or new kinds of operation on the artifact reference structure were added. The case study did not formalize requirements to a formal representa-tion. In order to generalize the results, several case studies would need to be con-ducted that extend different aspects of MIRA.
9.2.6 Summary
The Liebherr Case Study showed that an extension of MIRA with new requirements types is possible within few steps. The use of the MIRA tool facilitated the devel-opment and specification of domain-specific templates for requirements (commu-nication, storage, safety, timing) as well as tracing them to subsequent component architectures.