Tool for Visual Editing, Code Generation, and Monitoring of Interpreted Finite State Machines

Final Evaluation

(97/100) - The states and transitions didn't show the source code on hover.

Interpreted Finite State Machine

In this context, an interpreted finite state machine refers to a Moore-type automaton that responds to input events, executes internal actions, and generates outputs.

Features:

• The automaton is extended with a set of variables that can be manipulated by algorithms (actions) assigned to states. The automaton can react to input events through conditional transitions and generate output events as part of state-assigned actions. Transition conditions (guards) may include not only required input events but also Boolean expressions based on the values of variables. Additionally, transitions can be defined with a delay.
• Thanks to scheduling delayed transitions, the specified system can react to inputs and develop its own activity (proactive behavior).
• The described model is a specialized modification of a UML state diagram, specifically a simplified variant of an Execution Control Chart (ECC) used in control systems (according to IEC 61499).
• For simplicity, inputs and outputs are assumed to be of type String only. Internal variables can be of any type allowed by the inscription language (typically C/C++).
• Placing a value into an input constitutes an input event. A transition from the current state may respond to an input event; the event is ignored if no transition is triggered. The value stored in an input (i.e., the last known value of the corresponding input) is always available for reading and can be used in transition guards and state actions.
• Output events are generated by sending a value to an output within a state action.
• An example and detailed behavior of the automaton will be described later.

Tool for Visual Editing, Code Generation, and Monitoring

Features:

• Enables visual specification of an automaton (state and transition diagram, inputs, outputs, and internal variables). Transition conditions and state actions can be specified using an appropriate inscription language, ideally a subset of C or C++, which facilitates code generation (though other approaches are possible, as described later). Internal variables and their initialization will be specified in the same manner.
• Allows the complete specification of the automaton to be saved in a human-readable text format, which can also be manually edited if necessary. This stored automaton can be loaded and further edited. The code will also be generated from this text representation (details provided later).
• Provides a one-click process to generate the interpreter code, compile it, run it, and then connect to it (e.g., via UDP sockets) to inject inputs at any time and continuously receive, log, and display all events in real-time within the GUI. (Alternatively, execution and communication can be handled differently, such as via a shared library or a built-in interpreter for an appropriate language instead of compiling the interpreter.)
• Displays the current state at runtime (highlighted in the diagram) and the last known values of all inputs, outputs, and internal variables.
• Displays an event log at runtime, including date and time, the current state, and the values of inputs, outputs, and internal variables.
• Allows asynchronous injection of updated input values during runtime, as the user specifies.
• On startup, attempts to connect to a running automaton if one is found. It retrieves its name, loads the corresponding source file, displays the automaton, and monitors it by continuously displaying its entire state. The running automaton can be requested to terminate upon user command.

Execution Algorithm of the Interpreted Timed Automaton

1. While there is no termination request:
   • While there exists an independent executable transition from the current state:
     • If it is an immediate transition, change the state and execute the state action.
     • If it is a delayed transition, set a timer for this transition.
   • Remove timers for transitions from non-active states.
   • Passively wait for a timer expiration or an external input, then:
     • If a timer times out, determine which one, remove it, and perform the corresponding transition, i.e., change the state and execute the state action.
     • If an external input contains an input event, find an executable transition from the current state conditioned on this event.
       • If it is an immediate transition, change the state and execute the state action.
       • If it is a delayed transition, set a timer for this transition.
     • If an external input contains a termination command, set the termination request to TRUE.

Automaton examples

Automaton TOF5s

• Name: TOF5s

• Comment: Timer to off, jednoduchá verze.

• Inputs: in

• Outputs: out

• Variables: int timeout = 5000

• States and Actions:

  • IDLE: { output("out", 0) }
  • ACTIVE: { output("out", 1) }
  • TIMING: { }

• Transitions:

  • IDLE → ACTIVE: in [ atoi(valueof("in")) == 1 ]
  • ACTIVE → TIMING: in [ atoi(valueof("in")) == 0 ]
  • TIMING → ACTIVE: in [ atoi(valueof("in")) == 1 ]
  • TIMING → IDLE: @ timeout

• Note: The output() function, which generates an output event, is assumed to convert any data type to a string automatically.

• Note: A transition condition generally consists of three parts, each of which may be omitted. The general format used here is: input_event_name [ bool_expr_in_C_C++ ] @ delay_in_ms

Automat TOF

• Name: TOF

• Comment: Timer to off, umí nastavit timeout a na požádání sdělit zbývající čas timeru.

• Inputs: in, set_to, req_rt

• Outputs: out, rt

• Variables: int timeout = 5000

• States and Actions:

  • IDLE : { if {defined("set_to")} { timeout = atoi(valueof("set_to"))}; output("out", 0); output("rt", 0); }
  • ACTIVE: { if {defined("set_to")} { timeout = atoi(valueof("set_to"))}; output("out", 1); output("rt", timeout); }
  • TIMING: { if {defined("set_to")} { timeout = atoi(valueof("set_to"))}; output("rt", timeout - elapsed() ); }

• Transitions:

  • IDLE → ACTIVE: in [ atoi(valueof("in")) == 1 ]
  • ACTIVE → TIMING: in [ atoi(valueof("in")) == 0 ]
  • TIMING → ACTIVE: in [ atoi(valueof("in")) == 1 ]
  • TIMING → IDLE: @ timeout
  • IDLE → IDLE: set_to
  • ACTIVE → ACTIVE: set_to
  • TIMING → TIMING: set_to
  • IDLE → IDLE: req_rt
  • ACTIVE → ACTIVE: req_rt
  • TIMING → TIMING: req_rt

• Note: elapsed() returns the duration of the current state. If a transition does not change the state, the activation time is not reset.

Possible expansion for a team of four

• Work with a set of automata and let them communicate appropriately, e.g. via MQTT.
• The task can be generalized for an interpreted Petri net (similar to SFC, Grafcet) - this is recommended to consult.
• Use automata at the atomic level of a hierarchical block diagram along the lines of DEVS (Ziegler). This is recommended for consultation.

If you are interested in the project assignment

• Contact doc. Janoušek about the possibility of addressing a similar or related topic within BT.

General guidelines for project implementation

• The brief defines the essential features of the application that must be met. The solution teams are expected to complete the details.
• Follow the design process to make the resulting program easy to use. The evaluation will be whether it meets the above requirements and HOW it meets them.
• The design must separate the actual application model from the GUI (design an appropriate interface).
• Document the program design in source code format for doxygen.
• Use appropriate design patterns (Design Patterns) - see literature.
• For creating menus, dialogs, and other graphical user interface (GUI) components, use the Qt toolkit, at least version 5.5 (installed in classrooms and on the merlin server in the /usr/local/share/Qt-5.5.1/ directory). If you use a version newer/older than the one on the classrooms for development, we expect you to ensure backward/forward compatibility of your programs. (In case of problems, expect to demonstrate the application's translation/compilation/running on your laptop. This is not recommended.)
• Since the toolkits are portable to multiple platforms, your programs should work at least on Linux and on Windows. (Not only Java allows writing portable applications.) It doesn't matter which platform you develop your applications on; pay attention to the rules for writing portable programs. (Testing on Linux = merlin server, but the Makefile must not depend on a specific directory with a local toolkit installation.)
• You can use interactive editors/generators to create GUI dialogs and menus.
• Use C++17. (Boost better not be used. If you use some libraries from Boost, pack the used files and check if they fit the maximum size of the archive you uploaded. There is a tool BCP for selecting a subset of Boost).
• Programs will be created by entering the make command in the directory with the unpacked project sources (Warning - it will be automatically compiled). You must create a Makefile file, which must not contain absolute file paths.
• Name the resulting program appropriately. For testing purposes, everything can be run using make run.
• The project will include the program documentation created by Doxygen (set the configuration file to HTML output with the inclusion of the source texts: SOURCE_BROWSER = YES). The documentation will be generated automatically (= not packed into an archive) when you type make doxygen and will be stored in the doc subdirectory.
• The project will also include a conceptual design in pdf, containing at least a class diagram without unnecessary implementation details, or other UML diagrams documenting the design. The implementation is expected to be consistent with the conceptual design.

Submission notes

• The deadline for submission is indicated in the IS.
• Solutions packaged in .zip (or .tar.gz) format are to be submitted only by the team leader to the IS before the deadline. (No one will write that they didn't submit because *** and mail it.) The name of the submitted file must be in the form:

xname01-xname02.zip

or

xname01-xname02-xname03.zip

• xname01 is the leader's name (the one who submitted the project), xname02 or xname03 is the second or third member of the team (they do not submit anything).
• NOTE: The archive size must match what IS will allow. Therefore, checking the commit size early on is better to avoid last-minute problems.
• The committed archive contains at least the following directory structure:

./src/       # Source texts
./examples/  # Examples for testing
./doc/       # Documentation (generated)
./README.txt # Basic information
./Makefile   # Build and run

• Do not commit anything that can be created with make (executables or documentation that can be generated using make doxygen).
  • Note: The make clean command will delete all translation products, make pack will create an archive for committing - make sure it contains everything needed by unpacking it in an empty directory and compiling/running it.
• All source files must contain a comment at the beginning with the names of the module's authors, a description of the module contents, etc. The comments should also show which parts were written manually and which were generated automatically.
• If a module is based on borrowed code (e.g., from a tutorial or a publicly available open-source project), this must be explicitly specified in the module header and also mentioned in the README.
• The documentation (README) must specify which functionality has been implemented completely, which has some limitations, and which not at all (so that the evaluator does not unnecessarily try to make something work that is known in advance to be broken). Discrepancies between documentation and reality will be subject to a point penalty.

Notes for the project defense

• The project has to be demonstrated and defended. You have to register for the defense in IS.

Evaluation notes

• The project is graded on a 0-100 percent/points scale.
• After grading, points may be recalculated for individual team members as suggested by the team leader and coded into the name of the submitted file (the format of the name is then:

xname01-xname02-AA-BB.zip

• The sum of AA+BB=100, NOTE: for an even split of AA=BB=50%, there is no need to specify -50-50, which is the preferred option).
• The evaluation includes the quality of the OO design, the quality of the C++ implementation, adherence to the writing style of the program (indentation, quality of comments, appropriate identifiers), and most importantly, the program's functionality. If essential comments (especially authors' names) are missing in the source texts, the project will be rated 0p.
• WARNING:
  • Unless you translate with make = 0p or demonstrate on your laptop and explain where the problem was,
  • if there are no comments with the authors' names = 0p.
  • Completely inappropriately formatted and illegible code = 0p.
  • Plagiarism etc = 0p + visit to the disciplinary committee