Experience of an Embedded Developer Reasons Why MBSE Does Not Use Its Potential

Related Vendors

FAULHABER Drive Systems

dataTec AG

Wuxi InfiMotion Technology Co., Ltd.

Model-Based Systems Engineering (MBSE) is the buzzword on everyone's lips across the industry. Larger corporations in particular are increasingly relying on model-based development. Is this a major trend for the future - or is it just a fad? What are the potentials and challenges of MBSE?

A company's employees have a lot to do before an original product idea becomes the finished result. The efforts of many different departments must be pooled so that every cog in the machine meshes and "the left hand doesn't know what the right hand is doing" is avoided.

The lack of coordination between trades often leads to misunderstandings. It is not uncommon for things to be implemented inconsistently, twice or not at all during the course of a project. The consequence: development times and the completion of products are extended, valuable resources such as time and money are wasted.

With the Systems Engineer, a role has been found to identify all interfaces between the departments involved and then record and coordinate all requirements. Instead of often text-based documents from different software tools, MBSE (Model-Based Systems Engineering) is used to describe complex systems with standardized formal models. Today, UML-based SysML is usually used for this purpose. However, this is not the ultimate all-purpose solution: all-encompassing enterprise modeling with SysML, for example, certainly does not make sense, even if the idea of having a digital twin of an entire company may seem appealing.

Rather, MBSE is used profitably when a company uses it to find out which components can be developed and used as identical parts for different product groups. This prevents things from being developed twice purely due to coordination hurdles. The aim should always be to effectively eliminate waste of development resources and promote development efficiency.

Most of all, however, MBSE should find the product features that are to be implemented in development. It is therefore more about finding requirements and solution approaches. Unfortunately, in practice it can be observed all too often that the working method, the procedure and the work-oriented end product of MBSE do not reach the minds of electronics developers. There are several reasons for this:

Mismatch between MBSE competence and core competence

The system engineers have the method and tool expertise when it comes to model-based system development. However, the technical, company-specific core competence lies with the long-established developers. For a meaningful application of model-based systems engineering, it is precisely these developers who should actually use the corresponding methods and tools for MBSE and document the history.

Practice shows: As a rule, hardly any developers become system engineers. A developer is often indispensable in product development. Young, up-and-coming systems engineers with methodological and tool expertise find it difficult to create new models that incorporate all the knowledge of the past. In the author's experience, MBSE therefore usually only works with great difficulty for existing or follow-up projects. Technological paradigm shifts with the help of MBSE are possible in principle. But the right mindset must be anchored from the outset, which is often difficult to implement with long-established development teams. In innovation projects, on the other hand, where you can start from a greenfield site, this works much better.

Branches of development are diverging

The development of models and software is progressing at different speeds. This means that progress in these two areas of development inevitably diverges. It is very difficult to keep this synchronized at all times.

If this cannot be maintained, the consequence is that the MBSE team and the software team become estranged. Effectively, two teams are then working on two development threads. But then we are no longer talking about collaboration - the development team then effectively pursues its own approach again, and the work products from MBSE do not reach the minds of the developers. The work of the system engineer was effectively in vain.

Method and tool evolution

Methods and tools are constantly evolving. While they have only been subject to minor changes on the programming side for years, the methods and tools are constantly in flux. For example, it has been clear for some time that SysML 2.0 is coming - but it is not yet clear whether it will also be based on UML or not.

When a new version is released, and on a different basis at that: What will happen to the old models? Are there migration strategies?

If a developer is not already familiar with MBSE, a lot is required of him: he must master development methods and tools and also keep pace with the evolution of MBSE on-board resources. This is additional work, but it hinders the developer's development work.

Interoperability of the tools used

It is nice when a product property that has been determined as a requirement is also implemented in the end. Unfortunately, the chain of development tools from the model to the requirements tools and development tools to the test environment is usually not uniform in practice.

Ideally, there should be interoperability and traceability between the tools (traceabilizy). Unfortunately, this usually only exists in the form of export and import functions or, worse still, data has to be manually transferred from one tool to another. The potential for errors here is very high and delays development.

Perception of MBSE as a detour

MBSE extends the development chain. A model is first created before programming. Software components are then identified from this model and fitted into the software architecture. The models are often only a subset of the overall functionality. In such cases, this means that the developer develops parts of the software with and parts of the software without MBSE.

Only when the time for implementation has come can the software developer determine whether the model he is adopting really fits his vision and works in his environment. Unfortunately, many MBSE approaches do not allow the function of the models to be tested. Whether a model works correctly can only be determined after integration. If errors then occur, which is to be expected, the model must first be adapted. Then a new integration takes place and the cycle starts all over again. Is this loop really necessary for a fast development process, or is it additional work?

In principle, a programmer can generate code directly from the requirements. If he does his job well, it can be read like a book. Why then, some software developers think, is a further description necessary - doesn't that create additional work?

The most serious problem is that developers usually see MBSE as a detour. They are used to being able to implement requirements - whether classic or agile - directly and immediately test whether the product property is fulfilled. So why choose a different form of description first?

This impression is all the more reinforced when you consider, as described above, that tool and basic versions such as UML 1.0, 2.0 or 2.5.1 are also changing or becoming more and more extensive.

Budget and personnel issues

Introducing model-based system engineering initially costs money - and good MBSE experts also come at a price. The ratio of MBSE experts to the rest of the team is often unfavorable from the company's point of view. The desire to save costs, especially at the start of a project, is always great. As a result, the number of tools or MBSE experts involved in the project is often kept as small as possible.

However, if there is only one or a few MBSE experts in the team and the task is extensive, this headcount is not sufficient to develop models quickly or to react quickly to changes. So if savings are made at this point, model-based system engineering cannot successfully contribute to the success of the project.

What could MBSE do better?

The following conclusion can be drawn with regard to the various aspects: Developers need good and structured preparatory work for programming. They usually have to do this themselves.

It would be desirable if there were documents and models that describe the product features with good accuracy and completeness, so that the software developer can complete his programming tasks without much questioning. The tester is also able to create an equally correct and complete test specification and to test with a good test depth.

In the past, there was a research and development department and a pre-development department upstream of series development. Good preliminary work was done there. The developer was able to benefit from the experience and the development of the end product worked satisfactorily to well. This idea should also be applied to model-based system engineering in order to keep an eye on complexity and interrelationships right from the start. MBSE, which would function upstream as R&D with pre-development, would therefore be very promising today.

* Thomas Lachtrup is Managing Director of digithings GmbH, a provider of embedded hardware and software development. His company has made it its mission to complete even stalled and financially costly projects quickly and successfully. "We have learned from the experiences described above and have now dispensed with MBSE."

As a success factor for digithings GmbH, he attributes particular importance to Paderborn as a business location, which offers ideal conditions for technological innovation with over 300 IT companies. The combination of tradition and innovation, support from local institutions and close cooperation with scientific institutions create an environment in which companies like digithings GmbH can flourish. "We are proud to be part of this dynamic and future-oriented region," emphasizes Lachtrup.

(sg)