OO strategies for embedded systems

A lot of embedded software projects are implemented without modern techniques of object orientation. While in PC and server software theese are inevitable and state of the art, the embedded software industry is lacking behind. There is no justification for this on systems are driven by high speed ARM cores and hundreds of megabytes of memory.

Take your software to the next level by utilizing modern OO strategies as:
– S.O.L.I.D.
– Application Wiring
– Onion Architecture
– Code Generation

The following presentation gives you an overview to this productivity boosters:

All this is taken from real-world embedded projects. Once you utilized this, people will become more productive, mainly by writing and testing code mostly on the development PC and seldom in the lab/on the target.

Onion Architecture for the Internet of Things (IoT): The Protocol Translator

The Internet of Things (IoT) is on everybody’s lips these days. I’ve been confronted with IoT architectures since more or less 10 years now, and the biggest topics are:

  • Companies must react very fast. Windows of opportunity are opening and closing faster than ever. Today some IoT standard might be hot, and tomorrow it is superseeded by a bigger player.
  • Devices must support different and overlapping standards.
  • Testing becomes difficult when countless remote peer variants need to be compatible, and when thousands of simultaneous connections must be tested/simulated.
As a fan of SOLID, DDD and the Onion Architecture, I want to share with you, how to overcome this challenges. How to adapt new standards quickly – in the software itself and also in the test automation. And also, how to protect your core logic, your crown jewels, from an ever faster changing environment.
When using Onion Architecture one automatically regards the dependency inversion principle, and with proper application wiring, one stays automagically SOLID. It is a good idea to use DDD within the inner layers, which means (among other points) to use object instances that are named, and reflect, the Ubiqutious Language of the problem domain. The advantage of the Onion Architecture is that the Core Logic is protected (loose coupling and strong cohesion) and can easily be transferred to other environments. Furthermore all outer parts become software plugins that are easily exchangeable by e.g. unit-tests.
Onion Model
Onion Model
For an Internet of Things device, I recommend to use an abstract Protocol Translator inside the Glue Logic. This translator communicates to the outer layers by passing plain data buffers. To the core logic it communicates only by moving object instances with nice DDD Ubiqutious Language name and semantics. This way your core logic will not be polluted by the negligible details of the particular protocols, and it won’t be affected by the turmoil of IoT’s protocol wars. Such a translator can easily extended by other protocols, or just by dialects between vendors that share the same protocol.
Protocol Translator Example
Protocol Translator Example
This approach is ideal for test automation. For testing the core logic (e.g. high and concurrent traffic), the Protocol Translator can easily be replaced by a mock simulator. (Because we use the Onion model, the Protocol Translator is a replaceable plugin). And for testing the Protocol Translator itself, it can be easily surrounded by mock objects. (Again because we use the Onion model, which leads to SOLID, App-Wiring, replaceable Plugins etc.).
My Recommendation: Use a “Protocol Translator” in the middle layer of the Onion Model that speaks data buffers to the outside and DDD object instances to the core logic.
If you want to hear more details about SOLID, App-Wiring, DDD, Onion and the IoT Protocol Translator, visit my evening lecture at oose in Hamburg on January the 20th 2016. It is free of charge and there’s also free beer. Please be so kind to register at http://www.oose.de/abendvortrag/oo-muster-fuer-embedded-und-echtzeitsysteme.

Embedded Software Architecture Trends in 2015

I wish everyone a happy new year and I wonder what might be the biggest change in Embedded Software Development next year. Off course Linux will continue its triumphal success for recent ARM-driven systems. It’s really time to move to Linux if you haven’t done so yet. A key moment for me to realize the impact of Embedded Linux was when a Lauterbach senior sales representative looked at me with pity when I told him that we’re not using Linux. He was assuming that everyone uses Linux (on the ARM based uC of this project) and for him it was out of question that something else could be used. He underlined that every other customer in his area is using Linux on that sort of controller.

I also wonder about the trends in off-shore software development. In the 90s I saw much development being shifted to Russia. But when Russian developers became similar expensive as European developers this stopped – at least that was my perception. In between 2000 until 2010 I saw much development in India and for BSP and driver development this seems to be a perfect place.

I, however, would bet on China to become the next center of off-shore soft- and also hardware development. The high economic growth is an ideal spirit for enthusiast programmers. The spirit there reminds me much of the electrifying times during the dot-com bubble at the end of the 90s – but I don’t fear that this bubble will burst, not at all. And the clever import restrictions of China force the companies to have facilities there anyway. Furthermore Chinese Programmers are highly trained, and I appreciate the pragmatic and fast approaches I saw there in the projects I heard of.

Another question I ask myself is whether a backwards movement from TDD, MDD, SOLID etc. will happen. I don’t see this technologies disappearing. But maybe only the best of it will remain (e.g. TDD without test-first, MDD without class diagram roundtrips – only state machines etc., SOLID without giving every class several interfaces, ‘if’ will not have a smell anymore …). For a more efficient usage of SOLID, I hope a Mock-Framework without need for interfaces will come out (like voodoo-mock which seems to be a somewhat abandoned tool to me). Dependency-Injection is a great technology – but injecting everything to everywhere just for the unit-tests makes the code heavier than necessary. Coupling and complexity are two poles in an optimization problem – decoupling too much is even worse as decoupling too less – but that’s a topic for another blog …

So long, happy new year, have fun, consider buying Chinese software company stocks this year 😉