User Tools

Site Tools


State machine file format

The file format is hierarchical in nature, the outermost topic is a component. This topic has a number of sub-topics indicated by a colon at the end of the topic. Each sub-topic has the same amount of indentation relative to the topic. Sub-topics may in turn have sub-sub-topics, etc.

For example:

component Comp1:
        Comp1 is the first component

    initial startup

component Comp2:
    initial setup

In this example, component Comp1 is the first topic. Since it is followed by a colon, it has sub-topics. In the example, the two sub-topics are description and initial startup, since they both have the same amount of indentation with respect to component Comp1. The line component Comp2: on the contrary starts at the same column, which indicates it is the next topic in the file. The description: sub-topic of component Comp1 ends with a colon too, which means it has a sub-topic too, namely the text of the description.

There is an additional abbreviation. If there is one sub-topic, and it is one line, you may also put the sub-topic after the colon of the topic. For example, the description sub-topic may also be written as

component Comp1:
    description: Comp1 is the first component

As a compact notation of topic hierarchies in these Wiki pages, topics and their sub-topics may be written after each other, seperated with a slash character (/).


Topics and sub-topics

Below is a list of topics and sub-topics supported by the tools at this moment, displayed as a nested list of items. Each element starts with the name of the (sub-)topic, followed by a short description.

  • component <name> A state machine component named <name> is being defined below
    • description Textual description of the component
      • Text of the description
    • initial <state> The state <state> is the initial state of the component
    • state <name> State <name> exists in the machine
      • description Textual description of the meaning of the state
        • Text of the description
    • event <state1> → <state2> An uncontrollable event may happen, transferring the machine from <state1> to <state2>. An uncontrollable event here is an event that is forced upon the controller.
      • label <name> Label of the transition is <name>
    • action <state1> → <state2> A controllable event may happen, transferring the machine from <state1> to <state2>. A controllable event is an event that the controller can choose to perform or not, ie it is forced upon the environment.
      • label <name> Label of the transition is <name>

The notion of action and event itself seems quite fixed. However depending on the modeler, the abstraction level, or the intended purpose of the specification, actions and events seem to be interchangable. What is an event at one place can be an action at another place. It is not currently understood how to deal with this phenonemon.

Other recognized syntax

The file format is more liberal, it uses the hash character ('#') as line comment character (like in Python). Also, empty lines (lines containining white space only) are silenty ignored. Last but not least, lines that end with the '\' character are concatenated (after discarding the '\' and the newline from the source).

Adding real-time behavior to the component

For real-time implementation purposes of a component, behavior in the real-world needs to be attached to the transitions of the component in the form of triggers. Both actions and events have been extended with a trigger sub-topic. Its meaning is when the trigger is activated, the transition is taken (and other transitions from the same state are not taken) and the component progresses to the next state. Currently, the following triggers exist:

  • Send and receive events from channel:
    • self.jabber.receiveEvent ( channel ) takes the transition when a value is recieved from the channel (channel is a Python string), received value is put into self.result
    • self.jabber.sendEvent ( channel , value ) takes the transition and sends value is over channel (channel is a Python string)
  • Interfacing with hardware is done via the objects passed to the component during construction. Depending on the type of hardware interface, it supports different actions
    • A binary output object supports self.obj.set() and self.obj.reset().
    • A binary input object supports, self.obj.wait(0), and self.obj.wait(1).
    • An analogue input object supports
  • Choice
    • event.GuardedEvent ( predicate ) takes the transition when the predicate is true
  • Timing
    • event.DelayEvent ( length ) takes the transition after length seconds delay

The hardware interfacing objects are passed on via initialization of the component using the following extension:

  • component/initial/def init(<parameters>): Initialisation during start-up is expressed as an init function. <parameters> is the list formal parameters of the machine. The first one should be self as is common in Python.
wonham/fileformat.txt · Last modified: Monday, 20 March 2006 : 14:34:10 (external edit)