Slashdot Mirror
Software Diagramming In Embedded Systems?
afd100 writes "I work for a medium-sized company building embedded systems using C. As of yet, we do not have a great design methodology, but it is something we're working on. For the last 7 years now, we've been documenting our embedded software in an IEEE'esque Software Detailed Design, and using a very cryptic block diagram to explain our software. What does the embedded software community at large currently use to graphical represent their software or do they even try this? Since the programming is functionally decomposed, is UML the right way to go?"
Personally, I just refer to this diagram. It's the 42 of diagrams. You don't need any others.
You are using English. Please learn the difference between loose and lose; they're, there, and their; your and you're.
If you've got a reasonably small code base you might want to keep the documentation style you've got. I'm not sure what a "very cryptic block diagram" looks like, but a simple drawing showing the functional blocks of your software may be good enough. For smaller embedded projects I've done in C or assembly (2-4 people on the team, 10K lines of code, minimal use of 3rd party code other than maybe the C std lib) this is the design/documentation style I've used:
1) Create an architectural design. Identify the main functional blocks of software in a drawing, include a one-paragraph explanation of what each block does.
2) Define the external interfaces, from the physical level on up. Define any internal interfaces necessary to support development, but don't go crazy, internal interface documentation is hard to maintain.
3) Code to the design. The "detailed documentation" is the comments you put in the code. Every file, function and most globals should have a brief comment describing what it contains or what it's for.
For a simple embedded system I've found this is a good approach. Things that will require a higher level of documentation: large code size, library-type code that will be heavily reused in the future, a large number of developers. Embedded systems are often a very different animal than applications, and some embedded software is inherently not reusable.
The real question you should ask yourself is "What extra help am I getting from my new documentation format, and does it justify the extra time I'm going to be putting into it?".
Ditch your diagrams. They're far too often used to:
1) As a thing to show boss that you're working.
2) Unnecessary cruft which no one uses.
About the only case where diagrams are helpful are FSM diagrams.
I too work in embedded systems, more specifically aircraft controls. In most of our design documents we tend to keep the design to the interface level of each software component (CSC), and the interaction between them. Drawing this is usually down using more simple drawing elements than that of UML. Draw a couple of boxes to show your major components, and label the interfaces of those. In subsequent sections, show only one of the components at a time, with a drawing of its sub-components if applicable. Only go about 3 levels deep if at all possible here. The attention span of most reviews will get lost after that. Besides, your requirements already specify WHAT has to happen, your only job here is to specify WHERE those requirements happen.
While UML is nice, I have found that most of the reviewers of these types of documents are not UML savvy. The one drawing mechanism of UML that I do find invaluable in this line of work is the sequence diagrams. Large amounts of requirements can often be shown more precisely by a sequence diagram, detailing the interactions between a handful of component interfaces at a time.
Take it a step up and evaluate some modeling languages and tools, such as AADL and OSATE.
http://www.aadl.info/
This stuff is MADE for real-time, embedded systems. The ultimate goal is to use it through design and analysis, and then go ahead and generate code. It does take some getting used to, and there is a lot to it so keep that in mind.
It's not perfect, and still under development, but very cool. So give it a try, see if you can pick it up. I'm generally a supporter of UML, but after being introduced to AADL and OSATE in an architecture course I was eventually convinced that it could be better than UML for this field.
Most times when people think about using flowcharts, they really should create state transition diagrams http://en.wikipedia.org/wiki/State_diagram/ to discuss, describe, and document behavior. Statecharts are an improvement on earlier state transition diagrams and are included in the latest UML specification.
Some Statechart references: