If we want to use properties with finite automata then arises the question, how one can handle properties with finte automata. Strictly speaking there is no place for properties in finite automata. But seen from the point of property checking in the case of execution graphs it is clear that the main goal for the usage of properties is given in the goal to have a tool to enable an automatic proof checker to investigate the possible executions of an automaton with regard to certain specified criteria whether these are occuring in an execution or not. From this point of view we can use the output of a finite automaton as a kind of a protocol showing us all important informations. Thus we can assume that the output function prints the strings encoding the properties, eventually enhanced with additional informations like the actual state. For this we define the Finite Protocol Automaton as follows:

Def.: The automaton is a Finite Protocol Automaton iff we have the following structure:

with

- := Finite set of states
- := Set of initial states
- := Set of final states
- := Finite set of symbols forming the input alphabet
- := Finite set of symbols forming the output alphabet
- := Finite set of properties as a set of words of some language
- l : := mapping the states into finite sets of properties
- l : := mapping the states into words over the output alphabet
- := Relating actual state and input with follow up state and a word encoding the follow up state as well as the set of properties related to the follow up state.

Armed with this definition we can translate the graph with properties and as well the corresponding execution graph as follows:

- =
- = .
- =
- = .
- 2= .
- = .
- with =

The definitions for execution, stateSequence, and inputword can be taken as before.

Corresponding to the execution sequence: = we can then construct a protocol based on the output of the automaton as follows (assuming the convention, that the individual properties are printed separated by a comma and one output is enclosed in brackets):

- (1,start)
- (1,start)
- (1,start)
- (2,K=A)
- (3,K=B)
- (1,start)
- (2,K=A)
- (3,K=B)
- (4,K=A)

Because the automaton always will start in state with property we can interpolate the first element in the protocol and from this we can deduce the complete protocol. The complete protocol reports not the next states with their properties but the actual states with their properties:

- (1,start)
- (1,start)
- (1,start)
- (1,start)
- (2,K=A)
- (3,K=B)
- (1,start)
- (2,K=A)
- (3,K=B)
- (4,K=A)

The complete protocol corresponds directly to a possible path in the corresponding execution graph. if one interpretes the word encoding the actual state in the complete protocol then one could specify a CTL-expression like EF asking whether there is an execution path with a state where we have the properties . Because a state with such properties must be a final state we can with such a CTL-specification enable an automatic checkler to generate a proof that there is such a path or that there is none.

Gerd Doeben-Henisch 2010-03-03