Verification Results

The type of requirements to be verified are those listed in Section 4.2. For the purpose of showing the applicability of the methodology, the following requirements are selected:

1. Maximum Overshoot % (OS) ≤ 13%.

2. Settling Time (ST) ≤ 40 seconds.

3. Rise Time (RT) ≤ 15 seconds.

4. Steady state error % (SSE) ≤ 1%.

The verification is performed by verifying properties on the model. Requirements are then expressed in the query language of the model checker in the form of properties. The verification is conducted by querying the model in a push-button fashion because the user simply has to click on the verify button with a property as the input to the model checker. The types of properties to be used for the verification are either a reachability or a liveness property (Table 4.1). The reachability property is used to generate a witness trace in case requirements are met and the liveness property to generate counter example trace in case requirements are not met.

E<> Observer.End and Controller_OA.Settled and Plant_OA.Settled and Plant_OA.OS ≤ 13% and Plant_OA.ST ≤ 40 (seconds) and Plant_OA.RT ≤ 15 (seconds) and Plant_OA.SSE ≤ 1% and

Controller_UA.Settled and Plant_UA.Settled and Plant_UA.OS ≤ 13% and Plant_UA.ST ≤ 40 (seconds) and

Equation 4.8 shows the verification of requirements 1-4 using a reachability query in order to get a witness trace if requirements are met. The query can be read as: there exists a path where the observer has reached a final state, both controllers have reached a settled state, both plants have reached a settled state, and in both plants overshoot is less than or equal to the specification, settling time is less than or equal to the specification, rise time is less than or equal to the specification, and steady state error is less than or equal to the specification.

The result after running the query in Equation 4.8 is a Fail. For this reason the model checker does not return a trace. In order to get more information from the model checker, and not just a Pass/Fail answer, the path quantifier is changed from E to A. This changes the query into a liveness property, which returns a counter example trace when the property is not met. After modifying the query and re-running the verification a trace is returned showing why the verification fails: the over approximation fails to meet the overshoot requirement. Table 4.2 shows the results for the abstraction after running the verification, these results are cross-checked by running the simulation in the high fidelity simulator. The requirements values are shown for both the over approximation and the under approximation. Figure 4.16 shows the closed loop behaviour of the system abstraction. Highlighted in red is the overshoot area where the over approximation fails to meet the requirement.

As a sanity check and to corroborate the model checker is performing calculations correctly, the overshoot requirement is changed from 13% to 16% in the model. Given the information in Table 4.2 the expected result is Pass. After modifying the overshoot threshold in the model, the query is re-run and the result is a Pass. The use of the model checker and the generated traces for both the Pass and Fail scenarios will become fundamental in Chapters 5 and 6. In Chapter 5 they will be used to tune the controller and in Chapter 6 to find a suitable combination of controller tunings to generate the control schedule.

Table 4.2 Requirements verification results for the system abstraction.

Plant Requirement

Overshoot (%) Settling Time (sec) Rise Time (sec)

Steady State Error (%) Under Approximation 12.2 34 6 0.1 Over Approximation 15.74 35.5 6 0.12

If the abstraction meets high level requirements then the original system meets high level requirements. This is derived from the fact that using both over-approximation and the under-approximationin the model checker makes possible to infer properties of the original

Fig. 4.16 Closed loop response of the system abstraction. Both over and under approximation responses are plotted. Highlighted in red is the area where the over approximation fails to meet the overshoot requirement.

system. Given the nature of the type of requirements to be checked, it can be reasoned that for some requirements it is only required that either the over or under approximation meets the requirement. For example, maximum overshoot is directly linked to the system gain, the over-approximation has a higher gain than the original system, therefore if the over-approximationmeets this requirement the original system then is also guaranteed to meet the requirement. However, the proposed methodology in this thesis verifies that both approximations meet requirements.

The outcome when running the same scenario for the original system (given by Equation 4.2) is shown in Table 4.3. The original model also fails to meet the overshoot requirement. Figure 4.17 shows the closed loop behaviour of the original system. Highlighted in red is the overshoot area where the system fails to meet the requirement.

Figure 4.18 shows a comparison between the system abstraction and the original system closed loop response. The original system response is scaled using the selected value of

Table 4.3 Requirements verification results for the original system.

Requirement

Overshoot (%) Settling Time (sec) Rise Time (sec)

Steady State Error (%)

13.93 35 6 0.05

Fig. 4.17 Closed loop response of the original system. Highlighted in red is the area where the system fails to meet the overshoot requirement.

K_S= 10, 000. The scaled system response is bounded by the system abstraction (over and under approximations).