5 methods for quality with high complexity

Increasing complexity places high demands on quality management. This is particularly the case when quality is concerned with (functional) safety. Embedded systems belong to the class of products where this is a major challenge. One of the reasons for this is that software is one of the main drivers of complexity. A typical example would be a control unit installed in a vehicle.

Prof. Peter Fromm from Darmstadt University of Applied Sciences recently gave a keynote speech on this topic. The following is a summary of the most important ideas, including the top 5 methods that support quality with high complexity.

Prof. Fromm gave the keynote speech entitled How to build a safe embedded system this year at the SAEC Dayswhich focuses on quality in the embedded environment. "SAEC" stands for "Safety & Security", "Agile Testing", "Embedded Testing" and "Clean Code". Here is the keynote speech (worth watching) on YouTube:

The keynote

The keynote begins with the question that has often been discussed here on the blog: What makes Software so special? These are the following four characteristics that distinguish software from electronic or mechanical solutions:

• Software enables complex and abstract problems to be solved quickly.
• Software enables reuse.
• Software can be easily changed - even during use.
• Customers expect software to be cheap (or free).

When it comes to quality, the focus is therefore also on software. Of course, there are also potential quality problems with mechanics and electronics. Nevertheless, we have developed well-functioning approaches to quality in mechanics and electronics over the decades. These approaches generally work and are much less drastically affected by the growth in complexity.

Good - Cheap - Fast: Pick Two

There are various parameters that affect software quality. As complexity increases, so does the number of bugs. However, this also applies to changes. Other parameters ensure good quality, for example experience - or even just the right training! Bugs are also discovered and corrected over time, which can have a positive effect on quality.

But one of the most important parameters is a good architecture, or a good design as a foundation for development. In practice, however, we unfortunately find many projects where this is exactly what is missing, often for economic reasons: THE team finished the previous project in "firefighting mode" and doesn't have the time and resources to create a proper foundation.

Functional safety

It's no wonder that topics such as the development of a security concept are often put on the back burner. This is not only due to a lack of resources: there is often a lack of understanding at the start of the project, which the team first develops during the project. When the time comes to implement the security concept, fundamental aspects of the design and architecture also need to be adapted. This is exactly what agile approaches. But reconciling this with strict legal requirements is not easy.

TOP 5 methods for clean code and architecture

To resolve this dilemma, Prof. Fromm falls back on tried and tested methods: because these 5 methods are not new. But they are more important than ever in mastering the challenges of complexity and quality. These are

The "Skinny Sheep" is a painting by Ivar Jacobson. The idea behind it is connected to the MVP related: Using a minimal but functioning system, the team can mitigate the most important project risks. The system is then expanded on this framework until it is complete. With this approach, we basically have an executable architecture.

There is often a cultural divide between hardware and software teams. However, this is a major problem for quality assurance. A concrete example: nowadays, the diagnosis of hardware problems is largely carried out in the software. However, close cooperation is also important in the other direction: the hardware must also monitor the software, for example with its own safety controller.

Prof. Fromm openly admitted that the design guidelines he presented date back to the 1970s: Clear responsibilities, loose coupling, good naming conventions and the like. The list starts in the video at minute 31.

That reminded me very much of the also very old Security Code of Practice. In a keynote speech in 2018, Haydn Povey lamented how much better off we would be if all developers followed these 13 simple rules.

What applies to the design should also apply to the program code. Code guidelines have also been around for many decades. Guidelines complement and support. They can neither supplement a good programmer nor replace code reviews. Nevertheless, programming guidelines are incredibly easy to implement and have a very good cost-benefit ratio. They can also be checked automatically in some cases, for example using static code analysis.

This brings us back to the beginning: one of the biggest drivers of quality problems in software are changes. Furthermore, a good architecture is the foundation for quality, especially with increasing complexity. It is therefore not enough to sketch out an architecture in a document in the first week that is already outdated a day later.

The solution approach presented by Prof. Fromm is called µRTE. This is an architectural approach with tool support. µRTE was developed by Thomas Barth, a student at the chair, on the basis of Eclipse. The µRTE website is still minimal at the moment, but will be expanded soon.

Anyone interested in µRTE can watch the video from minute 35. In the following, however, I would like to discuss the underlying, tool-independent idea.

A holistic approach to developing and maintaining the system architecture

Among other things, µRTE was inspired by AUTOSARwhich, however, is rather heavyweight. The goals should be:

• We need a holistic but easy-to-understand modeling concept for requirements, hardware and software.
• The focus is on the signal flow at application level.
• The runtime environment is generated from the model.
• The model enables part of the documentation to be generated.
• Sophisticated change and refactor operations must be supported

It may be clear from the list that even a Modern modeling tool has these capabilities. However, the first point (simple, understandable) requires extensive customization.

Inspired by SysML

µRTE uses a minimal subset of SysML. The following diagram gives an impression of a top-level functional model. Of course, there are other layers hidden behind the individual blocks and ports:

The idea of using only a small subset of a modeling language is not new. Here I immediately had to think of Capella/Arcadia, for which there is a separate Comparison with SysML gives.

Code generation makes it possible to stop software erosion

The term software erosion refers to the gradual deterioration of existing software. However, if the skeleton of the software can be regenerated with the updated architecture at the push of a button, we can prevent erosion. In the video we see how this works with µRTE. I have worked with code generation from modeling tools myself in the past. Once the development environment is set up correctly, it works amazingly well.

But the nice thing about models is that we can generate not only code, but also all kinds of other artifacts, especially documentation. In particular, all important stakeholders receive relevant, up-to-date documents, especially hardware development. The model describes the entire system and manages the split into hardware and software.

Focus on simplicity enables quality with high complexity

The charm of this approach is the simplicity and clear scope of the modeling. Many approaches, such as MagicGrid or Capella/Acardia seem to quickly overwhelm many users. This was the basis for my comment that SysML will have a niche existence for the next 10 years will lead to.

But regardless of this, many teams have the problem that they do not maintain the architecture. And often even worse: they don't know the architecture! And that is why the last (or first) point is not about a tool or a method. It's about making the architecture a first-class development artifact. This is essential in order to reconcile quality and complexity.

Image by Gerd Altmann from Pixabay