I am starting in embedded software programming using a RTOS and, since I am already a developer for desktop applications, I kept wondering what is it like to model embedded software using UML diagrams, like Activity Diagrams, Sequence Diagrams, Use Cases, etc.
Is embedded software designed using UML, the same way desktop applications do? Is it the best option or is there a better one? Can I have some examples?
Is there a specific tool that does this?
There are Real Time extensions to UML that were popularized by a company whose name escapes me at the moment. I remember doing a paper on it several years ago. Bruce Powell Douglass wrote a few books on the subject of modeling embedded systems using UML, but his company is not the one I'm thinking of.
That said, to echo Wouter, there is nothing special about embedded software per se. I write embedded software every day for a system that runs on Pentium-class processors; UML is quite applicable. Also, remember that many aspects of control software have been added to UML over time: there is syntax for specifying synchronous or asynchronous events along with response time in Sequence Diagrams, Petri net type behavior can be found in Activity Diagrams, Statecharts model behavior even better than State Diagrams can, etc.
OTOH, a lot of people prefer to model embedded software using Structured Design and Dataflow concepts. It's all about the type of system you're designing and what works best.
When turning to an RTOS, we are usually dealing with an application that has many concurrent tasks that need to be scheduled optimally in order for each of them to meet their deadlines on time or share resources safely. The RTOS framework that you choose implements a task scheduler, and your job (typically) is to write these individual tasks with a certain set of properties (period, priority, etc) and then hand it off to the scheduler. So for documentation, the approach I would take would be to document each task carefully.
Most embedded software and, as far as I know, most RTOS's are not written in an object oriented language and thus may not benefit from a lot of things that are geared towards that like class diagrams for example.
When documenting your RTOS tasks however, any diagram which describes the task well would be a great benefit. I would imagine a sequence diagram for each task could be very helpful for example. Along with that you could specify its hard requirements like its period/frequency, priority, any shared resources it may use, pre-emption requirements, etc. Also of value could be to document how you've configured the RTOS and perhaps a state-machine of its scheduling algorithm.
Take any of this advice however you like, I haven't messed with RTOS stuff since my college days, and never really "documented" the work.
Modeling is all about
knowing what aspect is difficult and complex in your application,
finding a modeling tool/language/abstraction/convention/notation appropriate for that aspect
designing that that aspect
Hence no modeling tool/approach/etc is appropriate for all situations. A satellite will likely be a real-time multi-tasking system, probably with more than one processor. Task structure diagrams, STDs, and sequence diagrams are probably usefull (just to name a few). If the project is done in C a class diagram is less likley to be usefull (if it turns out to be very usefull, the choice for C was probably wrong). I am not very fond of UseCases, and a satellite an-sich has no user. Use cases are most appropriate in a situation where you want to discuss the requirements for your system with a non-technical user. If that is the situation you are in with a satellite project something has gone wrong.
I haven't designed anything that is space qualified. But I have worked for a Department of Defense (DoD) aerospace subcontractor and a lot of my designs were flight qualified. They require a lot of documentation on your designs and provide Data Item Descriptions (DIDs) that detail exactly what they want to see.
You can use the DoD ASSIST Quick Search to see all of the DIDs for the documents that may be required if you type "software" into the "Word(s) In Title" field and click Submit. (I find it funny that a DoD site throws a certificate security warning, but I assure you, it's safe).
Since you ask specifically about a Design Document, here is the Software Design Description (SDD) DID. They emphasize the use of words to describe each part of the design. But if the use of UML, State Diagrams, flowcharts, pseudo-code, etc., can enhance the understanding of the design, then they of course would like you to include it.
Which modeling method you choose, as others have stated, depends on you design. But I thought that seeing a DID for aerospace software might help you write your Design Document since your project is space related.
