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)

What is it anyway?

Let me start by specifying what I mean when I say: reverse engineering, roundtrip engineering and forward engineering. All in the context of UML and Rhapsody of course.

• Reverse Engineering: Reading in existing source code and inserting it in a Rhapsody model in such a way that it continues to work.
• Roundtrip Engineering: Reading in source code that was generated by Rhapsody but was changed by the user. Note!: Please understand the difference between reverse and roundtrip! It is very different for Rhapsody to read in “strange” code then it is to read in “familiar” code.
• Forward Engineering: Something I invented myself (Or maybe it already exists then I just re-invented it…)  It is reverse engineering but the user will take the result and do the necessary steps to make a decent UML Model out of it.

So. As I already wrote in a previous post, I don’t like reverse engineering. Sometimes you need to do it but it is something that prevents good modeling IMHO.
Roundtrip Engineering is OK although Rhapsody knows 3 modes there: Basic, Advanced and Respect.

• Basic: Allows you to change code that is between the Rhapsody generated comments: /*#[ and #]*/ That is the code that you type in state-chart entry/exit/transition and in the implementation body of your operations. Nothing else, changes to other parts will be ignored when Rhapsody generates new code. Is not trivial since Rhapsody sometimes uses the same code twice and will then ignore your changes! (Of course without commenting it…. Rhapsody is a tool for real men…) ***Recommended Setting***
• Advanced: Same as Basic but also allows you to add attributes and operations. Is also OK if you know what you are doing but keep way from it until you know what the effects are of what you change.
• Respect: The “Evil Knievel” option. Or “Eddy the Eagle” if you prefer him. This allows you to change every line in the generated code. Rhapsody will try to keep it as long as it is syntactically OK. To make things worse, Rhapsody will store this information in “source artifacts” that are hidden by default. (I still wonder which sadistically inclined person designed that option….) ***Not Recommended at all Setting***. At least switch on “Show Source Artifacts” (“View”, “Browser Display Options”, “Show Source Artifacts”).

So you have to be careful using these options. This is all more valid for ‘C’ then it is for other languages like ‘C++’ and Java, these languages are much closer to the UML and ca therefor produce much better results when doing reverse or roundtrip engineering!

LCD Display on the Keil MCB1700 Board

We use that board for our trainings. We do this since years and we use the LCD display on that board using some ‘C’ files that Keil provides. GLCD.C and GLCD.H. Here are these files: GLCD so you can check yourself.

The .h file has function prototypes (Useful for checking which functions are “public”!) and the defines for the colors. Reverse engineering will show these as types.

The .c file contains a couple of defines that are reverse engineered just as the all the defines in the .h file. Then there are all the functions. After examining the functions we can see that there are “public” functions (GLCD_xxxx() ) and “private” functions (spi_)

In the training we include glcd.h via the “external file” mechanism and the dependency with “Usage” stereotype. Glcd.c is inserted via the Component file and a “text element”. This works fine (And is of course aimed at learning different methods to use legacy code)

Reverse engineering also works, I tried, you can call the functions if you have reverse engineered them.

But we want something else: we want Classes that are completely generated from Rhapsody! So first we will create a class GLCD. Since SPI works a little bit different we will use a Singleton Object there.

Then we move all the functions to the respective class/object. Nice side-effect: the “me-pointer” is added automatically! But unfortunately… not to the code. This is where you have to do some work, add me-> to all uses of the attributes. I have created attributes from a few variables like orientation, bbps and position. You can add them to the init function. That is something that also needs to be done by hand: The init function must be converted into a constructor (initializer)

The SPI functions are moved to the SPI object. No me pointer is needed there but I used the variables that determine the exact version of the LCD hardware to attributes, you have to add the spi.<attribute> yourself.

The colors must be converted to an enum type. A bit of work which cannot be done automatically but it is worth it! (Why this is not done in the original ‘C’-code??)

I added some fine-tuning like converting some variables to enumerations or at least types, always a good habit in programming: let the compiler check as much as possible!

The result is quite nice: RhpGLCD, see for yourself.

Happy modeling with Rhapsody and greetings from the Bavarian Forrest!

Walter van der Heiden (wvdheiden@willert.de)

Disaster days and how to handle them.

We all know them…. disaster days. Mostly they are already starting bad. Like cars that don’t start, public transportation that strikes. Rain that pours, people shouting at you for no obvious reason. That is a day where you should not have ignored the signs and have stayed at home in your bed. Sometimes this just happen “out-of-the-blue” sometimes it is self-inflicted while you suffer from an overdose of “cool party last night”

But no, we are tough. We persist and fight our way through the day. But the real surprise comes next day when everything is working OK until you check last days work….. This is the point where you start thinking about Configuration Management Systems or at least Source Code Control…. Too late, you should have done that before…;-)

Yeah Right….

Making a zip file from your working directory every day is a solution, (and definitely better then nothing) but there are better solutions, certainly if you are not alone in your company.

Source Code Control is very old, on Unix Systems this is been used since there are Unix Systems. In the personal computer area this is a bit newer but also used a long time. The last 10 years or so, many people use Subversion (SVN) or Git, sometimes still CVS. All these are open source systems, you can just download them and use them. Since millions of people have, these systems are good, very good.

Of course there are still commercial systems that cost money, sometimes a lot of money. That does not make them better than SVN just different and they have a phone number that you can call when things don’t work.

More then a backup

Config Management does so much more than just saving you from bad days, it helps you preserve versions and releases, it helps you cooperate with colleagues and prevent changing the same stuff twice (the first one in is out….)
Modern systems use automatic difference/merge tools that are pretty intelligent and can merge files that are edited by 2 persons. As long as not the exact same things are changed, these tools do a good job.

What does this has to do with Rhapsody?

Everything…. If you develop with Rhapsody you also want to preserve stuff, cooperate with co-workers and much more.
And… no…. you don’t just take the source code and put that in CM, the model contains much more information then just the generated source code. In fact, the code can be generated from the model ALWAYS. (In fact it is Object code…) so don’t bother checking that in. (Only if you don’t trust Rhapsody…. or if you want to speed things up.)
Yes! You put the model under CM’s control. Now how is that done?
Rhapsody does not have a CM System built-in, it uses either the good old command-line or the a bit better and a bit less old SCC, the Microsoft Source Code Control. The latter is a registered DLL that is called by Windows. Works faster (although hardly noticeable on modern computers) but much nicer then command-line.
Unfortunately neither CVS, nor SVN nor GIT know SCC… there have been tools to create an SCC Interface, PushOK and TamTam but both have been discontinued for years (and PushOK is Russian, used to be a problem in the US but that might have changed….)
Luckily we have created a profile for the use of SVN via command-line. It is included in all Willert adapters but if you want it: send me a mail, i will send it to you.

What do we CM then?

Units. What are units? That are files that Rhapsody uses to store its models. A Rhapsody model is not just one file, per default the base model file (.rpy), all packages (.sbs) and Components (.cmp) are stored in files. Since all CM systems are filed base, this is the only thing they can process in CM.
You can use properties to tell Rhapsody to store diagrams in units and you can even tell Rhapsody that a Class is a Unit (right click, create Unit) but I do not recommend that. It is a sign of bad design if you need Classes to be units.

How is the Workflow?

There are 2 possible workflows

• Old-fashioned lock and free
  Once checked in CM the model is read-only until you check-out your “unit”. This is then locked for all others until you check it in again.
  In that way nobody can accidentally overwrite stuff that others have made.
• Work and Merge
  All members of the team have a copy of the model, they all work on it until happy, then use the (included) DiffMerge Tool to merge the changes in the base version. There is more risk that people are changing the same model elements but many of these changes can be automerged back.

Which is the best workflow? As usually: that depends. On how you work, with how many people and more. Also on how you have built-up your model, do you have one large model? Or do have divided into multiple models? In one of the next BLOG entries I will write more about methods to split the model up in smaller models.

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Why a Framework?

Actually quite easy. When you generate code from UML you need a lot more then ‘C’ or ‘C++’ can offer you. Java is different, it has a VM that does most of the things you need. But ‘C’… how do you start a thread in ‘C’? Or how do you start a timer in ‘C++’?

Right. You can’t. At least not in the base language, you need an external library for that.
The “extra” functionality in the UML is all RTOS based functionality. So it seems logical to use an RTOS for that. To make the use of any RTOS easier it is smart to implement this in a framework that does the translation to your RTOS. in that way, the only thing you need to do is adapt the Framework to your current environment and your UML model should be runnable in that environment.

In an embedded environment this is only part of the story, many hardware and even compiler dependant parts exist. Modeling certainly helps you but you should take extra care to separate your hardware dependant parts in your model.

Also the framework adaptation is not always straight-forward but the reward is high when you stick to the standard: you can be independent of the environment you use.

We have done a model conversion from one environment to another environment twice, both times it went with minimal effort. As close as you can get to the holy grail of embedded software development: platform independent programming. But I will be honest… we are a long way from reaching that in the embedded world.

What Framework?

There are quite a few Frameworks for Rhapsody. Out of the Box there are already a few. Are they any good? As always, the answer is: that depends….

On what? On what you want to achieve with it. Creating a PC application, Linux or Windows? Real-Time does not bother you, nor do you care about memory usage?
Than the standard OXF is your friend! It is the default in Rhapsody, you don’t have to do anything. If you are lucky enough to own a developer edition, animation, panel diagrams and webify are there to support you.

What Frameworks are there to choose from:

• OXF, standard Framework
  Is not small, is not fast, is not deterministic, blocks interrupts for unknown time, uses an RTOS.
• MXF, MicroC (Automotive) Framework, uses OSEK as RTOS
  in combination with the AUTOSAR import/export
• SMXF, reduced MicroC Framework
  Targetted for use in Certification projects
• RXF, Willert Framework
  Small, fast, C and C++, UML Target Debugger for back-annotation, enhanced Workflow, available as Cert with documentation.
• IDF – Interrupt Drive Framework
  Single threaded. Started as a demo for “how the framework works”, is available and adaptable. Was designed to be small
• SXF – Simplified C++ eXecution Framework
  C++ for Safety critical. Is also only static
• synchronous Framework
  For very small environments, discards a lot of UML functionality, programming only with triggered operations.
• NOF, No Framework
  For the real die-hard…..
• ?? Did I forget one?

So here we have a few criteria that you can use to support your framework decision:

• Code size, use an RTOS or just a main loop?
• Language, C, C++ or else?
• (Real-) Time behavior, are interrupts disabled? If yes for how long?
• Safety viewpoint, MISRA? Is there documentation about safety?
• Animation and Back-annotation, UML debugging available?
• Simulation, on PC?
• Hardware abstraction / Portability, fast switch to other environments?
• Memory Management, static or “half”-dynamic?
• Workflow, build in Rhapsody or elsewhere?
• Limitations, Ports, Container Classes, Dynamic, etc

Check the criteria before you make a decision. As you can see, the Willert Frameworks (RXF and RXF-Cert) have excellent notes on all items.

PEPS

We use a model to test framework speed, the speed unit we have is PEPS (Processed Events Per Second) We have invented that ourselves since there was no other measurement available.
The model is there for use in other environments, it is pretty standard so it must be easy adaptable to other environments. Ask me if you want to have it!

Happy Modeling with Rhapsody

Walter van der Heiden (Email: wvdheiden@willert.de)

Yes who?

Everybody of course. Don’t be daft. I know software developers hate writing documentation. Why do i know that? I am a software developer myself… takes one to know one.

But when using Model Driven Software development, documentation is not that hard anymore. In fact, you are writing documentation while you are developing, almost without noticing it.

Oh, don’t get me wrong here, it is not done fully automatically, you have to do the right things, like putting effort in the way you build up your model. When you don’t, the same happens when you write source code without documentation.

It is fully possible to create a working (meaning: the code you generate will do what is expected) UML model from Rhapsody without a chance to understand what is happening by reading the model. Or as we used to say: you can mess up things pretty bad but to really screw things up requires a computer…

So. Let’s assume we modelled the right way. Now what? The boss wants to see what we did and I have to present the model for him/her on paper. How do we do that?

Well: Rhapsody offers multiple ways to document your models and make the information available to others.

1. Use Rhapsody. Sounds a bit awkward but the best way to look at Rhapsody models is with…. Rhapsody. Don’t start with: But that is too expensive… there is an Architect Version that suffices for viewing the model for about € 600,- But a tiny bit of knowledge about models is required so that might not be the 100% solution.
2. Use Reporter. It’s free. And it does documentation! So where’s the drawback? Well… it does documentation but that;s about it. There’s no formatting, you can only decide on a high level what will be in and what not, it’s just in RTF, no other formats and you can edit the documents but they will be overwritten when you regenerate them. So…. only limited use.
3. Reporter Plus, is the version that costs. I’m not sure what the price is but since you ony need one, normally, that should not be a problem. This can write Word, PowerPoint, RTF and even HTML (with javaScript). The last format is pretty cool, it can build a web version of the model where you can click your way through as if you are using Rhapsody. The creating of the documentation template is a lot of work but not really complicated. Can document what and how you want.
4. Publishing Engine is the successor to the Reporter Plus. Can document data from multiple tools, that can be quite handy when you also use Doors or other IBM Tools. Must also be purchased , but again, mostly only one license is needed. Is also not too complicated but a lot of work to make perfect documentation.
5. Another method is often overlooked. But is sometimes the best way to do stuff. The Rhapsody Java API! It can access the model, it is built-in, (for free!) and is not too complicated. You are free to create any doc you like.

So. I hope this helps you in deciding how to document! If you have any questions, don’t hesitate to ask!

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)