Design Article
An architecture for designing reusable embedded systems software, Part 1
Dinu P. Madau, Visteon Corporation
5/4/2008 12:30 AM EDT
The drive to reduce product development cycle times has led to the need for designing reusable code. It's apparent that reusing code across software projects decreases project development time. Nonetheless, software engineers often resist developing reusable code because they're burdened by time-to-delivery commitments.
From design to documentation, reusable code requires that project managers assign additional resources up front. Project managers must decide whether to initially spend the extra effort in designing reusable software modules, which would benefit the long term, or to first quickly design the software to meet their clients' deadlines and later rework the modules to be reusable.
In an effort to reduce the development time of designing reusable software, adopting an architectural template that can be applied from project to project would be beneficial. The template would define hardware-independent reusable modules and an interface layer that is hardware dependent--changing when the hardware in the system changes. By applying the architecture template consistently across several program platforms, the goal would be to decrease the development time from one project to another while improving the maintainability of the software product.
Let's start off by viewing the overall system as an object that is partitioned into several smaller objects or layers. Some of these objects are written to be reusable while others, by design, are dependent on the hardware and have to change when the hardware changes. We can divide the system into four distinct layers as shown in Figure 1. The perceived system behavior, the outermost layer of the system, is where the users expect a certain behavior, typically defined in a functional requirements document. For example, when someone pushes the call button for an elevator, they expect that within some reasonable amount of time the elevator door will open allowing the person to enter and choose a desired floor.
The next layer is the "hardware" layer. This layer defines the various sensors and actuators used to provide information to the core software object. This layer defines the terminators for the system, which in many cases is dictated by the customer. These terminators are often constraints applied to the design.
For example, let's assume that the project requires a vehicle velocity input. One customer might define the terminator for this input as the vehicle speed, derived from the engine control module and transmitted via a two-wire serial communications link. Another customer, requiring the same input, may specify that the terminator is a wheel speed sensor, which requires processing in order to derive the vehicle speed. In either case, the customer dictates the type of terminator that is available to the system even though the core requirement is vehicle speed.
The "core-software" layer, by design, is a hardware-independent layer. This layer determines the appropriate action given a set of inputs and drives the outputs to a desired state. This part of the software executes the algorithms necessary to provide the desired function that the customer has required. The inputs and outputs (in other words, external terminators to the system) to this layer are pre- or post-processed by the interface layer and the data is typically passed to the layer through random access memory (RAM) variables.
Between the hardware and core software layers is the "interface" layer. This layer links the hardware with the software and, by design, is tied to the hardware making it reusable for any other system that uses identical hardware. Figure 1 is an illustration of the layers that compose the entire system.
|
|
|
|
|
Gabriel Gonzalez
5/1/2008 7:57 AM EDT
I don't want to be rude but the whole idea presented in this article seems too naive for me since this architecture thing should already be more than known and applied by any software engineer working in embedded or any other software development.
Sign in to Reply
Matt Osborne
5/1/2008 11:52 AM EDT
I agree with the previous comment; just call it what it is - a "uses" hierarchy, which is very well known and is a best practice in the design of a software architecture.
Sign in to Reply
SPLatMan
5/5/2008 9:28 AM EDT
These are well established principles. They do however deserve to be re-iterated from time to time time if only for the benefit of upcoming generations.
However, while the author is extolling the virtues of separating function code from hardware and engineering units, he then goes on to say in his ABS example on page 2:
The output from the core software is a current value that is desired to flow through the solenoid/load.
Core code generating current levels? That is not divorcing the core from specific engineering units. Surely all brake solenoids don't work at identical current levels?
This slip will do nothing to help the upcoming generations, and should have been spotted by the editors.
Sign in to Reply
KeithMullins
5/9/2008 1:35 PM EDT
As naive as it appears to some, this definitely needs to be presented over and over.
I have run into too many convoluted hack jobs in embedded software that an "expert" butchered up and needs to be redone.
I do enjoy the paycheck, but my time can be better spent than going behind the elephants in the parade with a shovel...
Sign in to Reply
pr_consult_name
5/11/2008 7:44 PM EDT
Denigrating your readers? That doesn't exactly smell of a healthy policy. As a site editor, maybe saying good things about your authors is where you should draw the line rather than taking it to the reader who are more than likely responsible for the interest that is shown in this site?
Given the healthy community of vocal active programmers including those in the embedded Linux community, the embedded WindowsCE community, the technical forums like CodeProject, Technet, the lkml, AVR freaks, the PIC forums... your comments are borderline inflammatory. Outside of the authors of this site, I would suspect your defensive and jaded statements might actually offend some of your readers with "lame excuses" who don't contribute to your magazine but do contribute to and participate in the community as a whole.
Sign in to Reply
Marco Wang
5/14/2008 1:01 PM EDT
I agree Editor's words. Though a lot of senior engineers already know the concept in this article and applied it in daily design activities, there are still A LOT OF engineers don't know how to do separetion, encapsulation and decoupling.
Just think how many embedded software engineers understand design patterns and use them? A lot of engineers even never heard it.
As long as I don't have time to write such nice article for my engineers, I will recommend this one to my team.
Sign in to Reply
xyin
5/15/2008 4:05 PM EDT
Nice to hear somebody talking design patterns in embedded software/firmware world. I'm a fan of applying OO/UML/Patterns modeling on embedded world, but hardly to find same interest from my colleagues.
Sign in to Reply
lmolleda
5/16/2008 12:01 PM EDT
Thanks for the article. One of the things I see with embedded engineers at different levels of experience is a lack of a good level of understanding for software architectures and software design. The article would certainly enlight some readers.
AutoSAR is certainly fullfilling a need for embedded automotive, and it's a monumental task that required a lot of OEMs, money and effort just to try to put together an architecture that can be used for automotive embedded. It has not been something easy or quick, and it will take its time to get through the oftware engineering community in automotive to accomplish what a lot of us try to do "Reliable and reusable software" to have better products, faster to the market.
What is naive is that some people believes that because something seems obvious, or simple, then everybody should be using it. The truth is that in the embedded world there exist a lot of hacking, and rework just because lack of software architectures, design, or a lot of coupling to the underlying hardware. As someone said in a different way above, we could be spending our time better innovating than re-hacking.
Sign in to Reply
seasideprogrammer
9/12/2008 10:42 AM EDT
Author here. :)
Thanks for the comments (both positive and not-so-positive). First, please read all 3 parts. It will give you a better prespective on the overal goal of the paper. The first part describes the encapuslation idea at a top level, the following sections defines the implementation method. It is in the details of the implementation that I have seen the lack of structure and it is not just from freshman programmers. It is too easy for folks in the embedded world (not so much in the OOD world) to hack code together and get it to work. By focusing on the basic structure of the implementation we can drastically improve the quality of the code that we write and increase its maintainability.
I recognize that some of the readers of the journal have years of experience in software development and I am sure that there are articles in the journal that will challenge them at their intelectual level. On the other end I am also sure that there are people who are not as experienced in the field and my hope is that they will find this article useful. Thanks for reading the article and for you comments.
Regards,
Dinu
Sign in to Reply