Software Tracing

Software Tracing

In the December 2010 Embedded Systems Design “parity bit” column, Mira Samek of  state-machine.com writes “Instead of re-inventing all this for every project at hand, you can combine them into a generic, reusable state machine *framework*. A framework like this allows you to take software tracing to the entirely new level, because a framework funnels all important interactions within the system. … This sort of software tracing is not just a theoretical possibility.  For example, the open source QP state machine frameworks that I’ve described in my book Practical UML Statecharts in C/C++, 2nd Ed contain software tracing instrumentation called Q-SPY.”  [Where UML stands for Unified Modeling Language.]

So the QP state machine framework is another framework that treats all the events that cause particular routines to execute.

I expect that the code for the state machine states of the open source QP state machine frameworks must be one routine for each state in order that the framework can execute the correct state for a given event – just as in the Exploratory Project Message Controller (mC) framework.  That is, that the state machine selection mechanism can’t be promoted to the framework without making the code for each state into a separately callable method.

As Mira Samek points out, having the selection done within the framework allows instrumentation for software tracing to take place automatically in the framework without the need to add it to the code for the various states.  Therefore, I propose to add such tracing via logging to a disk file to the Exploratory Project mC.  Since various applications of the interconnected network can reside on separate computers, a disk file will be necessary for each application.  Or, perhaps, a logging application can be implemented to receive and store the trace output of each of the networked applications.  This would depend upon the sequencing of the communication mechanism to indicate the relative occurrences of the events in the various applications.

Dynamic Display Update

Dynamic Display Update

To illustrate the ability to dynamically update of the display by a user application of the Exploratory Project I added a text box to the second display layer via the display definition file (DF) and a periodic timer component to user application App2. 

The specification of the text box with its widget identifier was all that was necessary to have the Display Application display the text box and then display the date and time in the box each time commands are received to clear the text box and write new text to it.

The addition of a timer component to user App2 that sends commands to display layer 2 of the Display Application was all that was necessary to periodically output the commands for the particular widget identifier.

Upon install, at initialization time, this periodic timer component was registered to be run every 5 seconds.  This component was implemented to read both the system date and time (that is, GMT) and the local date and upon each execution.  Using the system and local times provided by Windows, it then creates a display command topic for layer 2 for the widget and publishes it for the Display Response subcomponent of App2.  Without needing any modification, every time the Display Response subcomponent of the Display component receives the topic it, in turn, automatically transmits it to the Display App.

Whenever the Display App receives the command for the layer it causes the thread that outputs to the particular Windows form for the layer to run.  The command is then decoded and output to the Windows text box control is performed to cause the new values for the date and time to be displayed.  Since the correct user thread is running, Windows problems due to cross-threading of controls is avoided.

Upon running the three applications (Display and the two user applications) the new text box of layer 2 is periodically updated with the date and the two times.  All that was required was the addition of a minor component to the one user application and without any need to modify the Display Application.