Design Hardware/Software dependencies in embedded

[Martin Kaul]

Hi,

we develop software for embedded systems, i.e. our software uses direct hardware units of the microprocessor (for example: In/Out Ports, SPI, I2C, Timer-Units, Interrupts, DMA-Units).

In our Model I will design the Hardware system architecture and then design what software elements accesses what hardware units.

What diagram type is the preferred way to do this. How can I map the hardware architecture of our device to the UML model.

Is there a example, or do someone know literature specialized for embedded Systems and hardware/software system architecture.

best regards
  Martin Kaul

[qwerty]

Have a look at SysML. There are quite a number of examples to be found in the net. (I guess Sparx has some demo with its SysML MDG too)

q.

[Makulik]

Another option is to describe the HW architecture using nodes and ports for phyisical I/O interfaces combined with components that will represent the SW parts.

HTH
Günther

[Helmut Ortmann]

Hi,

as mentioned before there are many possibilities.

My preferred methods are:

1. Find one or more stereotypes for hardware
I use simple <<HW>>, but you may find more specific elements like <<spi>>,<<uart>>,<<subsystem>>, <<extern>>,<<AUDI>> or what is important for you

2. Assign the stereotypes to class or blocks (UML/SysML)
    You may add some tagged values which are important for such a subtype. E.g. Baud-rate if its important.

3. Class/Block -Diagram or Composite Structure/Assembly -Diagram
    Decide which diagram type fits best your requirements.
    - Class/Block is the light way
    - Part in Composite Structure/Assembly -Diagram is the concrete way
    For a lot of peoples the difference between Class/Block and part is somehow fuzzy. Therefore I usually preferred modeling with Block/Class

4. Use Ports and Port Types to specify the connection points

5. Use connector to connect Ports

6. If it's important model the Item flows over the connectors .
    I usually prefer to define the transferred information by the port type or simple by a name. Of course, Interfaces will also do a good job.

7. In sequence Diagrams you can easily define the communication
    Because of stereotypes you always know who is participant in communication. <<subsystem>>, <<SPI>>,<<UART>>, <<system>>, <<extern>> for foreign unit are easily to understand.


With those approaches we have in effect an information flow. In discussion with system engineers or typical embedded developer this approach does a good job.

Summarize:
There is no "true way" to success. You have to take in account the experiences of your stake holders and ....

Kind regards,

Helmut