In my previous Blog post I've discussed aspects that significantly influence the design of a good software architecture. Here are just a few things to mention:
- Simplicity: Simpler is usually better
- Maintainability and extensibility: Software is rarely not “finished” even after the first delivery
- Testability: It goes without saying
Alisa has already discussed the aspect of unit testing in detail in connection with C# tool development (→ Unit testing in C#).
But do the rules for desktop development also apply to “hardcore” embedded software?
Bad examples
Everyone has probably encountered the "Kraut-und-Rüben" code at some point. Even if it was their own—at least during their apprenticeship.
Module A calls functions from module B. Module B calls functions from C, … and from X it goes back into A. A dream!
Why is that "bad"? So many projects do the same thing?
Well, first of all, after a short time nobody can see through such a ConfusionAnd when it comes to the maximum runtime of a function call, determining the maximum call chain (with all possible branches!) is no longer possible without tool support or a lot of effort. If there's also the risk of a watchdog triggering in the meantime, the watchdog is triggered at every possible and impossible point.
The icing on the cake is this: Another module needs to be integrated. Now, function calls to this module (and from it to other modules) need to be added in numerous places. Anyone who can predict how many places need to be addressed and how this will affect the increase in complexity or runtime behavior will receive the fortune-telling prize from the boss.
Learn from the successful
Why are bus technologies such as CAN (Controller Area Network) so successful? Well, there's a master, a few cables, and all the participants listen. Those who are interested can either view a message—or not. If, for example, a display module needs to be integrated, you simply connect it to the bus—and that's it.
Ask: What prevents one from using such a simple concept as a model for software architectures?
Answer: Nothing :-)
But what could something like that look like?
Sender → “stuff” → Receiver
Event-based architectures aren't rocket science and certainly nothing new. Among the more well-known examples are signal slot mechanisms (used in Qt). Under the hood, this can be quite complex and perhaps too powerful for hardcore embedded applications. Because we're dealing with tough constraints (although, that's precisely the appeal of embedded software development ;-)):
- We usually have to manage without dynamic memory allocations (→ all data/objects are static or allocated once at startup)
- Runtime: The overhead of such an architecture is low – but of course, nothing comes for free.
- Code size: We needed some administrative information under the hood here and there (e.g., for lists), but that shouldn't be a problem.
- …
But what do we need for a simple event-based solution?
- Events – without them, nothing works. These messages can be simple enum values or structures/classes with a payload.
- Listener: Components that want to be informed about events implement a listener interface and implement a “handleEvent” function.
- Event-Dispatcher: This component receives events and distributes them to all listeners that have registered with the dispatcher.
- Sender: These are all components that have something to say.
Figure 3 uses a real-life example to show how event handling works in principle.
It is certainly easy to see that it would not be rocket science to make other components react to the press of a button.
Finished? No, not yet
With the architectural principle presented, we have already come quite far and can achieve the initially formulated goals (simplicity, maintainability and extensibility, testability) in an elegant way.
If you think that's it, I'd like to put you off until the next blog posts. One topic hasn't been addressed yet: data storage.
So there's still something to be done :-)
Do you need support with designing a software architecture or developing embedded software? Then please contact us. Our experienced MEDtech engineers will be happy to help you develop your medical device or clarify any outstanding questions.
Best regards
Jürgen Welzenbach