1. Introduction
Mechatronic [
1] (and, more generally, cyber-physical) systems are constantly growing in complexity and widening their fields of application, and require higher and higher levels of dependability and performance. Accordingly, system validation by simulation and testing should be complemented with rigorous analysis and verification methods, leading to a
formal-verification-in-the-loop [
2] development process.
This concept is the basis of the development process presented in this work. The process assumes a high-level specification, typically in natural language or some semi-formal language, from which a set of submodels is derived. The submodels may represent different structural parts (e.g., power plant and gear train of a vehicle) or different aspects (e.g., electromagnetic and mechanical physics of a motor) of the system. Each submodel can be developed by different domain experts, who use modeling languages and tools fit for each domain. Co-simulation (as opposed to traditional, monolithic simulation) is the co-ordinated simulation of heterogeneous submodels that have been developed independently.
Modeling languages are usually oriented to simulation. They may be based on different conceptual frameworks, such as e.g., signal flows for Simulink and equations for Modelica and their supporting environments provide a simulator. However, their support for verification is limited, if any. In the proposed development process, also verifiable models are built. A model is verifiable if it is written in a language oriented to verification and implemented in an environment providing tools for automatic or semiautomatic verification. In this work, we propose to use an abstract mathematical specification as the base of both the simulation-oriented and the verifiable model.
Not all submodels need be formally verified since many aspects of a system are well known and can be designed with well-proven and reliable techniques. Formal verification is needed for the more innovative components or aspects of a system, in particular for control systems. In this case, co-simulation is particularly convenient.
In this work, we present an application of formal verification, co-simulation and
design-space exploration (DSE), to a case study of practical interest, a servo drive for permanent magnet synchronous motors. Servo drives are cyber-physical (more specifically, mechatronic) systems since they combine physical and algorithmic components. This case study has been chosen because servo drives are systems of particular interest as they are applied in all fields of industrial automation, industrial robotics, and automotive applications. However, the contribution of this work is not a new control algorithm for brushless motors, but rather to propose a control algorithm verification procedure in the context of mechatronic systems. The algorithm used in this case study had been previously designed by two of the authors [
3] and validated with the classic
software-in-the-loop (SIL) procedure.
This paper aims at showing how formal verification and co-simulation can be introduced in the design process to achieve more confidence in the system’s compliance with requirements and to assist the designer in choices that would otherwise be based on rules of thumb and trial-and-error procedures. Particular attention is paid to the tuning of parameters of the control algorithm, whose values, in a classic SIL approach, can be chosen only by making many simulations. In the approach exposed in this paper, formal methods are used to define acceptable ranges for those values, and co-simulation-based DSE is used to explore systematically the parameter space.
In the rest of this section a small collection of references to the vast literature on mechatronic [
1,
4,
5,
6] systems development is presented, grouped by their relevance to the main themes of this work, i.e., modeling and simulation, co-simulation, and formal approaches.
Concerning modeling and simulation, system models are typically built with block-based languages, which describe a system as an assembly of functional blocks, each representing a possibly complex mathematical operation, and interconnected by data flows. The blocks have a visual representation, but their semantics is defined in an underlying textual language. The models are then simulated by running test scenarios and successful runs reinforce confidence on the correctness of the design. However, exhaustive testing is not possible and high reliability of the system requires a high level of testing coverage.
The MATLAB/Simulink suite [
7,
8] is a prime example of an environment supporting block-based modeling. Among its large number of application-oriented toolboxes, the Stateflow toolbox, based on a state machine formalism, can be used to model hybrid systems, which are characterized by having a finite number of distinct modes of operation, and in each mode the system evolves according to time-continuous laws.
Several papers may be cited from the literature on simulation of mechatronic systems published in recent years. Dell’Amico and Krus [
9] use monolithic simulation and
hardware-in-the-loop (HIL) simulation to design an electrohydraulic power steering system. In the HIL simulation, both the controller and the vehicle-tire model are in software while the mechanical and hydraulic parts are assembled in a test rig comprising the steering wheel, the rack and pinion, pump and valves, and associated sensors and actuators.
An interface between Simulink and the finite elements toolkit Abaqus is presented by Orszulik and Gabbert [
10], oriented to the simulation of smart structures, i.e., solid bodies whose shape can be modified through a control stimulus, such as, e.g., an electric field. As a case study, an aluminum beam controlled by piezoelectric sensors and actuators is simulated with Abaqus, while the controller is simulated in Simulink, in order to study the vibrational behavior.
Isermann et al. [
11] discuss the role of HIL simulation in the development of engine-control systems and report on the simulation of a Diesel engine interacting with real injection pumps and real control units for engines and pumps.
Concerning co-simulation, an extensive survey has been recently published by Gomes et al. [
12], providing definitions of the fundamental concepts and the taxonomy of the literature based on the computational model adopted in the various works:
discrete events,
continuous time and
hybrid, i.e., a mix of the two.
Co-simulation of multibody dynamic systems in ADAMS [
13] and controllers in Simulink are used by Hadas et al. [
14] to analyze various types of industrial robots.
Use of the SysML language [
15] is discussed in a paper by Sadovykh et al. [
16], where a SysML model defines the high-level architecture of a heating, ventilation, and air conditioning system composed of various physical subsystems modeled in 20-sim and a controller modeled in VDM. The latter has a digital (event-driven) component that reacts to user inputs and temperature changes by switching between modes of operation (heating or cooling), and a continuous-time component that in each mode controls the temperature with a PID algorithm.
Foldager et al. [
17] present a case study on the development of a driverless lawn mower, describing the interplay between experiment and simulation to study physical parameters, design parameters, and operating conditions. First, two physical parameters have been determined by experiment, then co-simulation has been used to choose an optimal value for a design parameter of the controller, which has been validated by field testing. Finally, co-simulation has been used again to assess system behavior for different speeds. The plant has been simulated in 20-sim and the controller in VDM.
From the literature of formal approaches, we may cite Giese et al. [
18], who develop a formal extension to UML Statecharts and components enabling developers to model cyber-physical systems as hybrid automata [
19] and supporting the modular composition of subsystems.
Model checking with UPPAAL is used by Lindahl et al. [
20] to verify a gearbox controller, modeled as a network of timed automata, against requirements of different kinds, including performance and time bounds.
Cimatti et al. [
21] developed HyComp, an SMT-based tool for the verification of networks of hybrid automata. The tool can also synthesize design parameters [
22].
The KeYmaera X interactive theorem prover is introduced by Fulton et al. [
23]. In this environment, continuous-time behaviors are expressed in the language of
differential dynamic logic [
24].
Another theorem proving environment is the Prototype Verification System which, differently from KeYmaera, uses a general-purpose higher-order logic [
25]. This environment has been used in many application fields such as medical [
26,
27] and control systems [
28,
29], and it will be described more extensively in
Section 2.1.
Other interesting works, which exploit formal methods for verification, are listed below. In [
30], the authors propose a review of the state of the art in the field of automotive cyber-security, evaluating the best combinations of on-board HW simulation methods and formal verification methods to cover special cases. In [
31], the authors present a strategy to control the power distribution system to minimize electricity bills and meeting the comfort constraints of users. They use the UPPAAL environment for modeling and verification by model checking.
This work is organized as follows:
Section 2 provides background information on the theorem proving and co-simulation;
Section 3 introduces the methodology presented in this paper;
Section 4 reports the design of a controller for brushless motors as a case study, and the application of formal verification,
Section 5 contains co-simulation, and DSE results, and
Section 6 concludes the paper.
3. A Development Process Integrating Verification and Co-Simulation
In the development of complex, possibly safety-critical applications, it is desirable to exploit both simulation and formal verification. In this section, we present a development process that integrates co-simulation and verification by computer-assisted theorem proving. This section is the core of this paper’s contribution, as it defines the structure of the development process in its general form. An example of its application is shown in the next section, where the design of a control algorithm for a brushless motor is taken as a case study. Readers interested in the details and performance of the algorithm are referred to [
3].
The process, represented in
Figure 2, is based on three models of a mechatronic system (rectangular boxes), which are the inputs to the process activities (ovals). The models are the
mathematical,
logic, and
simulation model. The latter two models are the starting points of two activity flows,
simulation and
verification.
The mathematical model is a mathematical specification of the system, from which the two other models are derived. This model is composed of three parts: (i) the definition of the plant dynamics, (ii) the control algorithm, and (iii) the system requirements. Each part, in turn. may be decomposed into submodels, reflecting the system’s structure.
The simulation model is an executable specification of the plant dynamics and the control algorithm. This specification is usually built as a monolithic model using a block-based language such as Simulink, but co-simulation affords the convenience of using different languages for different submodels. This is particularly useful when a model is already available for one subsystem (e.g., the plant) and a model for another subsystem (e.g., the controller) is to be created anew.
The logic model is a translation of the mathematical model into a language suitable for verification. In the present work, the logic model has been expressed in the PVS higher-order logic language. In this language, a logic model can be structured into a set of theories, each corresponding to a different submodel of the mathematical model. The mathematical models of plant and control algorithm are translated directly into PVS axioms and definitions, while requirements become theorems to be proved against the theory.
The simulation flow uses the executable models of the plant and control parts to collect experimental results from the co-simulation activity. At this stage of development, the control part design is software design, so that its executable model is conveniently built with a software specification language, or directly in the implementation language, whereas the plant is built with physical modeling languages. Co-simulation is chosen as the simulation method to cater for the different formalisms.
The verification flow uses the logic model to prove if the requirements are satisfied. The
proof activity takes place as
interactive theorem proving, as anticipated in
Section 2.1: The theorem prover displays the
goal, i.e., the statement to be proved, and the user issues commands that simplify the goal or decompose it into subgoals. This is repeated until the initial goal is reduced to a set of subgoals simple enough to be proved automatically by the theorem prover, or else until no command can simplify some subgoal, in which case the theorem is not verified. The proof activity then results in a verdict of
verified or
not verified for each theorem. As a byproduct, verification may lead to the definition of constraints on design parameters, which are fed back to the mathematical model and propagated to the simulation and verification flows, as shown in
Figure 2.
The two workflows merge into the assessment activity, which consists of taking action in response to the results of proof and co-simulation. In case of negative results of either proof or simulation, the logic and simulation models are reviewed and compared with each other. Comparing logic and simulation models is useful since the two models, albeit derived from the same mathematical specification, are built on different conceptual frameworks, and either one can shed light on the other one’s issues. The two models are then compared with the mathematical model, to ensure that it has been correctly translated. In the following, we assume that the three models are coherent. As a result of the assessment activity, the mathematical model is updated and the updates are propagated to the two parallel flows.
In the case of negative simulation results, tests can be designed to isolate the parts of the specifications where problems lie, and the mathematical model can be changed accordingly.
Negative verification verdicts are caused by inconsistencies in the logical specification, such as false, incomplete, or contradictory assumptions or requirements. There is no mechanical procedure to pinpoint such inconsistencies, but the interactive theorem proving process usually guides the developer in the search for inconsistencies. Typically, a failed proof gets stuck in the attempt to prove a faulty statement, whose analysis reveals a conceptual problem in the specification.
Depending on the project context, different parts of the specification can be changed. If the requirements and plant are fixed, clearly only the control part can be acted upon. Otherwise, modifications of the plant or even the requirements can be considered. For example, components with different characteristics can be chosen, or performance requirements can be loosened.
The above cycle is iterated as necessary until the results are satisfactory. In this case, the design-space exploration activity starts. DSE consists of trying out different combinations of design parameters to find those that maximize certain figures of merit or minimize certain costs. In the approach proposed in this work, the design space is made of the intervals of parameter values that have been formally and experimentally shown to satisfy the requirements.
The design parameter values chosen by DSE are used to produce the final version of all the models, ready for further stages of development, such as HIL simulation and implementation.
Many variations to the above schema are possible. In particular, a logic specification can be both verifiable and executable, and then used both for verification and simulation. Another variation is the side by side deployment of verification tools and automated mathematical tools, as shown in the following sections.
Furthermore, it may be remarked that the software-based process introduced in this paper can be included in a complete process, where a HIL phase is used to validate the simulations.
5. Co-Simulation and Design-Space Exploration
In this section, we report the results of co-simulation for trajectory tracking of the rotor position.
Three FMUs have been generated starting from a complex Simulink schema that implements the entire electric drive: the first related to the generator of the desired angular position of the rotor axis; the second related to the control laws obtained with the FLC technique described above; a third one incorporating the part of the process to be controlled, which includes the models of pulse width modulator (PWM), inverter, and synchronous motor. The plant and signal generator FMUs have been generated using the FMI export feature of Simulink, while the FLC controller and its FMU have been implemented in Misra C.
Figure 9 describes how the three FMUs are connected together. In particular, the co-simulation orchestration engine manages the communication between each FMU so that when all FMUs execute a simulation step the updated outputs are provided to the FMU that requires them as input. For example, the output values
,
,
and
of the plant FMU are connected to the input values
,
,
and
of the control FMU, so at the end of every simulation step the co-simulation orchestration engine forwards their updated values from the plant FMU to the control FMU.
The chosen sampling time is 100 s. The choice is in accordance with the Nyquist sampling theorem. All the co-simulations performed in this work assume a fixed step size of 100 s and have a duration of 10 s.
In the simulations, the desired values of are sequences of rectangular pulses. The co-simulation results are shown as plots of the system response superimposed to the system positioning command . The figures are generated by the INTO-CPS interface. The ordinates are the values of and in radians and the abscissae represent time in seconds.
The line labeled Out1 in the legend represents and the line labeled Theta_m represents ; the label prefixes track.trackInstance and plant.plantInstance are the INTO-CPS names of the signal generator and plant FMUs, respectively.
Figure 10 shows the results of co-simulation for a value of
outside the range identified in the proof activity. In this case,
fails to reach three out of five desired values (
, 10, and
).
As another example,
Figure 11 shows the results of co-simulation when
is further above the upper bound of the range identified by the proof activity. The value of
does not follow the requested value and remains stuck near its initial value.
Figure 12 shows the results of co-simulation when the value of
is below the lower bound of the identified range. In this case,
approaches
with a damped oscillation.
Figure 13 shows that asymptotic stability is attained for a value of
within the indicated range, as
follows closely
except in the transient phase where it shows an overshoot depending on the difference between
and
.
On average, on an Intel Core i7-7700 CPU processor with 32 Gb of RAM, each co-simulation took 2 and half minutes to complete. It should be stressed that the FMI standard allows a black-box approach for co-simulation, in which each model can be expressed as a standalone FMU and different languages and tools can be easily combined together. The co-simulation presented in this section can, therefore, be easily expanded by replacing any FMU with a more refined one. Moreover, the standalone FMUs can be reused in other scenarios, reducing the time needed to assemble a new co-simulation.
5.1. Assessment
The verification work allowed the definition of sufficient conditions for system stability on the design parameters, and its assessment did not result in the need for changing the original mathematical model.
The assessment of the simulation resulted in the validation of verification results, as it showed that parameters values chosen within and outside the indicated ranges proved to be, respectively, satisfactory or unsatisfactory, as shown by the counterexamples in
Figure 11 and
Figure 12.
In a different scenario, the simulation activity reported in
Section 5 can be seen as an example of design carried out by heuristic, or trial and error, methods. In this approach different vales of
have been tried until acceptable values have been found.
5.2. Design-Space Exploration
The INTO-CPS DSE feature enables designers to specify the desired sets of parameter values to try, the objective functions, and the ranking criterion. The INTO-CPS application executes the co-simulations, collects the results, computes the objective functions for each tuple of parameter values, and ranks the tuples according to the specified criterion.
This section shows two applications of DSE, one to analyze design robustness with respect to variations of physical parameters and one to optimize design parameters.
In the first experiment,
Figure 14 shows the behavior of
for values of inductance L equal to the nominal value (50 mH) and to the values corresponding to the nominal value
. The control gain
is
. The continuous line is the desired
(
Theta_des in the legend), and each dotted line represents
for the three values of inductance. The results are qualitatively satisfactory since the differences among the curves are small. Clearly, a quantitative statement of the robustness requirements is needed for a definitive assessment.
In the second application, DSE was used to determine combinations of design parameter values that minimize the following objective functions:
the absorbed power,
:
the mean square deviation of the tracking error on the angular position,
the mean square deviation of the tracking error on the current’s direct component
In these equations,
is the number of samples collected in a single co-simulation run, one for each co-simulation step. In Equation (
12), the samples are the three-phase supply voltage (
) and the three-phase current vector (
). In Equation (
13), the samples are the values of the angular rotor position (
) and of its desired value (
). In Equation (
14), the samples are the values of current’s direct component (
) and of its desired value (
).
The following combinations of parameters are used:
has been fixed at
because this variable has a low impact on the system behavior, as shown in a previous work [
3].
takes the values
and
in order to study the behavior with two values, one inside and one outside the interval found in
Section 4.4.
the angular position takes the values of 10, 20 and 30 radians.
The inductance L takes the values , 50, and mH, i.e., the nominal value and small variations.
The Pareto front [
40] method has been used to find the best parameter combinations to simultaneously minimize pairs of cost functions. The combinations are ranked so that lower rank values indicate better performance.
Since the goal of this DSE analysis is to minimize all pairs of the objective functions, in the plots shown in this section, lower rank points are closer to the origin of the axes (the green points are the closest ones). In the figures, adjacent rank groupings have different colors, points connected by a line have the same rank and the values of the angular position are reported in the figures as they are related to different clusters, shown by ovals.
Table 4 and
Figure 15 show results for the power absorption of the machine (
) and the mean square deviation of the desired current tracking error (
), respectively.
Increasing values of (the number in the oval) lead to higher values of mean square deviation and more power absorption, meaning that small movements are more controllable and need less power, as expected. Regarding the effects of and L for any fixed value of , the best performance is achieved for smaller values of L and larger values of . For any , the best combination of parameter is L , while the worst combination is L .
Table 5 and
Figure 16 show the minimization of the power input (
) and the mean square deviation of angular position tracking error (
).
In
Figure 16, changes of
significantly affect the error of the tracking position, creating well separated clusters. For
, the values of L and
have little influence, whereas their influence increases for larger values of
. The combination of parameters that minimizes the error on tracking position is L
, while the combination that minimizes the power required is L
. The worst cases of each cluster are correlated with a larger value of L (
Table 5, rows 5 and 6 for
; rows 11 and 12 for
; rows 17 and 18 for
).
Table 6 and
Figure 17 show results for the minimization of deviations both of angular position (
) and current (
). In
Figure 17, it is possible to notice that the three different values of
lead to distinct clusters, well separated along the abscissae. Parameters L and
affect
more than
. For every
, the parameter combination that minimizes the error of the current is L
. It is possible to identify the worst combination for all parameters which is
L
.
From the results of the analysis, it is possible to recognize some patterns, so as to identify recurring behaviors or some trends of the system under examination.
It is possible to notice that experiments with the lowest value of have better performance for each pair of objective functions. This result is expected, as higher values of amplitude require the motor to perform faster and longer rotations.
Finally, from the minimization of and , it is possible to notice that the value of suggested by the formal method analysis produces the best results for while lower values of L produce the best results for .
6. Conclusions
This article presents a development process integrating formal verification, co-simulation and design-space exploration. An application of this method has been shown in the design of a controller for a mechatronic system, namely a feedback linearization controller for the reduction of cogging torque in a brushless motor.
Formal verification has been used to identify ranges of values for the controller gain coefficients, satisfying the stability requirement of the non-linear dynamic system. This verification provides designers with the starting point for subsequent design refinements, which otherwise could be derived only through a trial-and-error process.
Co-simulation made it possible to build a system model by assembling different submodels simulated by heterogeneous environments. This is a relevant advantage in the design of complex systems combining subsystems of different natures, such as electrical, hydraulic, mechanical, software, etc. The results of the co-simulation have validated the results of the verification activity. Furthermore, co-simulation driven by a high-level design-space exploration environment has been used to assess the robustness of the control algorithm with respect to parameter variations and to find optimal parameter values.
This work shows the usefulness of the proposed method in the development of control in electric drive systems, but it is as well applicable to many other areas such as driving and navigation algorithms and energy management.
Synergies between verification and co-simulation lead to a development process that exploits the results of both approaches to enhance the initial model.
Summarizing, a method of verification of a control algorithm has been proposed in this work that can be considered an advanced version of the classic SIL method in which part of the physical system to be tested is replaced with a software component that simulates its outputs. The new features of the proposed verification method with respect to the classic SIL method are listed as follows:
using the methodology described in the article, one could think of formally analyzing the global state of a mechatronic systems, with a view to safety, mapping the operating states directly with PVS and analyzing the final effects of the unpredictable variations of the parameters via DSE, as well as verify the robustness of the entire dynamic system through co-simulation
the development of a generalized and more automatic procedure can be used to analyze and verify conditions for the safety of the dynamic system and its users, which is essential in the field of automation and industrial robotics and in the motor vehicle industry, where often the development of a safe and efficient system requires a large number of field tests, which have significant costs
a systematic development process based on formal methods and co-simulations in the early phases of system design allows reducing risks in the physical prototyping phase.