Intro
This article describes a new way of dealing with relatively complex status diagram driven control systems which I developed for my own use. It may inspire someone else to use it for his/her own projects.
Many of the real-time processess can be described by means of a Status diagram which is perfectly fine for systems without complicated timing dependencies.
When there are many processes running independently, each of them can be described by its own state diagram.
In cases where processes have their own timing and needs to be mutually synchronized, status diagrams become a bit impractical for describing mutual relations between processes and programming of the many intertwined processes can easily become a nightmare.
Sometimes, it is necessary to set some parameters on the target system. If there are many of them and they are part of the status machine it is useful to represent them in the state diagram for easy modifing of their values.
There are following aspects of the problem
- how to graphically represent the state machines and their mutual dependencies
- how to easily convert the graphical representation to a code
- how to easily browse the code
- how to verify that the real target system behaves as expected
1. Graphical representation
For state machines with a lot of branching classical state diagram is probably the best tool. On the other hand, for processes mutually dependent based mainly on the timing, the solution is to use time-based reprenentation of each process including its states and process synchronization
2-3. Converting graphical representation to a code and code browsing
Standard implementation of the state machine is one big switch statement where each node (case) represents one state and the action are taken based on testing various conditions. The conditions and transition actions are usually placed in the case statement. In case of status machine with many states and many conditions, it is usally difficult to navigate, especially after some time of writing of the code.
4. Tracing the behaviour of the target real-time system
Very often it is necessary to verify that the target system software executes correctly and that the timing is as expected. For this purpose it is a good idea to log the transition changes in the database and evaluate what was happening on the target system and when. The log is bound to the source code so that it is easy to trace the state transition in the log and watch the appropriate source code at the same time.
Each column in the log table represents one state diagram. Colors diferentiate events: state changes, signals, debug informations. As the target system keeps track of the real time which is used for event logging, it is possible to measure time between events in the log.
The log is automatically stored in the database. If needed it wouldn't be a big problem to write a program simulating target system behavior based on the log or compare behaviour of the target system when it is working correctly and when it is misbehaving.