[The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
– Edsger Dijkstra, The Humble Programmer
Right now there are lots of people who are saying two things: First, embedded devices and embedded software will change and transform our way of life in a similar or even stronger way than the arrival of the internet and second, the resulting software engineering challenges are huge.
There are a lot of drivers/trends behind this, but two of the more critical ones are the arrival of multi-core processor architectures for embedded devices and the resulting increase in processing power that comes with it (see quote above :)). And secondly the increasing demand to make embedded devices talk to each other (e.g. make Electronic Control Units (ECUs) on the car talk to each other and then make cars talk to each other).
The lack of abstraction that we have in embedded software engineering makes more than 50% of all embedded software projects being later, over budget or not deliver on expectations.
This sounds and looks like a first class software (engineering) crisis. What do we do?
Killing the problem with people (e.g. throw more people at the problem) is a very popular approach, especially with the emergence of cheap off-shore development centers in India and other places, but creates a huge liability, because over time it does not scale very well and the management and maintenance burden has the potential to become an even bigger problem.
More thoughtful approaches first segment the embedded market from a requirements point of view and then look for much more systematic approaches to address the requirements in the given segment. One way to segment the market would be along the lines of the real-time requirements. Working assumption would be that there is a hard real-time market, a soft real-time market and an embedded market (no real-time requirements, but the software must run on devices with limited CPU and memory capabilities).
The segment with the strongest growth is the last one. Addressing the software engineering issues in this segment will give us the biggest bang for the buck.
One way to go about it is to use existing approaches that have (kind of) worked for the first two (real-time) segments and also use them in the embedded space, e.g. using integrated tool-chains to generate a lot of the source code (also known as Model-Driven Software-Development (MDSD)). This gives you good initial results in terms of productivity, but has the potential to create hard to maintain, monolithic, tightly-coupled monster systems.
The most promising approach right now is to introduce the idea of Software Product Lines (SPLs) to the domain of embedded software engineering and combine it with MDSD. This will give you the productivity gains you are looking for, but will also allow you to enforce a/the necessary level of reuse to ensure the long-term maintainability of the system.
In that context abstractions become pivotal. Without abstractions there is no way to create good boundaries for reuse. The first level of abstraction is the operating system and here is good news, because more and more embedded systems are based on standard operating systems (e.g. embedded Linux). But the layer above that is still under construction. What is needed is a platform that will allow you to build business-level software components and integrate them on the device and/or even reuse them over device boundaries.
Interesting efforts in this context are ...
- OSGi - a component deployment platform for embedded devices for components and services implemented in JAVA
- The Virtual Function Bus (VFB) in AUTOSAR - a common software infrastructure for automotive systems of all vehicle domains based on standardized interfaces
- Various embedded software engineering platforms for mobile devices like LiMo, Moblin and Android
Can we avoid the embedded software crisis? Yes, we can! Check it out.