BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Tag: Germany (Page 2 of 2)

MESCONF 2018

Introduction

As every year we have organized our MESCONF (Modeling of Embedded Systems CONFerence) We changed the format a little bit, this year we have extended it to 2 days, the first day is just like last year with the difference that we have an evening session, the second day is “Tool Vendor Day” to allow Tool vendors to do a more marketing focussed presentation of their tools

Again at the fantastic Infineon location in Munich we had 80 people there listening to various presentations of experts and later some Open Space sessions.

The evening session with Nicolas Dierks the Philosopher was really interesting and shines a new light on our lives as developers.

panorama2.png

As usual we used “Open Space” to organize a big part of the MESCONF. Proven concept, since years we receive very good critics about it.

We spoke about lots of things that occupy modelers these days. One thing that returned in many meetings was the topic of “How to handle people who are refusing to model.”
A very interesting topic. Why are people refusing to model?

  • Some people just don’t get familiarized with modeling. Modeling is not easy, you need a lot of initial knowledge to apply it in the correct way. The only thing that helps there is train, train, train, coach..
  • Modeling is different from programming. Sometimes people who are real programming guru’s refuse to switch to modeling while they lose their “guru” status. It is difficult to discuss with them since they do not refuse consciously most of the time. they will use other arguments to refuse modeling and keep on doing what they do.
  • “Known hurts are better than unknown happiness”. A common attitude of most people is to stick to what they know until the hurt is really, really big. As long as people manage somehow to deliver their products using old methods they will stick to them.
  • “We don’t have time to repair the fence, we are busy catching chickens”. Most people are under stress and continue doing what they do because the stress does not allow them to step back and take the time to evaluate the used methods.

There is no “silver bullet” solution to that. The common feeling is that the world is leaning more and more towards modeling, partly because younger developers have less objections against it (Mostly they had it in school) and because the complexity is increasing faster. We also notice an increase in Rhapsody business. And that’s good!

OK, that’s it. Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Publisher Subscriber

On the road again….

Last week I was on tour in Germany by car. Not by myself but together with Andreas. That makes traveling a lot more fun, alone is OK but with someone to talk to (or to listen to Jazz on my Burmester…) is a lot cooler.

img_0058

S-class Burmester speaker

First evening stage was from home to Bückeburg. Sunday evening is perfect for driving, it is quiet on the road and trucks are only allowed on the street after 22:00u. Then the next morning early to Stuttgart but via Karlsruhe. We had a visit to a partner company, show them our AUTOSAR solution. then to Stuttgart for the hotel.

Next two days was at an automotive customer to help them using Rhapsody to create the architecture for some very cool stuff. Sorry,…can’t tell you any more… sometimes stuff must be kept secret….

During that 2 days I came across an old friend, the Publisher-Subscriber Design Pattern and I decided to write something about it.

Design Pattern

Publisher Subscriber is a design pattern. A design pattern is not just a library function, it is a standard way to solve a problem, you can not give standard code for it but you can give example code that you must adapt to implement in your own realm. (Not always, due to clever inheritance it is possible to give some standard stuff for OO languages.)

What is PS (Publisher – Subscriber) ? It is just what it says. Somebody publishes something and somebody else can subscribe to it.
Suppose you have a button in your system and you want an event when the button is pressed. Easy, just do a CGEN (me->receiver, evOfInterest() )….
If it only were that easy… Of course this is not a solution, you probably want to re-use the button in other applications. If you have solved it like this, you have to change the button each time you want to re-use it. Better is to let the button be unaware of anything from the application and:

Reverse the Relation

Yes. The application should have a relation with the hardware and not the other way around. The hardware should have a “subscribe()” function that allows an interested user to be notified when the event of interest comes by.

*^@#$&*( “C”…

Yes… the old “C” fan starts to see the advantages of “C++”… “C” definitely has its uses but design patterns just work so much easier when you have encapsulation, inheritance templates and overloading.

image-1

A very cool example of ‘C’…

The publisher subscriber pattern works as follows, you have a publisher that “publishes” a certain service, let’s say a button can be pressed, you can “subscribe” to that press. This is done by a subscribe function where a function pointer and (We’re using Rhapsody in”C”!) a “me”-pointer are passed. The function stores them in attributes and can call the function via the pointer. Sounds easy but there are some caveats. You have to know the signature of the function to “type” the attribute and the subscribe functions’ arguments. This is a bit awkward since you can not “just” take any function, your compiler will protest. Also the “me”-pointer has to be of type “void *”, you can never predict which object it will be. Depending on the compiler you need some casts… not really elegant.PublSubsc

Elegant C++

Compare that to “C++” where you just create a Publisher Class that has a relation with a subscriber class. The publisher Class has the “subscribe” function that has a pointer to the class as argument. This will be stored in the “Subscriber”, that has an abstract Notify function that needs to be implemented in the inheriting class (Since it is abstract) Screen Shot 2018-03-28 at 16.12.29.png
You can use the subscriber type as a template and you have a ready made function that works for most cases. You only have to adapt the subscriber function but you can even make multiple functions with different parameters, the compiler will help you.

To make life easier I have put this in a Rhapsody 8.2.1 model, download here: PublSubsc.
As always: If you need an older Version: please respond.

That was it for today! Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

München in winter – Rhapsody 8.3!

Muenchen

This week I was in München again. We have lots of customers there so traveling to Munich once and a while is unavoidable.

This time I went there by plane. There are more possible ways to go to Munich, plane, train and car. I let it depend on the starting point (from Home, which is 150km further then from the Office) The weather forecast (not very good, snow and ice) and my own personal feeling at the time (don’t wanted to drive far) So… KLM, do your job…

This time they did, no snow or wind to cancel the flights. And then flying is pretty easy for me. Just hop on the train in the city I live, check in (Yes… the Netherlands have a “public Transport Chipcard”. Just hold it against the check-in pole and it beeps. Check out again 1,5 hours later at Schiphol and you’re done. Eat your heart out, Germany…..

Flying went fast and comfortable. I like flying with KLM. In Munich I took the S-Bahn to the hotel. Always a challenge to find out where to go and which train you need. Giving the right directions in the right dose is an art, Munich does not have that.
But OK, München is OK. I don’t like their football team (at least not “that one”) but the city is cool. So I arrived at the hotel and checked in. # days of AUTOSAR modeling before me, later more about that!

Rhapsody 8.3

Almost in Nikolaus day (December 6) IBM released Rhapsody 8.3. As I already mentioned before: If it ain’t broke, don’t fix it….
If you really want to update: please wait until we have tested the release and determined the parts that require special attention.
In a complex world, development environments are becoming more and more complex. Even small changes can have large consequences. Here I will give you a heads-up on the changes and some caveats we (and a helpful customer!) have already established.

File Format and extensions

To allow a better integration in the Jazz platform, IBM needed to change the format that Rhapsody uses to store its models. until now that format was proprietary (but working quite well) IBM changed that to an XML format. To indicate the change they changed the file extension (Like Microsoft did in Word and Excel, they went from .doc and .xls to .docx and .xlsx) Rhapsody files now also have an x behind it (.rpyx, .sbsx, etc)
This seems like a minor issue but is deadly when you want to keep your historical information in your config management files.
Some CM systems allow you to change the name of files but you have to do that by hand. Not a small job if you have large models….

Not new

In fact, the new database format was already there, it was just optional in version 8.2.1. It was there in the release notes but it was not really noticed. To be clear: I like this change. But it is a complex one, it takes time to solve all the pieces of the puzzle.

DiffMerge

OK, a new file format. Does that work with DiffMerge? The good new: Yes it does. The bad news: it only saves as .<file>x. converting old into new.

Save As?

The question that comes up immediately is: Can I still save in the old format. Yes you can! Like all (since 7.4) Rhapsody versions you can do “File”, “Save As” and then go back 2 Database versions. I don’t have an official statement from IBM yet but to me this looks like this option will be gone after 2 more releases.

When to update?

So this does not bother you? And you want to update to 8.3 anyway. Well… don’t do that yet. Certainly not if you use Eclipse (Plugin and Workflow), there have been some issues there.
There has been an iFix already but that did not solve all problems. IBM is working on this with high priority but it takes some time. I’ll keep you posted.
If you also use the RXF you also have to be a little patient, we have to test it first. Check our download portal, we keep you informed.

Happy modelling with Rhapsody (8.2.1)

Walter van der Heiden (wvdheiden@willert.de)

Oktoberfest

This week starts in Munich. Or actually in Münster where I stay in a hotel to prevent having to go up at 4 o’clock. My flight to Munich leaves pretty early here, the Hotel is close to the airport and has a taxi service. Without large check-in luggage the check-in time here is about 10 minutes.

But enough about Münster, I’m on my way to Munich, not my favorite town as you might remember. Luckily I don’t have to drive..

The flight was hard enough to get since this is the time of the “Wies’n” as the Munich people call the “Oktoberfest”. Yes, correct, that is not in October… People from all over the world travel to Munich to have a look at the Oktoberfest. And I am invited by IBM on their IoT (Internet of Things) conference with a visit included.

I personally couldn’t care less, the music they play there is absolute horror, the noise is terrible and the only good thing is the Beer that they serve in large glasses that contain 1 whole liter (Mass), drink a few of them and you won’t notice the rest anymore…

Unfortunately I have a busy week and I’m on a diet so no beer for me. So I have to survive it cold-turkey.

Finding the right place was not easy, we had a description but the Oktoberfest place is huge.

There are positive sides, luckily. I meet with old friends from the pioneer Rhapsody days and that is really cool.

The conference was very good, we spoke with many people from IBM about the tools. Although IBM is breathing “IoT” to the outside world, this conference showed that they are still very much aware that there is no IoT without compelling tools!

There is a lot going on with Rhapsody and all Jazz tools, I will speak more about that later when things are released.

In the meantime: Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

AUTOSAR meeting Juli 2017 Paderborn

The planning was to have a more quiet week with less travelling. As usual, this did not work out well. As my good friend Bruce always says: The difference between theory and praxis is a lot larger in praxis than it is in theory. No problem, I’m used to that.

On Tuesday, at least that is what Clemens thought, we had a common AUTOSAR Meeting. We are AUTOSAR Premium Member (by proxy of Sodius) so we visit the meetings and we try to influence the process of the AUTOSAR specification.

So on Tuesday morning very early we drove from the apartment in Bückeburg to dSpace in Paderborn where the meeting was held.

There it turned out that Clemens made a tiny mistake. He assumed that all meetings had the same footprint during the week which was wrong. (As _I_ always say: Assumption is the mother of all f***-ups) So after a Tuesday full of very very in-depth AUTOSAR workgroup meetings (and a nice lunch, thanks dSpace!) we drove back to the apartment just to go up very early again on Wednesday to visit the meeting we wanted to visit….

Anyway… shit happens. This way Clemens and I had time to discuss the Willert AUTOSAR solutions. Basically there are 2 AUTOSAR solutions, Classic and Adaptive.

Classic is for targeted at smaller controllers and very static environments. Base is that many system information and software (SW-C, Software Component) information is captured in an XML structure (ARXML) Tools can read that structure and use the information in there to configure themselves and to export their own added information to other tools.

Adaptive is targeted at larger systems that have dynamic components. Base is a Linux environment with many specs for security. It will (amongst others) be used by ADAS (Advanced Driver Assistance Systems)

What does that has to do with us? Well, Rhapsody is a tool as well and it is, out of the box, capable of reading and writing these ARXML files. You can then add information and work with the provided information. We think, however, that this solution is not applicable and scalable enough for a lot of customers. So we visit the meetings and have access to the AUTOSAR information to be able to create our own simplified AUTOSAR profile. (Apple Style, or better: Jobs Style, keep it as simple as possible, hide the complex stuff, make it usable for everybody but also make the complex stuff still accessible for Guru’s)

What we basically do with Classic is that we import ARXML and convert it to UML Elements right away. In that way we can use “normal” UML to develop AUTOSAR SWC’s.

Adaptive is very new and in early stages of definition. So there is a lot to do for us in that area, not only in profiles and frameworks but we can do a lot there in Rhapsody modeling, at least that is what we think.

So in the next weeks we have a lot to do. Clemens and I will be cooperating in creating / improving the Willert AUTOSAR Solution!

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

 

Stuttgart 2 (The Sequel)

OK… Stuttgart again. I’m there so often that people think I live there… “Neigeschmeckt” they call it … (Something like “Tastes new” but ask a Schwabe if you want to be sure…..) To make it halfway bearable I’m with a different customer again. And I’m not alone, Joachim joins me for the training part and on Wednesday for support with our AUTOMOTIVE Rhapsody Model and later Andreas will join us on Wednesday for the MDSE part.

Yes correct, I’m with an Automotive customer again (what are the odds…) so a lot of extra constraints that are less important at non-automotive sites. They always use AUTOSAR, they never buy chips that have enough memory or enough power to do the job, often they have a very cheap CPU but there is only a CPU manufactured compiler (horrible, sometimes these don’t even fulfill ANSI-‘C’….) And they have time constraints that make all other projects look relaxed.

But this customer might use a bit different approach. At least a decent (although very expensive) compiler: Tasking and a decent (although complicated) CPU: Infineon TriCore. But they are determined to use MDSE and willing to put in the necessary effort.

It was a very nice week with very productive sessions. So I’m sure I will see a lot more of Stuttgart in the next months….

Back to Rhapsody. We had a new case, a customer from…. Stuttgart…., with a question I heard before. But that was a long time ago so i decided not to do a copy/paste solution but to dive into it and see if there were better solutions now. And there was…

The problem, or actually the question, was “How do I use Doxygen within Rhapsody”. Simple question. For those who do not know Doxygen: this is a system (Open source) to document C or C++ (amongst many others but these are the interesting for us)  source code. ( www.doxygen.org ) Of course it is Dutch, what else, and many developers use it.

You can document your source code with certain special comments, Doxygen will look for that and generate either an HTML or a LaTeX file. It can do stuff like generate call trees, looks pretty neat.

My first reaction, years ago, to this question was: why do you need to document your source code? It is generated, who cares? But that is too black and white. A lot of source code inside Rhapsody models can be documented and a Rhapsody model is, of course, way better as documentation but not everybody has Rhapsody! (We are working on that one…) So there is an actual use case for generating documentation from your partly generated source code. We even use Doxygen to document our RXF Framework!

But how do you do that? Simple way is to just use the “Description” field in Rhapsody, it will appear in the generated source code. But there are ways to make this more comfortable.

The “old” solution was to add some properties to your site.prp (sitec, sitecpp) But in modern time we can use profiles for that. So i decided to put the stuff into 2 profiles, one for C and one for C++.

A very nice feature of Rhapsody is that it has profiles. In these profiles you can do a lot of stuff that, once the profile is loaded in a model, has great influence on that model. You can set properties, define stereotypes and define tags. You can also define model elements that will be copied (and adapted!!) to your model and much more, I will write about that in a later Blog entry.

When you define tags in a profile and you assign these tags to a specific model element then (It’s magic!) the tags appear in all that elements in your complete model.

Another nice feature is that Rhapsody has a “Description Template” property for many model elements. In that property you can define what comment you want with that model element. You can use tags there ($TagName), the content of that tag will appear in the description. Quite cool eh?

So if you predefine some tags with Doxygen Standard Comments and you make a clever description template you can generate your source with the correct Doxygen Comments. The nice thing? I already did that for you, just download the model (8.1.5, if you need an older one: just ask, I’ll generate it for you, but you will owe me a beer…)

Download at: DoxyGen815

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Stuttgart

I do a lot of traveling. A whole lot of traveling. Mostly Germany but sometimes outside or way outside. But the city I travel to most is Stuttgart. Not because my car was made there but because we have lots and lots of customers here.

Stuttgart and the surrounding cities are not bad, just the traffic is really murdering. They even beat Munich in traffic jams. Part of it is caused by the geography, Stuttgart is a hole between some hills, there is no way you can build decent roads, what is there must be used, no room for more roads.

The other cause is the so-called “Stuttgart 21” plan. This involves railway only but it will take the complete main station and move it underground. If you look where the station used to be it looks like a nuclear bomb just went of…. Big hole with lots of machines. This has its influences on railway traffic but also on everything that goes through the city.

This week is Rhapsody Training at a customer. 5 days! A long time ago a 5 day Rhapsody Training was normal, unfortunately this is no longer the case. It went to 3 days, often only 2 days and there are companions that estimate their employers to be able to learn UML and Rhapsody in 1 day.

This is, of course, total rubbish. Learning UML and Rhapsody takes just as long as learning ‘C’ and compiler/debugger. If by now you think: “Learning ‘C’ goes quick” then please dig your memory for the truth…,. Before you are an experienced ‘C’ programmer, years go by!

The UML is not more difficult or easy to learn, it is just different. And… you have to know ‘C’’ (or ‘C++’) before. This is what Rhapsody generates.

What is difficult about UML/Modeling? Well.. the way you do it is very different from traditional source code programming. I think that is the most difficult part for most “converted programmers”. Modeling is an art, you learn it by doing a real good training (like ours… 😉 ) and by doing it! You need to practice, read a lot, try a lot.

I see many people using Rhapsody The way they use their IDE, try until the code generator produces the desired output. This is wrong! Follow the paths that people like Bruce Powel Douglas and others have described in books, modeling is a lot of work. In the end you will save because the number of errors and changes will be way lower than with traditional programming.

It pays off to invest in a good process (which diagram should I use when?, what information is where?)  and in making your model so that it is actually your documentation. Modeling takes time but it is time you have to take anyway to give your brain the time to understand what you are doing.

I always say: a model behaves just like your car. If your car is dirty, it does not drive “good”. As soon as you wash and vacuum it, you will sense that it drives “better”. Subconsciously, admitted but true. A model behaves the same. If you make it nicer, with straight lines and with elements that have the same size and are outlined you will notice that it makes more fun to use the model. Some think that the drawing part is wasted time: trust me, it’s not!

So beautify your model, insert navigation information so that other can also find their way in your model, use enough diagrams, (every diagram should answer a question) use requirements that you connect to model elements to show traceability. Use stereotypes, profiles and tags to store information in your model. After a while you will do that automatically and the quality of your modeling will increase dramatically. Also re-use will be much easier than it was.

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

RUGS & DUGS

On Tuesday June 27 we had our yearly RUGS&DUGS. That is the Doors and Rhapsody User Group Summit. Actually the correct abbreviation would be DRUGS. Is fine with me (i’m Dutch) but my German colleagues were against that name. Well OK… but acronyms ending in UGS are all problematic… well except Hugs I guess 😉 Check out RUGS/DUGS in google…

But the conference was successful despite the name, a lot of users were there. This year we were in München, not exactly my favourite city. Or to be precise: i hate Munich. Traffic is hell, public transportation sucks, hotel cost a fortune unless there is a fair then hotels cost more than a house in north Germany, the local soccer team are a bunch of tax criminals.

Enough about bad stuff, onto the good stuff. On our User Group Meetings (and also the MESConf we held the day before) we use something called “Open Space”. This is something that was invented by Harrison Owen and David Belisle. These guys organised conferences and in their evaluations they found out that most people liked the conversations they had during the breaks best. So they figured out a way to extend the conversations during breaks: cut the presentations and formalize the breaks.

There is a time/place plan that allows for multiple conversations to take place, participants determine the topics themselves, put them on a board on a specific time and place and others can, with a look on the board, determine what is interesting to go to.

Works like a charm, i’ve witnessed an Open Space conference a dozen times now and all were great. You can learn a lot in a short time.

More Info

This is one of the methods we use to spread our knowledge about MDSE/Rhapsody/Doors/etc. Other methods are:

this BLOG!

FaceBook

Twitter

IBM DeveloperWorks (Recommended!!!)

Rhapsody4You (please use Developerworks from now on!)

UMLforum (use Developerworks please!)

Andy’s Page

Training & Coaching

Download Portal

Support

You see, enough possibilities to extend your knowledge and become an MDSE Pro real fast! About the forums: In close cooperation with IBM (Thanks Johan Adelgaard!!) we decided to concentrate all Rhapsody knowledge on the IBM site. You will need an IBM ID to login but that is totally free and takes 1 minute to set up.

The next UML Trainings are:

  • 19. – 21.09.2017 in Stuttgart
  • 14. – 16.11.2017 in Bückeburg

 

 

Happy Modeling with Rhapsody!

Walter van der Heiden, wvdheiden@willert.de

Was ist grün und stinkt nach Fisch….

This week we are in Bremen, “we” being my son Robbert (who does an internship @ Willert) and me. The title is German and means:

“What is green and smells fishy”. This is what German soccer fans sing when they play against the local soccer team “Werder Bremen”. Because Bremen is near the sea and you can eat fish here. (Which tastes excellent by the way…) Later some pictures, now some Rhapsody!

Rhapsody First-Aid:

Sometimes Rhapsody is not working as it should. Many “problems” can be solved by installing Rhapsody in the right way and by using it the right way.

Here are some quick solutions that might help improving your Rhapsody Experience:

  • Use the 32-bit version of Rhapsody.
  • OK, Rhapsody brings its own Java JDK but please see that you have a 32-bit version of Java installed.
  • When possible, install “as Administrator”. Just install as admin, do not login as admin!!
  • Do not use “Install for all users” when installing. Please….
  • Do only use “Install all files in one directory” when you install outside “c:\Program Files”, otherwise: don’t!
  • Rhapsody installs in 2 directories: Programs (default: “c:\Program Files”) and Data (default: “c:\users\<you>”)
  • Always install the developer. You can later start the correct version by editing the “rhapsody.ini” file or via the command-line.
  • Edit rhapsody.ini to start the version/language you need. DefaultEdition = Developer/Architect/Designer …, DefaultLanguage = C/C++/Java
  • Install only the languages you _really_ need.
  • If you have multiple versions of Rhapsody installed: only the last one is the default!
  • Before trying to fix stuff: remember that a re-install does not take long.

After installing:

  • When starting Rhapsody for the first time: do it “as Administrator”.
  • Rhapsody heavily relies on the rhapsody.ini in the Data directory (Share) check if there are no duplicates (e.g in the c:\windows directory)
  • Using Rhapsody as Eclipse starts the Version/Language as set in rhapsody.ini
  • Rhapsody is sensitive for having a “Bad Windows”. Many crashes are an indication for a DLL Problem.
  • In 8.2 there is a known Problem when “Active Code View” is on and a diagram is opened.

We hope that this helps you when installing and using Rhapsody!

 

Walter van der Heiden (wvdheiden@willert.de)

Newer posts »

© 2026 Rhapsody TechBlog

Theme by Anders NorenUp ↑