11
\$\begingroup\$

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?

\$\endgroup\$
  • 8
    \$\begingroup\$ There is absolutely nothing specific about embedded applications. What is special is resource restricted applications, the most common of such restrictions are timing restrictions, for instance hard real time requirements. If you tell us more about the requirements for your application we might be a ble to give you a specific answer. \$\endgroup\$ – Wouter van Ooijen Jul 29 '12 at 15:18
  • 3
    \$\begingroup\$ I totally agree with @Wouter's comments about resource constrained applications, but I believe that there are specific design nuances associated with using an RTOS vs. a soft-scheduled desktop development environment where blocking calls are an accepted practice. \$\endgroup\$ – HikeOnPast Jul 29 '12 at 15:43
  • 1
    \$\begingroup\$ Beware of overengineering embedded systems. See also "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html \$\endgroup\$ – drxzcl Jul 29 '12 at 18:20
  • 2
    \$\begingroup\$ @drxzcl - Disagree. Firstly, I don't think you can take too much care when designing space qualified software. Secondly, the Engineer's approach to the King's Toaster is the reason so much bread gets burned. Most toasters are too simple for what is actually a non-trivial job. \$\endgroup\$ – Rocketmagnet Jul 29 '12 at 20:16
  • 1
    \$\begingroup\$ @Cassio: I'm with Wouter on this one. You have to analyze the problem yourself, and then map out the important parts using whatever system you think is appropriate. The problem with choosing a representation before analyzing the problem is that you get stuck seeing the problem in a certain way. UML is a representation that has its roots in enterprise software, and you don't want to get lured into designing embedded software like enterprise software. \$\endgroup\$ – drxzcl Jul 30 '12 at 6:53
8
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thanks @lyndon. But how do you model embedded software everyday? Do you think that Activity Diagrams, State Machines, and Sequence Diagrams, would do the trick? I'm actually looking for the concept of what to design, then what are the schematics to be done to be inserted into the Design Document, if there's one for embedded systems. \$\endgroup\$ – Cassio Jul 29 '12 at 22:50
  • \$\begingroup\$ The most frequent constructs I see are State diagrams/statecharts and Sequence diagrams for day-to-day use. I honestly think we could get more use out of Class diagrams, but I find that people have a tendency to just create massive "god objects." Oh: the company I was thinking of is Artisan Software. This link may be informative: werner.yellowcouch.org/Papers/rtuml/index.html#toc7 \$\endgroup\$ – lyndon Jul 29 '12 at 23:37
5
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thanks @JonL. So, in order to have a nice Design Document, I would just need to design the tasks involved in my application? Also, I'm not very familiar with a scheduling algorithm, I've never have to deal with it. I'm using RTEMS. \$\endgroup\$ – Cassio Jul 29 '12 at 23:45
  • \$\begingroup\$ @Cassio, I'm not telling you to do one thing or another, that's really up to you. Just try to do what's necessary. If you're unfamiliar with your RTOS, I think just getting started with it first and how you're supposed to use it would be a good place to start. Then you can start designing your tasks around it. \$\endgroup\$ – Jon L Jul 30 '12 at 0:53
  • \$\begingroup\$ Yes, I'm still getting familiar with the RTOS features. And thanks for the suggested approach! Will do it! And as I said before, I'm new to embedded software, I'm not really sure what's necessary. It would be nice to have an Embedded Software Architecture or Design Document. Would you have one of those? \$\endgroup\$ – Cassio Jul 30 '12 at 1:55
  • \$\begingroup\$ "most RTOS's are not written in an object oriented language" Indeed. But for a course in real-time modeling and implementation we use a simple (non-preemptive) RTOS in C++. \$\endgroup\$ – Wouter van Ooijen Jul 30 '12 at 16:35
5
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thanks @Wouter. You've introduced a new concept for me: Task Structure Diagrams, nice! So, it is in C. What would you have for a document with all the requirements, if not UseCases? \$\endgroup\$ – Cassio Jul 29 '12 at 23:47
  • \$\begingroup\$ IMO you need a list of identifyable, more or less single-issuse requirements, if only to base your test cases on. For me UseCases are just a method to get to such a list. A good method, in some cases. \$\endgroup\$ – Wouter van Ooijen Jul 30 '12 at 7:04
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.