USA
Table of states visited
My first visit to the US was in november 1999. I had to be in Salt Lake City for work and took the opportunity to visit my friend Arno, who lived in Philadelphia back then. He worked in DC and I flew there to drive with him to Philly.
From there I went to Utah but on the way back l took a small stop in New York to complete a real cool trip with a visit to already a number of states.
Cancelled flight
From that moment on I flew to the US almost once a year on average. And kept on visiting states. In 2004 I was on the way to Las Vegas together with Andreas Willert for the I-Logix Kick-Off Event. We booked the flight from Amsterdam via Minneapolis. We travelled a few days before the conference and wanted to drive around Las Vegas to see some of the Parks there. I already booked a hotel for the first night in Vegas and we planned on driving around and find ourselves places to stay on the go.
Unfortunately, KLM/North-West were not able to produce a working plane on the day we were supposed to fly so we had a forced night out in Amsterdam.
I phoned the hotel in LV to shift our stay for one day, just to find out that the next night was “Superbowl night” and the hotel price would not be $49,- but $249,-…
So I told the to shove their room somewhere dark and let KLM deal with it. It was their fault. (But my problem……as I found out later)
Luckily a have a friend who lives in “020”(As we from Rotterdam call our Capital, it’s the telephone area code) guided us through the city and after some beers (and some more) the next day we stood, slighty hangovered, before the KLM desk to get a room in LV for the next night.
They could not help us, this would have to be sorted out in Minneapolis they said.
So we first flew to Minnesota and went to the KLM desk over there to find out how they planned to get us in LV. It turned out to be a quite late flight that would arrive in LV on 00:30. They also told us to sort the hotel thing out when we arrived in Las Vegas.
This is where I intervened and said: no way I fly to LV without a hotel room.
So after some negotiations KLM booked us a room in Minneapolis and we rented a car to drive to LV because: What’s the difference? We wanted to drive around in LV and now we were driving around in the USA. No difference?
A small difference…
As it turned out, there was a small difference. We landed in Minneapolis, we noticed that it was snowing there. What we first noticed after we rented a car and went to five (5!) sliding doors to pick up our rental car. After each door the temperature dropped for more than 10ºC….
It was cold there. And I mean really cold. On the way to the hotel we were overtaken by a snowmobile. That was the first time I saw a sno-bolie in my entire life….
In the hotel we watched television just to find out that the USA was in something they called “The Blizzard of the Century”….
So the driving thing turned out to be a co-called “Bad Idea”
( “Bad Idea” is a trademark of Microsoft Corporation )
So we decided to drive south as soon as possible to find better weather and to avoid going through the Rocky Mountains where this would certainly be worse.
So we did 3500 kilometers USA with at least 95% of that through the snow. Even on the Grand Canyon there was 50cm of snow. We have seen more crashed trucks and cars than in the rest of my life.
But we arrived in LV where is was nice and warm. And we passed about 12 states on the go.
State Count
As you can see in the state-chart, my current state count is 33, I hope that the next trip will bring me at least 2 more.
State-machines
OK, now a little about UML and Rhapsody. State-charts or state-machines are an important part of UML but certainly of Rhapsody. This, of course, stems from the fact that Mr. State-machine, David Harel, is the founder of I-Logix, and one of the fathers of Rhapsody and Statemate, it’s predecessor.
Although it is said that David Harel invented state-machines, this is not true, he merely described them thoroughly for the first time. His definition was take into the UML.
There are many more implementations and definitions of state-machines.
State-machines are excellent when you implement behavior that has discrete logic. For Control loops, it may look tempting to use a state-chart but that is a mistake. There are far better mechanisms to model continuous behavior.
Example
Picture: You have a new job at the software department of “El Cheapo” a manufacturer of computer LCD monitors, know for it’s really good value for money displays.
Your new boss gives you the assignment to make the software for a new monitor that El Cheapo will release soon. The monitor is aimed at the lower end of the market so it has only 4 buttons: one for on/off, one for switching between brightness and contrast and 2 to control whatever you have selected (plus and minus)
You remember from your last job that you had a UML Training with Rhapsody (from some Dutch guy…) and decide to use that for your new job.
After 2 hours of thinking you have your first version ready:
Not bad for a new guy, you think and you are on your way to your boss to tell him about your success.
Your boss is impressed until he starts asking you about the “evMode”, “evDown” and “evUp”. “Where are these events coming from?” he asks.
“Easy”, you say, “The hardware guys have to send these events from the button interrupts when they program the hardware drivers”.
Your new boss starts rolling his eyes and drops backwards back in his chair. “INTERRUPTS???” he shouts! “No interrupts allowed over here!”. “Do you have any idea how dangerous interrupts are??”.
You ask: “But how do you detect that buttons are pressed then?”. “The safe way”, your boss replies, “by polling all inputs every 100 milliseconds”. “Sigh”, you think.
But no matter how you try to explain that this is so wrong, you are eventually forced to curb your enthusiasm and go back to the drawing board.
But… you never give up without a fight and you come back with another plan. You have learned in your Rhapsody Training (from that vague Dutch guy…) that you can tweak the generated code from Rhapsody using properties (see Properties. Stairway to heaven, highway to hell….) and you start tweaking the state-chart. You ignore the Framework (see Real-Time Framework, the robust base for your embedded applications. ) and you come up with this solution:
All events are replaced by guards. The state-chart code is now tweaked so that the generated function (rootstate_dispatchevent() ) can be called by the 100mS loop.
Some quick tests prove that this also works and now without interrupts.
Really???
Is the second state-chart really a functional copy of the first?
NO!!! it is not. In this example nobody would notice because 100mS is fast enough to fool humans. But suppose you press both the “mode” and the “up” button within the 100mS time frame. Which one is pressed first?
You can never know since you were not looking. The first state-chart knows while that uses interrupts and the framework. Events are stored in the queue and processed according to the FIFO principle.
You have to choose which of the variables “mode”, “up”, and “down” has the highest priority. And react too that. So the state-machine should actually look like this:
That is the big difference between these methods.
You have to take the priority into account and then create the state-chart like this:
If I show this state-chart during training, people tell me: “Walter… you always told us to use state-charts because they make it easier to understand your application.”, “This is not understandable”.
And they are right… this is not what I call a good and understandable state-chart. It’s a chaos. I checked it multiple times but I’m still not convinced that it is really 100% OK…
An easier way!
What!!?!! there is an easier way? Yes, there is… This is actually the state-chart that does the exact same as the one above here.
Does that state-chart remind you of something? Another diagram maybe?
It should… It is an activity diagram. Or flow chart (As the activity diagram of an operation is called in Rhapsody). Check it out here:
An activity diagram…. does the exact same that the state-chart does. And.. If you compare the LOC (Lines Of Code) you will see that the real state-chart (the first example with the events) uses more code then the activity diagram but it is more correct. The other examples (And certainly the incomprehensible one) use way more code and are much slower!
Conclusion
Use state-charts when you have discrete logic. For continuous logic or polling solutions: use activity diagrams or flow charts. Or use Matlab Simulink for control loops.
That’s it for today, happy modeling with Rhapsody
Walter van der Heiden (wvdheiden@willert.de)
