EN 
DE MBSE in tightly budgeted projects
Author: Thomas Rogalski, enders engineers
Contribution – Embedded Software Engineering Congress 2015
The core of this article is a report on the use of model-based systems engineering (MBSE) in a completed customer project. The project's goal was the development and deployment of a braking vehicle with a braking power of 500 kilowatts. Right from the start, there was considerable debate about whether to use MBSE, what expectations should be placed on the model, and what form the methodology should and could take. These questions were particularly influenced by the tight project budget. It was therefore clear that the methodology had to be implemented as pragmatically and effectively as possible. This article discusses the early project phase, the implementation of MBSE, and provides a summary of the overall results.
Introductory remarks
„"We'd like a vehicle that can selectively brake our tractor unit with up to 500 kilowatts. Oh, and by the end of the year, please!" This task is solvable. With or without the use of MBSE. Which is better? There's certainly no single answer. The average systems engineer, based on their own convictions, will naturally advocate for the use of MBSE. However, the overall project manager might see things differently.
As a development service provider and systems integrator, enders Ingenieure GmbH relies on a closely integrated and well-coordinated interdisciplinary approach when developing complete mechatronic systems. MBSE is, in principle, precisely the right tool for this. However, since the project in question had a tight budget, the application of this methodology had to be carefully considered and planned accordingly.
Brake vehicle – Project presentation
Enders Ingenieure GmbH was commissioned by a leading agricultural machinery OEM to develop and fully deliver a special braking vehicle. The project was planned to take just under a year from commissioning to delivery. The vehicle's core function is to be attached to a tractor unit and apply a predetermined braking load via this direct mechanical connection. Peak braking loads of up to 500 kW are to be achieved. This vehicle will be used for measurement-based testing on the tractor unit.
The following is a brief outline of the basic technical concept (see Fig. 1, PDFThe braking vehicle (BFZ) essentially consists of a two-axle trailer attached to the tractor unit via a special drawbar. Braking force is generated by an eddy current brake and directly coupled to the two axles of the chassis via a gearbox. Due to the high power output of up to 500 kW, heat dissipation from the eddy current brake is achieved through water cooling. All electrical components are powered by a mobile diesel generator. The BFZ is controlled via an operator interface installed in the tractor unit's cab, which has a direct connection to the actual BFZ control unit located within the trailer.
MBSE – Selection and definition of the approach
The basic idea for the project was to use system modeling with SysML to support the concept phase. However, this idea first had to be agreed upon with the project participants and those ultimately responsible. More precisely, some convincing had to be done.
This proved challenging, not least because many of the participants had very little or no knowledge of the MBSE methodology and, in particular, of the SysML modeling language. This starting point significantly influenced the design of the chosen methodology. It was clear from the outset that everything had to be pragmatic and easy to understand. It should not feel like an additional burden or require a cumbersome learning curve. Furthermore, it was essential that the modeling could be implemented with minimal effort, given the very tight overall project budget.
The MBSE methodology used is scaled according to the project's framework and essentially comprises five steps (see Fig. 2, PDFThe individual points are presented as a sequence. However, the actual implementation is more iterative and incremental. Modeling the structure, for example, can have an impact on behavior, or a closer look at use cases can have repercussions for the requirements.
MBSE in Action – Use under real project conditions
Let's get down to brass tacks – how was the MBSE methodology, as outlined in principle, applied in the project? What benefits did this provide, and what complications did it entail?
1. Define goals and scope
The first and most important goal for using MBSE was, and remains, the structured support of the concept phase. Especially with such an interdisciplinary system, broad in scope both thematically and technically, a significant advantage can be gained here. It is essential to consolidate the requirements and avoid potential design errors early on. This statement is practically a truism. However, in tightly budgeted and strictly time-bound projects, it is all the more crucial to adhere to it.
Another goal of the model, and an argument for using MBSE, was that the defined functions and model content should serve as a conceptual basis for the software implementation of the mobile control system. The fundamental architecture of the software should be directly represented and contained within the system model.
The third and final goal was identified as the documentation of the system architecture. This aligns with the core idea of MBSE, which is to manage all information without redundancy in a single model.
One derived goal for the model and the application of MBSE with SysML was to create a model that was as easy to understand as possible. The aim was to use as few language elements as possible to minimize the learning curve for newcomers and to avoid making the model itself too complex. Figure 3 (see PDFThis section shows which SysML diagram types were omitted and which were used. Furthermore, care was taken to use a minimal set of elements in the diagram types that were employed. For example, ports were not used.
2. Requirements Engineering
Requirements management started based on the jointly defined specifications. From this, model-based solutions were developed (see Fig. 4, PDF) further requirements for the system were derived. In the model, these requirements were categorized into functional and non-functional requirements, as well as conditions.
Based on the core functions and the corresponding requirements, the fundamental testing and acceptance procedure was also defined in the model. In this way, aspects of verification and validation of the overall system were taken into account.
3. System context
An important step, which takes place at an early stage of the modeling process, is the representation of the system context. Here, the system is depicted as a black box within its relevant, surrounding context. At the same time, the first fundamental interfaces are defined here (see Fig. 5)., PDF).
4. System structure
Structural modeling represents the largest part of the overall model. Here, the vehicle's structure is broken down into its subcomponents and assemblies. In this way, the overall system is represented hierarchically. The mechanical and electrical elements, as well as their interaction, are addressed. Figure 6 (see PDFFigure 1, for example, shows a section of the structural model with an overview of the cooling circuit. It shows which components are part of the cooling system and how they are interconnected. Since cooling is a system-wide function, such an overview is particularly important.
Furthermore, the structural model describes the basic features of the software architecture for the control and regulation of the BFZ.
5. System behavior
The description of the system behavior is limited to two considerations. Firstly, the model includes a description of the system's core functions using use case diagrams. These diagrams provide a basic overview of aspects such as operation, fault handling, and vehicle diagnostics. A more detailed examination of specific functions is provided using state diagrams. These include, for example, the system and operating states (see Fig. 7)., PDF).
Looking back – How did it go?
In school terms: Good. Not very good, but definitely better than satisfactory. That much can certainly be said in summary.
What are the reasons why the use of MBSE in the project is not considered very successful in retrospect? Here are a few points worth mentioning that can serve as starting points for optimization in future projects.
The majority of development projects at enders Ingenieure GmbH are (still) carried out without the use of MBSE. Established and established work processes are document-oriented with regard to the management and provision of project information. Bills of materials for parts and components are therefore essential for efficient material procurement and assembly. However, the simultaneous use of the model and the bills of materials inevitably leads to data redundancy, as elements and individual items in the bill of materials sometimes correspond to elements in the model and vice versa. This contradicts the fundamental MBSE approach.
Another point of criticism, which relates more to communication and marketing, is the fact that SysML diagrams are somewhat too abstract for a truly high-level representation. Experience has shown that when communicating with end customers or those unfamiliar with the project, it is important to start and work with a visual level, i.e., to use actual graphical representations of objects and not just abstract boxes. This necessitates a hybrid modeling approach, in which such high-level overview diagrams are represented using non-formal modeling (see Figure 8)., PDF).
Another advantage of the model was its integrated software architecture. Because this was developed and documented at a very early stage of the project, the implementation of the control software could begin without extensive conceptual preparation. The progress and status of the implementation could always be tracked transparently using the model.
Finally, the cost-benefit ratio is discussed, along with the question of whether the use of MBSE is worthwhile in projects with tight budgets. These are the key questions for decision-makers. However, they cannot be easily answered in general terms.
Based on the presented project, it can be concluded that the effort was worthwhile. A sound, detailed technical concept was developed. It is very likely that several potential errors that could have occurred later were prevented and avoided.
The cost-benefit ratio was positive. In retrospect, it's difficult to say how much effort was attributable solely to the use of MBSE. However, if it's just the actual work on the model, it probably took several weeks. Considering the overall project duration, this investment is more than justified.
The initially reserved decision-makers have become true advocates of MBSE thanks to the project's progress and the results achieved. It has become clear that the benefits outweigh the costs.
Finally, the answer to the question posed in the title of the article must of course be omitted: MBSE is accelerating the development of 500 kW braking power!
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
