The formal methodology, which focuses on the safety and stability of a system from the aspect of logical analyses, mainly refers to the formal specification and the formal verification. It abstracts functions and processes of a system into logical expressions and verifies whether system behaviors conflicts predefined rules.
Although simulation allows one to experiment the behavior of a system in a specific operational condition and quickly detect some errors, the result obtained from the simulation may be biased beyond test scenarios.
Compared with the simulation, due to the analyses of all possibilities of evolution of a system’s behavior, the formal specification and verification allows one to obtain more conclusive results at the expense of time-consuming analyses. As a result, it is advantageous to use simulation complementarily to formal verification, that is, simulation is responsible for finding more simply detectable bugs and then the formal verification tries to look for undetected errors by simulation.
4.1. Analyses Techniques of the Formal Methodology
Since the UEMS is a real-time system, the analyses of the UEMS need to take time evolution into account. Consequently, timed automaton is adopted in this paper to construct abstract models of UEMS behaviors.
A timed automaton is essentially a finite automaton extended by time restrictions. As a formal analyses technique, the timed automaton has rigorous definition. In general, a timed automaton is defined as a tuple , where
- (a)
is a finite set of states,
- (b)
is the initial state,
- (c)
is a finite set of clocks,
- (d)
is a finite set of actions,
- (e)
is a finite set of variables,
- (f)
is a finite set of transitions. A transition is a tuple indicating that, starting by the state , the automaton executes the action , if the constraint is satisfied; clocks of are reset, variables of are updated and the new state is .
The constraint
is defined as Equation (2). Incidentally, Equation (2) applies Backus-Naur Form (BNF).
where ‘:=’ means ‘defined as’ and ‘|’ means ‘or’. Equation (2) implies that the constraint
is a logic expression of time (
g_clock) or a logic expression of data (
g_data) or a combination of the above two. The logical expression indicates a variable (
clk or
ex) is less than, no more than, equivalent to, no less than or more than a preset value. A variable of data (
ex) can be further defined as a constant or the elementary arithmetic between those variables. Several examples of the constraint
g are ‘true’, ‘
clk < 5′ and ‘
clk > 10 and
ex < 5′.
To analyze communication requirements, timed computation tree logic (TCTL) is applied in this paper, which is an extension of computation tree logic (CTL) logic that can express real-time properties.
In addition, another benefit of applying time automata is that timed automata are the input formalism of the UPPAAL model-checker [
21], which is a dedicated software for the formal specification and verification of real-time systems.
4.2. Tool
As mentioned above, UPPAAL model-checker is a simulator available to perform the formal specification and verification of the real-time system. It provides timed finite automata as the timed input language, which is appropriate for the proposed time automata-based formal specification. In addition, UPPAAL achieves the formal specification and verification in a unique environment, without the need for translation between formalism from the simulation to the formal verification environments. Thus, possible mistakes in the analyses that may occur during the translation can be avoided. Consequently, UPPAAL model-checker is selected in this paper as the simulator for the formal specification and verification.
To execute the formal verification, UPPAAL uses a simplified version of TCTL and applies BNF to describe query language
. The query language consists of path formulae and state formulae. State formulae describe individual states, whereas path formulae quantify overpaths or traces of the model. The formal expression of
is:
where
f is the state formula that is a logical expression describing the nature of the system to be verified while
a can be a clock variable, an integer variable, or a location in the timed automaton. Characters
A and
E are used to quantify the path, where the path is a state transition sequence of the system.
A indicates that for a given property, all paths in the model are satisfied.
E indicates that for a given property, at least one path in the model can be satisfied. <> and [] are used to quantify the status on the path. [] indicates that all states on the desired path can satisfy given properties while <> indicates that at least one state on the desired path can satisfy given properties.
Figure 3 illustrates the path formula.
Path formulae can be classified into reachability, safety, and liveness (As illustrated in
Table 2). Reachability properties ask whether for a given
, there exists a path starting at the initial state, such that
is eventually satisfied along that path. Reachability properties do not by themselves guarantee the correctness of the system, but they validate the basic behavior of the model. Safety properties ask whether a bad result will never happen, or an awaited result is invariantly true. Liveness properties are of the form “an awaited result will eventually happen”. With this type of properties, response conditions can be verified as follows “whenever ϕ is satisfied, eventually
will be satisfied”.
In addition, UPPAAL supports urgent locations (marked as ‘u’) and committed locations (marked as ‘c’). In the urgent locations, time may not progress, but interleavings with normal states are allowed. A committed location is more restrictive: delay is not allowed, and the committed location must be left in the successor state. The synchronization mechanism in UPPAAL is a hand-shaking synchronization: two processes take a transition at the same time in the synchronization channel ch, one will have a ch! and the other ch?
For direct use in the UPPAAL model-checker, the formal specification and verification of the behaviors can be executed according to the following steps:
- (1)
Modeling timed automata of the intended behavior
- (2)
Describing the intended behavior in natural language.
- (3)
Formalizing the informal behavior by using a subset of TCTL.
- (4)
Translating the behavior properties into the input language permitted by UPPAAL and executing the formal verification.
4.3. The Formal Specification and Verification of the UEMS
(1) Connection behavior. In the MQTTSN-based UEMS, an intelligent terminal is regarded as a client and needs to setup a connection to a gateway before it can exchange information with that gateway. The procedure of setting up a connection with a gateway is illustrated in
Figure 3, in which it is assumed that the client requests the gateway to prompt for the transfer of Will topic and Will message. This request is indicated by setting the Will flag of the CONNECT message. The terminal then sends these two pieces of information to the gateway upon receiving the corresponding request messages WILLTOPICREQ and WILLMSGREQ. The procedure is terminated with the ACK message of register ‘U_’ topic sent by the gateway.
Table 3 introduces the meaning of topics in
Figure 4.
It should be noted that the upper half part of
Figure 4 is the standard connection procedure of MQTT-SN while the lower half part, which includes topic subscription of ‘M’, ‘C’ and ‘U’ and topic registration of ‘M_’, ‘C_’ and ‘U_’, is our originality. Those basic topics are based on the major behaviors of intelligent terminals in the UEMS, which have been mentioned in
Section 3.3. The proposed basic topics could help topic-oriented MQTT-SN avoid hidden troubles such as topic explosion.
The formal specification of connection behavior based on timed automata model is depicted as
Figure 5 and
Figure 6 (where the subscriber is instantiated as Gw and the publisher is instantiated as Sck).
Figure 5 and
Figure 6 are formal specifications of
Figure 4, i.e., the connection behavior of intelligent terminals. After sending connecting request, a Sck would successively subscribe the ‘M’ topic, subscribe the ‘C’ topic, subscribe the ‘U’ topic, register the ‘M_’ topic, register the ‘C_’ topic, and register the ‘U_’ topic to a Gw. Additionally, some other details are added into
Figure 5 and
Figure 6 to make the behavior more realistic. For example, the ping mechanism is introduced. When the Sck is active, it would send a ‘Ping_Req’ message within each predefined time period, which the Gw acknowledges with a ‘Ping_Resp’ message immediately. If the Sck does not receive a ‘Ping_Resp’ message within a predefined latency time, it will go into lost state and try to reconnect the Gw.
The formal verifications of the time automata are illustrated in
Table 4.
(2) Measure behavior. Monitoring various signals of a physical device is imperative in CPS. The more timely and frequent the data publishing is, the more precise and synchronized the virtual mirror of physical processing established in the computing system is.
The normal approach is to sample the signals equidistant in time which is called Riemann sampling. However, the communication network of UEMS is usually the resource limited and unstable WSNs. The gateway, which is the message transfer station between the cloud server and the intelligent terminals, bears considerable information throughput. It is crystal clear that an increase of the number of nodes and communication traffic will inevitably heavier the burden of the network and further cause the instability of the network.
To improve data exchange efficiency, a data sampling and publishing mechanism based on Lebesgue sampling [
22], which samples the system when the output has changed with a specified amount, is adopted in this paper.
The hybrid model of the proposed data exchange mechanism is illustrated in
Figure 7.
Where
is current time and
is the time of last data publishing.
denotes a vector of monitoring data types of device at time
:
where
denotes the value of the
ith monitoring data types at time
.
And
is the vector of the predefined threshold of the monitoring data type:
where
is the predefined threshold of the monitoring data type
.
For example, if the power, current and voltage of an electric heater are the three monitoring data types, could be defined as , which implies that is power, is current and is voltage.
The hybrid model has two states, ‘Data Sampling’ and ‘Data Publishing’. ‘Data Sampling’ state only samples concerned data and does not publish them while ‘Data Publishing’ state delivers the sampled data to certain receiver such as gateway. These two states can be transformed into each other when certain condition is satisfied:
- (1)
If current state is ‘Data Sampling’, the state will transform into ‘Data Publishing’ when the deviation between current sampled value and the sampled value of last ‘Data Publishing’ of any monitoring data type is greater than the predefined threshold, that is, . If the condition is not satisfied, ‘Data Sampling’ state will be maintained.
- (2)
If current state is ‘Data Publishing’, the state will transform into ‘Data Sampling’ when the deviations between current sampled value and the sampled value of last ‘Data Publishing’ of all monitoring data types are no more than the predefined threshold, that is, . If the condition is not satisfied, ‘Data Publishing’ state will be maintained. Additionally, once the state is transformed into ‘Data Publishing’, will be updated to be .
Figure 8 illustrates the formal specification of the measure behavior based on the timed automata model (where the publisher is instantiated as Sck and the subscriber is instantiated as Gw). The Sck applies the above-mentioned data exchange mechanism to decide whether the sampled data should be published. Some other details are also introduced to make the behavior more realistic. For example, the Sck would resend the sampled data until it receives a ‘PubAck_M_’ message in the condition of QoS > 0. In addition, each measurement message has a time mark. When the Gw receives a measurement message, it will check the message’s time mark with the last measurement message of the same Sck. If the former is less than the later, the message will be judged as invalid data.
The formal verifications of the time automata are illustrated in
Table 5.
(3) Control behavior. The control messages have high priority and real-time requirements. The QoS of the message is always set 1 or 2, which ensures that the message arrives at the receiver at least one time. In addition, the receiver must respond with an ACK message. The formal specifications of the control behavior based on timed automata model are depicted as
Figure 9 (where the publisher is instantiated as Gw and the subscriber is instantiated as Sck). Similar to measure behavior, the Gw would resend the control command until it receives a ‘PubAck_C’ message in the condition of QoS > 0. In the condition of QoS > 0, the response message of Sck should explicitly indicate the execution result of the control so that the Gw could know whether the control is successful.
The formal verifications of the time automata are illustrated in
Table 6.
(4) Upgrade behavior. To further support scalability of intelligent terminals, remote firmware upgrade is implemented to expand and update the functions of modules or devices.
Since the UEMS in this paper is based on ZigBee wireless network, which cannot transmit all upgrade data at one delivery, the upgrade file needs to be divided into block data of appropriate length to transmit. In addition, a greedy algorithm is adopted to generate the upgrade file according to the differentiation between the old firmware and the targeted firmware. The process of the remote firmware upgrade is depicted in
Figure 10.
The formal specifications of upgrade behavior based on timed automata model are depicted as
Figure 11 (where the publisher is instantiated as Gw and the subscriber is instantiated as Sck). As illustrated in
Figure 10, to generate the upgrade file, the Gw would firstly request the software version of the Sck. After the Sck returns the version information and is ready for upgrade, the Gw starts to transmit segmented upgrade file. After the transmission of upgrade file is completed, the Gw would deliver a check code of the upgrade file to the Sck. The Sck would then check the received check code with the local check code. If the two check codes are equivalent, the upgrade of the Sck is successful.
The formal verifications of the time automata are illustrated in
Table 7.