#xtuml

Although BrdigePoint has a great statechart designer module (depicted in figure above), which improves productivity a lot, the other parts of the software has some defects.

The suite comes with a module called Verifier, though it should be called Simulator instead, that helps to simulate and validate your state machines in design time.

Since the Verifier can be connected to platform-specific implementation code (such as Java, C, C++) through an interface, at simulation time events can be sent from the state machines to this code and vice versa. Thus it gives you a real simulation environment that can be even made cyber-physical, if the platform-specific glue code is necassarry for controling trains on a model railway!

However, there are some problems with the Verifier.

Although it is single threaded, the interface that shall be used for raising events from the platform-specific code to the simulation environment often threw NullPointerException if we used it from multiple threads concurrently in Java. This bug was not justified by any means of the structure of the state machines or the platform-independent code written inside them. We reported this non-deterministic bug to the developers, but has not found any resolution yet.

Second, we caught some weird exceptions from the Verifier, that originated from the real depth of this module. Because xtUML BridgePoint Editor is open source, we received the advice to debug and fix the errors ourselves, and then push it its GitHub repository. The only problem was, the code base is huge and its quite difficult for a developer to get involved and fix the bug in a not too long time, because we shall develop our system as well.

After the Verifier, we had some problems with the code generator module too, called Model Compiler.

First, the generated C++ code could not fit in our Arduino Uno embedded controller’s program memory (read What this project was all about). It was mostly because of the complex structure of our state machines, so we decided to write an own model compiler using BridgePoint’s own query language, RSL.

Here comes the second and the greatest problem regarding the extensibility of BridgePoint. The RSL (Rule Specification Language) is a query language (just like SQL) that should be used if you would like to transform your platform independent state machines to platform-specific code.

Because the state machines are platform independent and they are model-based, they have a metamodel that describes what elements can be found in a state machine model. This metamodel is so complex and there are so many associations and non-trivial paths in it, e.g. fetching the exact order of the OAL expressions that are written within the states requires 10+ classes and associations to go through. Inspecting the meta model requires days, because it is separated for 30+ packages and 3-40+ classes are in each package. In the figure above the metamodel package for State Machine is depicted.

So if you have much time, maybe years, you can write your own code generator in BridgePoint.

That was when we started to look for a new statechart editor, and found Yakindu Statecharts. It is open source and much easier to be extended by a code generator.

Safety logic

The class diagram is depicted here:

It is quite complicated, so I describe it in short. Section and Turnout (or switch in better terminology) were differentiated.

Section

Section can be FreeSection if no train is on it, otherwise it's OccupiedSection.

The behaviour of the FreeSection is quite simple, it simply allows any train to come to the section. Because its so simple, it is not depicted now. :-)

But, the OccupiedSection is more interesting, because it contains a more complex logic in itself:

As you may see, there is some text in the squares, that are called states. The edges connecting the states are called transitions, which have events or triggers written on them. If an event is occured in a state, then the respective transition is fired, which means the state machine moves from one state to another.

As an illustration: in BridgePoint one can write platform independent actions, in the BridgePoint's own language, called OAL (Object Action Language). With the help of actions, we can create and fire events, instantiate new state machines, create references between objects, and so on. Actions can be written within edges and states as well.

E.g. in the BecomesLocked state the next OAL code is written:

select one section related by self->Section[R1];

send Port1::setSection(sectionId: section.id, isEnabled: false);

It gathers a reference for a section, and sends a setSection event with several parameters through Port1.

Turnout

A Turnout can either be Straight, or Divergent. It is illustrated on the following picture (the recent direction is marked with black):

The logic for the Turnout was designed in a three-level hiearchy (see the high-level class diagram on the top of this post!). Only one column of the hierarchy exists at a time, depending on the recent direction of the turnout (or switch).

The first level is responsible for rejecting new events that are received while a former event is being handled by the hierarchy.

The second level is responsible for handling events which are received from perpendicular direction than the turnout's recent one.

The third level is actually responsible for what we call safety logic itself.

It is quite complex, but on high-level it can be described easily; we have to stop trains if they are close to each other. On this level we are prepared for the worst-case scenario, which means the trains are approaching to each other!

Trains are either in the territory of the local turnout, or a remote one. Thus turnouts have to communicate with each other, whcih adds an extra complexity to the system.

Wrapping up this long post

Ugh, it was quite a long post, but we hope you liked it, and found the state machines fascinating.