Month: September 2017

Introduction

As I always tell the people who attend my UML Trainings: without using Classes and Objects to split up the work your application must do, it is impossible to handle todays complexity.

Programing used to be easy, in the early days of computers and the early days of embedded. The first boards had small controllers on them that had a few kilobytes of ROM memory and a few bytes of RAM.

Getting these to work from scratch involved a day of reading some stuff and applying power to the board, then your first blinking LED was reality. (and how cool it was..)

Later using 16-bit controllers, still with Kilobytes but now more than a few,  but using ‘C’ in stead of Assembler, this was already complex. Could take a few days to get the first stuff running. (Not to forget that you had to learn ‘C’ as well…

With UML the initial effort increases again, you have to learn UML, ‘C’ (or ‘C++’ ) and you have to install a lot more stuff. But this is also doable and after the initial effort you’ll notice that things go faster.

The complexity, however, is still increasing and the only way to master it will be to re-use existing stuff. This is only possible if we have “designed for re-use”.

Modeling or Programming?

That is the question. The difference is not clear to people who use Rhapsody for the first time, it is, however, crucial for the way you use your models and how you do the implementation. So just breaking up in multiple Classes and Objects is no longer sufficient, you need to be able to divide your models in “Components” that can be re-used without having to look deeply into them to understand what they do.

Rhapsody supports a couple of ways to do that in your model. You can use (parts of) other models. In the menu you have “File”, “Add to Model”.

Then a menu pops up that lets you select a Rhapsody model (Or a file in a model, i.e. a Unit like a Package or a Component) You can also select “As unit (with a “copy” tick) or as reference.

• As Reference, links the selected model element in the open model as a read-only reference. (Same GUIDs) You cannot edit the element in your Rhapsody model, you have to open the original model for that.
• As Unit, links the selected model element in the open model as a writable reference. (Same GUIDs) You can edit the element in your Rhapsody model and it will then change the original model as well.
• As Unit (with copy) copies the selected model element in the open model. (New GUIDs) You can change the element in your Rhapsody model but the original element will be left untouched.

GUIDs are the generated 128-bit ID’s that Rhapsody assigns to every Model element. Rhapsody uses the GUID to recognize model elements (It does NOT use the name for that!) So copying renews the GUIDs so there will be no name clashes with existing model elements.

Now try to model as independent as possible by using only unidirectional relations, eventually ports and interfaces. Use private attributes and operations when possible, at least describe the public interface as good as possible so re-use is easier while the re-user does not have to study the inside of your model.

Attention points.

• Paths. If you use referenced model elements, be sure that they are in the right path on all computers of all project members… Otherwise check-in  and -out will be a torture. You have to manually adapt the paths in your model. It helps to use relative paths in your model

  General::Model::ReferenceUnitPath
  General::Model::PathInProjectList
  can be helpful there. You might also use an Environment variable to point to your working directory and sync that with your colleagues. (Like the OMROOT variable that Rhapsody uses to make it independent where your Rhapsody Share directory is)

• Config Management. If you check in and out models and parts of models, it is easy to fetch a wrong version of a referenced model. Think about your CM structure!
• Names. Don’t use default names like “default” for th package, etc. Use meaningful names that can be used in their projects without causing collisions.
• Documentation. Is even more important when your model is re-used inside other models.

Tips and Tricks

• As long as you make changes in your model _and_ in the referenced model, load both models in a project (Using “File”, “Insert Project”. You have to switch the active project to make changes but it will reduce time. Rhapsody saves the Workspace separately! (You can even edit it if you make changes to your paths)
• Using Ports and Interfaces greatly improve the way you can use models in models.
• There are more ways to create Interfaces, see my Techletter about using Interfaces.

Dividing up your models.

If you have made a model that represents the hardware you use in multiple projects, you can easily use that model in all projects that use the same hardware. The nice thing is that if you have your version system right (perhaps even with a check in the model..) and really defined your interfaces, then you can use different versions of the hardware without really worrying about you model.
Another advatage is that referenced model load faster.

That’s it! Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

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 of. And we don 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

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)

Introduction

MISRA -Motor Industry Software Reliability Association. This is a comite that defines rules that ‘C’ (or ‘C++’) programmers need to follow to increase the safety and reliability of their code.
A customer asked me about Rhapsody and MISRA compliance, hence the BLOG entry…
There are multiple MISRA standards, for ‘C’ and ‘C++’. For ‘C’ there is 1998, 2004 and 2012, for ‘C++’ there is the 2008 standard.
Rhapsody has 2 profiles “out-of-the-box”, 1998 for ‘C’ and 2008 for ‘C++’. We (Willert) have created our own profile for MISRA ‘C’ 2004. It is delivered with our RXF Frameworks.

Is Rhapsody generated code MISRA compliant?

Yes and No. (In German they have the word: “Jein” which is a combination of Yes (Ja) and No (Nein). Beautiful word.)
First: there is no such thing as 100% MISRA compliant embedded code. It is almost impossible to write all code exactly as MISRA tells you, alone the code you need to control your hardware will violate multiple rules. The code that Rhapsody generates is created in a way that it is more or less compliant with some important rules.
If you load the MISRA profile, the generated code will contain comments to tell your checker tools that a rule is violated and why that is OK. But again: you have to check yourself and the MISRA part only applies to code that Rhapsody has generated by itself. The code that you type in yourself is as MISRA compliant as you want….

Restrictions

Code from relations with * multiplicity are not MISRA compliant, as is dynamic behaviour like instantiation at run-time and dynamic memory allocation.
Code for Ports in Rhapsody in ‘C’ is using recursion, code for interfaces uses pointer arithmetic. Both are not MISRA compliant and very difficult to prove right.

It is not compliant so it can not be used?

No, that is not how it works, Let me give you an example that I once learned from Günther Glöe from Tüv.
Suppose that you want to drive a nail into a wall. The only tool you have available is an old hammer that has a failure: the head is pretty loose and can fly of if used.
So… according to popular belief you have to refrain from using the hammer and drive the nail in the wall using your fist. I would personally not do that…. it hurts…
I would use the hammer but take precautions to minimize the risk of injuries and other collateral damage. I would remove objects from the vicinity of the place I want to drive the nail in the wall, warn all people in the neighbourhood to stay away and then carefully use the old hammer.
This is exactly what MISRA says: “Use with care”. If you have to violate a rule, then take care that you prevent this from causing disaster.

How To use Rhapsody and MISRA

• Load the MISRA profile
• check as soon as possible. If you wait with checking for MISRA, you will be flooded with error messages.
• distinguish between mandatory and advisory rules. You should comply with the first and try to comply with the latter.
• Document the violations as defined so that you can do a check run without warnings.
• create documentation that documents all the decisions you took and the measurements you took to prevent problems

How to test for MISRA compliance

You can (and should…) test if your stuff is following the rules of MISRA by using a checker. Some compilers (a.o. Tasking and IAR) have checkers built-in.
We always use PC-Lint because it is pretty good and very cheap. Other static checkers offer a lot more comfort and more but are way more expensive.

PC-Lint
Compiler
Polyspace
Many more check: Wikipedia.

What is that????

Open Space is a way to organize meetings and congresses invented by Harrison Owen.

Basically it is a meeting where there you define time/space slots and where all attendees can bring in topics. These topics are connected to a certain room and time, this is done on a board where everybody can see the topics and can apply to join the meeting on that topic.

The organizer will be in the designated room and time to start  the meeting, he.she will also tae care that minutes are being made so that others that could not be present ( e.g. because there was another interesting topic in another room) can still read what was discussed afterwards. There is some more to it, when you want to read more:

Open Space on Wikipedia

We always use that for our own events and it is a very succesful way to communicate with clients. The disadvantage, however, is that physical presence is required.

In the current time where we care about energy and environment, this is not what we want. So we invented “Virtual Open Space”, where we do an Open Space Meeting using modern technology.

We use doodle to find out what the topic is that people want to talk about, we then use WebEx to create a “virtual” room on the internet where people can speak with each other and, when necessary, share their screens with others.

Check out: Willert Open Space.

This weeks topic: UML debugging!

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Introduction

OK… today a little less Rhapsody Tech stuff and a little more about the rest of my life. Should be OK on a day full of snow….
So my company is actually older than Rhapsody… On september 1 we celebrated our 25 years existence with a big party. But… 25 years… what happened in this time?

History

In 1992 Andreas Willert founded Willert Software Tools. His business idea was to sell tools that were there to create software for a specific microcontroller, at that time the Siemens C166.
This sounds like a crazy idea now in 2017 but in 1992, the world looked very different. Try to imagine the world back then….
There were only 8 and 16-Bit Micro-controllers, a few 32-Bit systems were there but they would cost a fortune. Even the PC’s were small 32-Bit systems, an Intel 80386 on 33MHz was not a bad system in that time.

The development tools in those days were all DOS based, Windows 3.0 was there but not really used. Development tools were also very loosely connected, mostly via vague intermediate formats. Some tools had separate compilers, linkers, locators, debuggers and assemblers.
Andreas had much knowledge about that. he had been working for Hewlett Packard, selling Logic Analyzers and for Tasking who sold compilers.

Tasking is like a common thread through the history of Willert. Many of the people who are involved have something to do or have a history with Tasking. I have worked there from 1995-2001. Andreas and I have met on a Tasking event (Actually an EmWare event, a company that was active with IoT, 15 years too soon…) in Salt Lake City.

The choice for the Siemens C166 Micro-controller was a good one, with the 1992 knowledge. But the Infineon spin-off, the flash disaster and the lack of a good successor the C167 were things that were not good for business. Also development tools improved and there was not much need for an expert in connecting debuggers, emulators and compilers.

Andreas was always looking for new business opportunities and landed soon in the Modeling area with Telelogic SDL. Also EmWare’s EMIT that was being sold by Tasking as Master Distributor was in his interest. This is where Andreas and I met and started to do things together. In 2000 we held our first tour through Germany to try and find customers for the EMIT product. We were way too early (also a bit of a common thread in our lives)

In 2001 Tasking was taken over by Protel and was renamed to Altium. I was kicked out pretty soon, together with other people and I called Andreas to tel him that. We decided to meet and discuss what we could do together. Since that I am the co-owner of Willert Software Tools.

So from that on we could concentrate more on technical stuff. The rise of the use of modeling tools was a new opportunity to sell products because we had knowledge that would encourage customers to choose us as supplier. We became the distributor of a fresh German subsidiary of an American company: I-Logix. they had a UML Tool called Rhapsody, we obtained the rights to sell that, restricted to certain markets since there was another company selling that.

2001 was not really the best year to begin a business… There was already the internet crisis but after September 11 the phone stopped ringing and we had to fire people to survive. Slowly we fought our way back and re-hired most of the staff.

In the meantime i had created the first version of our framework, at that time it was just the “standard” OXF with the correct adaptation to run with CMX-RTX and, of course, the Tasking compiler. We called the product “Bridge” since it formed a bridge between all different tools.

The first Bridge should have been a ‘C++’ Bridge, for Tasking and CMX-RTX. After a few weeks of fighting (learning Rhapsody, understanding how to make an adapter, learning what an RTOS was, learning ‘C++’…) i figured out that adapting the OXF to TAsking was impossible. At that time it was not a ‘C++’ compiler but some front-end that would translate ‘C++’ into unreadable ‘C’. Luckily, the customer that ordered the adapter agreed on using Rhapsody in ‘C’.

Soon we received requests for other “bridges” for other RTOSes and compilers. The first Bridge was baptized “WST1” and we started working on WST2, ‘C’, C167, CMX-RTX and Keil. Reinhard Keil himself helped us to get this running and it was done a lot faster then WST1.

Just do it

After a while, frantically trying to create a market for UML Tools, we decided that the tool was overpriced. It was, perhaps, a good price for a UML Tool in the “IT-world” but it was priced 3-4 times as much as an average compiler. Andreas and I created a presentation that we held against the CEO of I-Logix, Gene Robinson who was visiting Germany. We suggested that we need a special version for embedded with a special (lower) price. His legendary words were: “Just do it”.
Gene Robinson passed away in june 2016. He was a great guy and we miss him very, very much.

A year later a customer asked for a Bridge without an RTOS. At that time Mark Richardson from I-Logix had created a Rhapsody model with a stripped Framework. I took that and created the first “lite” Framework. WST2lt was born. Although we thought that would be a “one-off” it turned out to be the #1 sold framework.

Versions and versions followed. The WSTxx names went and in Version 5 the Composers were introduced. Clemens Maas, our Development Manager at that time, loved classical music and took composer names to name the different Bridges. Beethoven, Mozart, Bach but also names with Easter Eggs like Sibelius (Finnish composer for the Linux Bridge) Wagner and Schneider (Customer names)

Telelogic

Then in 2006 I-Logix was bought by Telelogic. Quite a shock for us and for Telelogic. Business was shook up and we were not doing that well for quite a while. Telelogic was not used to having distributors and it was a small miracle that they kept us. Pro was that we also started to learn Doors which helped us survive the “Modeling Winter”.

After 2 years we were just about to get used to Telelogic and then the next take-over was announced….

IBM

Yes. IBM took over Telelogic and we started over again. This was a hard time for us, the IBM processes were very different and sometime pretty hard to understand and to implement in our own company. But we managed and are succesful un selling IBm products and selling our own products.

We are now with 20 people and active in Requirements Engineering, Model Based Systems and Software Engineering, we have our own tools like the RXF, the embedded UMl target debugger, the Requirements eXChanger, we are working on a very good Automotive/AUTOSAR Toolkit.

“In & Out” in 1992

Mobile phones were there but only for the rich and famous. Definitely no smart phones. Internet was just about to start but nowhere near to what it is now.

We had DOS and Windows 3.0, Windows 3.1 was released that year.

The war in former Yugoslavia started.

We had our own currencies, Deutsch Mark, Franc, Gulden etc.

The Olympic Winter and Summer Games were held in the same year every 4 years (in 1994 they would be alternated every 2 years staring in Lillehammer in Norway)

Czechoslovakia is split up in the Czech Republic and Slovakia.

in that year was the “Freddy Mercury Tribute Concert”.

El-Al flight 1862 crashes in Amsterdam.

Denmark became the European champion Soccer (“The Beach Team” because the players were called back from holiday since Denmark was called to replace Yugoslavia that was banned because of the war)

The Maastricht Treaty is signed, founding the European Union.

Presidents and world leaders then were George Bush (Senior!), Boris Yeltsin, John Major, Helmuth Kohl. Bill Clinton was elected as the new President of the USA.

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)