So, what does _your_ software architecture look like?

Customers often ask me in my opinion as to what their path to multi-core should be. Invariably I ask them two things. 1) Describe your current hardware architecture, your next hardware architecture and what your hardware architecture will look like in 3 years; 2) Describe your current software architecture and any plans you have to evolve it.

This leads to interesting discussions, most customers can draw their hardware architectures, some can white board their software architectures easily, some have more problems, but I have a strong feeling that their drawing differs significantly from the actual implementation.

The software content of devices is only increasing in todays age of multi-core and virtualization. And to top that off, not only is the content increasing, multi-core offers many ways to map the software content to hardware.

My background is in visual modeling, UML, SysML, Domain Specific Modeling, SCA/SDR, they are all visual ways to describe what you are working on, while SCA/SDR is specific to software defined radio.

The languages can be used to describe the problem domain or the solution domain, depending on how you are using them. SysML is useful in systems with many non-software moving parts, to describe requirements and to describe how parts will work together. UML is useful for describing software systems, it can describe requirements, architecture, design as well as implementation. It can even be used to generate source code, something I have seen used successfully in a number of large systems.

I was having a conversation with an ex-colleague a while ago on this and we quickly started reminiscing how we utilized UML (and a modeling language called 'ROOM') in many different systems ranging from large telecom radio base stations, radio network controllers, automotive and industrial systems.

The topic then quickly shifted to multi-core systems and how these modeling languages can be used to describe both hardware and software and the relation between them. See, that is the difference between the past and the present. In the past the mapping from software to hardware was straight forward, one software system, one operating system, one processor. In today's systems it is not. There are many ways that you can split a large software load on a multi-core system, especially if you involve multiple operating systems with required separation for reliability, security or redundancy reasons.

Modeling languages allow you to describe the software design, the hardware design and the relationship between them (the deployment). It also allows one to model multiple different hardware designs (as hardware tends to evolve over time) and how the deployment changes over time. You would typically want to describe multiple deployments to understand how your system would evolve when newer hardware platforms are available.

Constructs in the modeling language like sequence diagrams and collaboration diagrams provide visualization of how the software interacts. Visualization provides understanding and helps planning. And if the models are elaborate enough, they can be used to generate implementations from.

If you are building a large software system, are using multi-core systems and feel that the complexity is increasing every software release, and are attending the Embedded Systems Conference next week in Silicon Valley then I suggest you attend the presentation on Software development, the key to multi-core success by Martin Bakal. 

If you are not attending ESC and for more information have a look at the information on the web.

Comments

[Julien]

Just for information about software/hardware binding (and even the association of functions to a multi-core architecture) : the AADL language (http://www.aadl.info) seems to be quite interesting in this context. It also can be used to automate the implementation of the deployment. It was experienced in many projects, in US and Europe.

[Mark Hermeling]

Thanks for your comment Julien. Yes, AADL is interesting, as is a UML standard called MARTE. Europe is an active place with many universities and companies experimenting with modeling languages.