Tag: travel (Page 6 of 6)

Liechtenstein – Small is beautiful

September 27, 2017 / rhapsody207 / 0 Comments

Liechtenstein

This week is another traveling week. From home via the office to Liechtenstein, 940 kilometers in one day. Follow the star….
It’s training week, again a couple of developers that want to learn how to model in Rhapsody.
People ask me sometimes, “Don’t you find that boring, telling the same story over and over?” But then I always answer: “Yes, that is boring. But to make it bearable I always tell it to different people!”
No it’s not boring, I like trainings, always. It is nice to help developers learn to model.

Liechtenstein is very nice, beautiful country, squeezed in between Switzerland and Austria. Mountains on one side, the Rhine on the other side.
The country is 160 km² large which is slightly larger than the city I live in… 36000 inhabitants. And rich…. very rich…. Many people have bank accounts here to avoid paying tax in other countries. That is their main income it seems.

So what can you do in Rhapsody to make your code smaller? I assume you are using an RXF from Wilert, otherwise the first you can do is ditch the OXF (or whatever you are using) and start using the RXF from Willert which is much smaller and much faster than other frameworks. The Frameworks with OO-RTX as RTOS are the smallest, they do not have preemptive scheduling but if you don’t need that, this is the RXF to go with.

We don’t do destructor…

An embedded system just works until switched off. And we do not have to care about freeing memory or cleaning up structures. So we can use the properties to prevent Rhapsody from generating them. These properties control that:

CG::Class::GenerateImplicitConstructors
C_CG::Class::GenerateDestructor
C_CG::Class::EnableDynamicAllocation

HighWaterMarks

The RXF knows highwatermarks, they indicate how many memory blocks you have maximally used at the same time. The same for events and timers.
A good way to estimate the optimal use of your static memory is to use the compilers “mapfile” to determine the size of all structures you are dynamically (or semi-dynamically) allocating. Then optimize your memory structures by making your tiny, small, medium, large or huge blocks exactly as large as the structures you use.
Then determine the maximum number of blocks you need from every size. If you do not need 5 different sizes: make the block count 0, then the structures will disappear completely. The same for timers, if you do not use the “tm(xxx) statement in your state-machines, set the TIMERS to 0.

State-machine

Rhapsody uses an int for the state-variable. If you use less than 255 states in a state-machine you can easily use an unsigned character for that. This is the property:

CG::Class::Statechart::FlatStateType

Inline

Create inline functions for operations that are not or hardly used. The RXF knows the inline keyword that you can replace with the compilers inline keyword. On some controllers a function call is much more “expensive” than replacing that with the original statement from the called function!

C_CG::Class::IsCompletedOperation
C_CG::Class::IsInOperation

Compiler

Most compilers have excellent optimizations. Switch them on, try all settings and make an overview (Use Excel!) of all the effect you can measure, (Size, speed)

Oktoberfest

September 19, 2017 / rhapsody207 / 0 Comments

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

July 19, 2017 / rhapsody207 / 3 Comments

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)

July 16, 2017 / rhapsody207 / 0 Comments

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

July 4, 2017 / rhapsody207 / 0 Comments

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

July 1, 2017 / rhapsody207 / 0 Comments

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!)

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….

June 14, 2017 / rhapsody207 / 0 Comments

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)

AUTOSAR meets Fjällbacka

May 18, 2017 / rhapsody207 / 0 Comments

The Willert AUTOSAR Team (Clemens Maas and me) regularly visit the AUTOSAR meetings. (See: AUTOSAR WebSite)

Since our successful introduction of Rhapsody @ Marquardt (See: Referenzstudie (German) ) we do more and more Automotive. The increase of software in cars is helping us to more and more Automotive customers that are all struggling to create their software in time and without (greater) errors.

AUTOSAR is the Automotive worlds standard to improve software development. It is an organisation that is founded by the major (mostly German) Car manufacturers. You can become a member and in that way cooperate and contribute to the software standard.

What does this have to do with Rhapsody? Good question…. I’d say: everything. With Rhapsody (UML or SysML) you can also improve your software quality, time to market, re-use and more. The combination of both worlds is, however, not really easy.

Many AUTOSAR artefacts look like UML or SysML artefacts but are different. Rhapsody is used to store everything in its own database (not a real database but it’s own file format) and not used to export stuff to cooperate with other tools like MatLab. This is something that is defined in AUTOSAR, the ARXML files that you exchange on all levels for information interchange between tools.

Rhapsody has an AUTOSAR profile that allows the import and export of ARXML files. When you want to use Rhapsody for Architecture you can then export your Rhapsody model as ARXML to do further work in other tools. The other way around is also possible, you can draw your architecture in a Vector or Elektrobit tool, export ARXML, import that in Rhapsody and then create RIMBOs to add behavioral elements.

Sounds complicated and… unfortunately…. it is. We at Willert have designed an “AUTOSAR light” solution that allows the use of Rhapsody on a much simpler level. We import ARXML but convert all items to standard UML items. You can add behavior in a normal Rhapsody way, generate code and… it works. in the current version you have to do some stuff by hand but we are working on automating that as well.

So….back to Fjällbacka… a very nice town, we can recommend a visit!