Finite State Machine (FSM)

A mérés összehasonlítás, a mérőműszer a mérési eredményt egy etalonnal hasonlítja össze. Ezt teszi a mérőkészlet is a MONITOR és EMULATOR mérési módokban is, ahol a mérési eredmény egy bonyolult jelzésszekvencia, melyet össze kell hasonlítani egy "etalon" szabályrendszerrel, protokollal. Ráadásul az "etalon" szabályrendszer is változó, hiszen egy távközlési protokollnak számos nemzeti változata létezik. Ez azt a követelményt támasztja a mérőkészülékkel szemben, hogy az összehasonlítás alapját képező szabályrendszer a felhasználó által szerkeszthető legyen.

Az összehasonlításhoz tehát protokollokat kell specifikálni a mérőkészletben.

Measuring is comparation, measuring tool compares the measuring result with an etalon. Measuring set does the same in measuring modes MONITOR and EMULATOR, where the measuring result is a difficult signalling sequence, which must be compared with an "etalon" rule system, or protocol. Moreover, the "etalon" rule system is variable, too, because there are several national variations of a telecommunication protocol. It has a requirement towards the measuring tool, that the rule system, which is the basement of the comparison, must be editable by the user.

So we have to specify protocols in the measuring set for the comparison.

+++ It is does not belong to the equipment's handbook. There are numerous formats of specifications of telecommunication protocols: Finite State Machine (FSM), graph models, description languages (Estelle, SDL), Message Sequence Chart.+++

Protocol editor realized in the measuring equipment is based on the state table description of the finite state machines (STATE_TABLE), namely we give the protocol with a table (a state table). 


           +-------+------------+-------------...+------------+
           |       | State1     | State2         | StateN     |
           +-------+------------+-------------...+------------+
           |       | Action-    |                |            |
           |       | block:     |                |            |
           |       | Condition11| Condition12    | Condition1N|
           |Event1 | Action11   | Action12       | Action1N   |
           |       | NewState11 | NewState12     | NewState1N |
           +-------+------------+-------------...+------------+
           |       | Condition21| Condition22    | Condition2N|
           |Event2 | Action21   | Action22       | Action2N   |
           |       | NewState21 | NewState22     | NewState2N |
           +-------+------------+-------------...+------------+
           .       .            .                .            .
           .       .            .                .            .
           |       | ConditionM1| ConditionM2    | ConditionMN|
           |EventM | ActionM1   | ActionM2       | ActionMN   |
           |       | NewStateM1 | NewStateM2     | NewStateMN |
           +-------+------------+-------------...+------------+
The essence of this desription mode, that the signalling process can be described with a determined state in every time. State create the columns of the table, and rows are created by the events, which can make the automata to change its state. We can write to the table, what kind of actions (processes) we will make in case of the lack or fruition of certain conditions, and what will be the new state of the automata. These processes create an action block of the automata, its flow diagram can be seen below - as a general rule: 
                            +------------+
                            |   STATE    |
                            +------+-----+
                                   |------->-------+----------->--------+
                                   |               |                    |
                            +------+-----+  +------+-----+  ...  +------+-----+
                            >   EVENT    |  >   EVENT1   |       >   EVENTn   |
                            +------+-----+  +------+-----+  ...  +------+-----+
                                   |               |                    |
                                   |-------<-------+-----------<--------+
                                   |                          -
                     TRUE   +------+-----+   FALSE            |
                    +-------< CONDITION-i>--------+           |
                    |       +------------+        |           |
                    |                             |           |
             +------+-----+                +------+-----+  action
             |   ACTION_i >                | ACTION_i+1 >  block
             +------+-----+                +------+-----+     |
                    |                             |           |
                    +- - - CHAIN (+2)- - - - - - -+           |
                    |                             |
               CHAIN (+3)                         |           |
             +------+-----+                +------+-----+     |
             | ACTION_i+3 >                | ACTION_i+2 >     |
             +------+-----+                +------+-----+     |
                    |                             |           |
             +------+-----+                +------+-----+     |
             |NEW_STATE   |                |NEW_STATE   |     |
             +------------+                +------------+     |
                                                              -
The incoming events are predominantly SIGNALs arriving form the measureable object, and actions are predominantly response signals for them.

In the realized table we should mark every state, event, condition, action signal with an identifier. Event, condition, and action identifiers cover processes built in by the manufacturer, and parameterable by the user. Signal identifiers cover physical parameters editable by the user (frequency, level, code, duration).