User Tools

Site Tools


wonham:fileformat

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wonham:fileformat [Monday, 20 March 2006 : 14:34:10] (current)
Line 1: Line 1:
 +====== 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:
 +<​code>​
 +component Comp1:
 +    description:​
 +        Comp1 is the first component
 +
 +    initial startup
 +
 +component Comp2:
 +    initial setup
 +</​code>​
 +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
 +<​code>​
 +component Comp1:
 +    description:​ Comp1 is the first component
 +</​code>​
 +
 +----
 +
 +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 (''/''​).
 +
 +NOTE: THIS COMPACT NOTATION IS NOT SUPPORTED BY THE TOOLS!!
 +
 +==== 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 //​trigger//​s.
 +Both //action//s and //event//s 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.read()'',​ ''​self.obj.wait(0)'',​ and ''​self.obj.wait(1)''​.
 +    * An //analogue input object// supports ''​self.obj.read()''​.
 +
 +  * 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)