FiniteStateMachine

An example that is a structurally simple implementation of a Deterministic Finite State Machine. The example uses a project with a single main module.

For this example, the state transition table is assumed to exist in an Oracle, Ingres, or another database. The fsmDb.sql file in the data subdirectory contains the SQL necessary to set up the Oracle example. The SQL table has the following form:

create table dfsm_state_transitions (
 from_state             varchar2(30) not null,
 to_state               varchar2(30) not null,
 event                  varchar2(30) not null,
 action                 varchar2(30) not null)

The database setup is further described in the readme.txt file in the data subdirectory.

The data describes the possible paths of RFID-enabled pallets through doors in a three-room building. The incoming data has no timestamp. Instead of using a timestamp column from the data source, the input adapter specifies a Rate to regulate the input rate and uses the current time to assign timestamps to incoming rows.

The StateEventStream in this example receives its data from a .csv file, which contains an ID column, to differentiate the multiple finite state machine instantiations, as well as a FromState and an Event column. The FromState and Event data is used in conjunction with a CCL database subquery, which obtains the to_state and action values from the relational database. The retrieved information is passed on to the CurrentStateStream stream.

The SQL queries used in this example notes the absence of an entry in the state transition table by the union with a not-exists subquery. This is used for subsequent filtering and error handling. If there is no entry in the state transition table, the row is fed to the ErrorAction stream.

Valid rows are passed into a named window called States that keeps the last two rows for each finite state machine instantiation.

The TransitionStatus stream receives both valid and invalid state transition data from States. The transition is considered valid if the previous state value of the current row is the same as the previous row's state value (or if the previous row does not exist, because only the first row has been processed). Otherwise data has been dropped or extraneously added and the entire process is suspect. The States window maintains a view on the last two rows to identify such loss of data.

The TransitionStatus.IsValid field is set to either TRUE or FALSE when the data is validated and the row is published to the StandardAction or ErrorAction stream, depending on the value in the TransitionStatus stream.


Created March 8, 2010. Send feedback on this help topic to Sybase Technical Publications: pubs@sybase.com