## 3 Concept of an Automaton for Data Validation
### Algorithms
#### 3.3.1 Handle Incoming Messages and Detect Overtakings  
The most important task is to handle incoming data from the IoT environment. Algorithm 1 provides an overview of the steps to perform. For incoming information, we first have to identify the data set it belongs to. If a corresponding data set does not yet exist and the identifier is thus unknown, we proceed as follows: Depending on the message type, we enter the associated initial state. The new identifier is then assigned with a rank and a process-specific timer is started.  
```
0:\(A\gets new\ ValidationAutomaton()\)
1:procedurehandleMessage(m)\(\triangleright\) For each incoming message
2:\(id\gets m.getId()\)
3:if\(\
eg A.find(id)\)then\(\triangleright\) Start of a new manufacturing process
4:\(q_{new}\leftarrow\delta(Null,m)\)\(\triangleright\) Enter initial state
5:\(A.set(q_{new},id)\)
6:\(A.startTime(id,m)\)\(\triangleright\) Process-specific timer per product
7:\(A.determineRank(q_{new})\)\(\triangleright\) Compute rank considering time of arrival
8:else
9:\(q\gets A.getCurrentState(id)\)
10:\(r\gets q.getRank(id)\)
11:\(A.clearTime(id)\)
12:if\(r>1\)then\(\triangleright\) Overtake detected
13:\(A.transferToCat4(\{\{rank(all)<r\}\sqcap[consistentState(id)]\})\)
14:\(report(\{\{\{rank(all)<r\}\sqcap[-consistentState(id)]\}\})\)
15:endif
16:\(q_{new}\leftarrow\delta(q,m)\)
17:\(A.set(q_{new},id)\)
18:if\(q_{new}\) is \(con\)then\(\triangleright\) Reached final consistent state
19:\(validateDataSet(M)\)\(\triangleright\) M contains all messages related to the current id
20:elseif\(q_{new}\) is \(valid\)then
21:\(A.startTime(id,m)\)\(\triangleright\) Start timer considering next process
22:\(A.determineRank(q_{new})\)\(\triangleright\) Compute new rank
23:else
24:\(report(id)\)\(\triangleright\) When entering invalid state, report inconsistency
25:endif
26:endif
27:endprocedure
```  
**Algorithm 1** Process incoming messages and detect overtakings  
Otherwise, we clear the active timer to prevent an expiring timer from triggering unwanted actions. Afterwards, we check the rank of our identified set. If \(rank>1\), we detect an overtake, because the state contains older data sets. An overtake is not problematic for the current data set, but is for older ones. If the overtake happens in a _potentially consistent state_, we can transfer all older elements into the _cat4_ state. This is possible because we assume that the identifier has been removed from the IoT scenario. An overtake in a usual state means that older data sets are not currently consistent. We conclude that information was lost. The affected data sets are classified as inconsistent according to the _missing message_ criterion.  
Thereafter, we can switch the state and proceed. First, the algorithm checks in what type of state the identifier is. In the _cat4_ state, the entire data set is checked for category4 inconsistencies. In a valid state, a new process-dependent timer is started and the new rank of the identifier is determined. As we already mentioned in Section 3.1, each process has its own time restrictions. The rank is derived from the timestamp of a message. The recalculation of the rank is necessary in order to further identify overtaking items.  
If we are in an inconsistent state, there is no longer the possibility to receive an anomalous-free data set. As a result, we can report an identified inconsistency directly.