This week I’m in Boston at a customer that is starting a new project. I’m helping setting it up, setting up the model and the rest of the development environment.
In the beginning of our Rhapsody days, we were always happy to tell people we were the experts in “Systems with limited resources”. Now. in fact, we still are, just because we have a lot of experience in that area. I don’t think many people know how to handle the specific requirements of modeling in small 8- or 16bit systems with kilobytes of memory and microseconds to respond.
But slowly we have been growing with our customers and we also do larger systems. This week I helped setting up a “larger” system. This a “normal” PC with Linux on it, accompanied by a couple of other boards that do small tasks (and have smaller controllers!)
The use of Linux as operating system immediately introduced one big question: how are we going to implement a framework?
Linux has processes and threads. ( See BLOG entry ) Are we using a distributed framework? Or the normal framework with Threads?
Both have advantages and disadvantages. Distributed Framework is more difficult to implement but just threads will influence the way you can use your system and will not give you all the advantages of memory protection.
We decided to use both ways with a “simple” framework and use IPC to communicate. So we would actually use multiple applications that communicate with the use of the OS.
The trouble with IPC is always that you need some base information to start the communication. You can use a “zeroconf” system like Apple’s bonjour where every client starts and assumes it is the “Master” until it finds another client that already is the master. Or you create a Master that is known by all clients.
We have chosen the last variant. A Master-broker is in the system, waiting and listening on a fixed IPC Channel. Clients report to that Channel with their name and the Master sets up the communication. The client then opens up for its local clients to publish/subscribe that it will communicate with the Master-broker that registers all clients in the complete network. C++ makes a lot of this easier.
It was real fun to set this up. Most work was spend on setting up the development environment and describing how to use it. We use GIT and Sharepoint to do that.
The compiler/IDE is Eclipse in Ubuntu Linux, we deploy code to a shared directory with Windows. IPC on Linux is done with named pipes.
We spend some tie setting up the Rhapsody model so that the package structure was logical and ready for use by multiple people. The model will contain a lot of components that must be built separately. Luckily you can tell Rhapsody to “build all” (which will generate and deploy all in our case) Eclipse can also build a complete project with multiple executables. We also built some test tools to test the Broker setup.
This is what many people underestimate when starting to use MBSE. The UML Tool will not do that for you. It is a a UML Tool, UML is a language, not a process nor a development environment. It is very important to spend time setting that up and documenting it. Use a central documentation tool like Confluence, Sharepoint or MediaWiki, your success depends on it!
So… just work in Boston? Nope… in my 3rd Boston visit I finally had the time to visit “Cheers”, the bar of one of my favorite TV series.
I’ll end this one with a quote from Norm:
“Can I pour you a beer, Mr. Peterson?”
“A little early isn’t it, Woody?”
“For a beer?” “No, for stupid questions.”
“Cheers!” and Happy modeling with Rhapsody
Walter van der Heiden (email@example.com)