Proportional-Integral-Derivative (PID) control is the most common control algorithm used in industry. The extensive use of electronics and software has resulted in the situation where the digital PID controller using a microprocessor as well as its software implementation replaces existing pneumatic, mechanical and electromechanical solutions. The reliability of the software system is assured by detection and removal of errors that can lead to failures. The paper presents mathematical methods for verification and testing of microprocessor-based PID controllers that can be used to increase the reliability of the system. The presented methodology explores the concept of testing with a model as an oracle. Regulator PID (regulator proporcjonalno-całkująco-różniczkujący)  Proportional-Integral-Derivative (PID) control is the most common control algorithm used in industry. It has been in use for over a century in various forms: as a purely mechanical device, as a pneumatic device and as an electronic device. Modern digital PID controller is a system that can be considered as a combination of computer hardware and software designed to perform a dedicated control function. The control is implemented on a custom hardware platform, which is often designed and configured for the particular application. Such systems are called embedded systems [29, 30] . Embedded systems may be observed in common devices employed in everyday living (e.g., coffee machines, washing machines, cell phones) as well as in sophisticated engineering systems (e.g. cars [4, 29] , planes, spacecrafts). PID controllers are also often safety critical systems. Due to the area of application, the PID controller must have high reliability as unexpected failures can be fatal. Ensuring the reliability of embedded software systems based on the detection and removal of errors that can lead to system failure. The process to verify that the system meets the specified requirements is referred to as testing. Testing is also the process of trying to discover every conceivable fault or weakness in a work product [12, 14] . The most common errors that can lead to improper operation of control devices equipped with the software include functional errors in the code, arithmetic errors associated with the use of fixed-point arithmetic, communication and task management errors, lack of robustness to different types of disturbances and work outside the scope of the variability of input signals. There are several facts that show clearly possible consequences of poorly tested systems. On February 25, 1991, an Iraqi Scud hit the barracks in Dhahran in Saudi Arabia, killing 28 soldiers from the US Army. This accident was caused by software error in the system's clock [24] . The PATRIOT missile battery has been in operation for 100 hours, by which time the system's internal clock had drifted by one third of a second. For a target moving as fast as Scud, this was equivalent to a position error of 600 meters. Another example is connected with Therac-25 radiation therapy machine that was produced by Atomic Energy of Canada Limited and CGR of France. The machine was involved with at least six known accidents between 1985 and 1987, in which patients were given massive overdoses of radiation, which were in some cases on the order of hundreds of grays [18] . At least five patients died of the overdoses. These accidents were caused by errors in software control application.One of the most infamous computer bugs in history was found during flight 501 that took place on June 4, 1996. This was the first, and unsuccessful, test flight of the European Ariane 5 expendable lunch system. Due to an error in the software design (inadequate protection from integer overflow), the rocket veered off its flight path 37 seconds after launch and was destroyed by its automated self-destruct system [19] . As it was an unmanned flight, there were no victims, but the breakup caused the loss of four Cluster mission spacecraft, resulting in a loss of more than $370 million. There are two basis classes of software testing: black box testing and white box testing. Black box testing is testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. White box testing is testing that takes into account the internal mechanism of a system or component. Black box testing is also called functional testing [2, 3] or specification-based testing. The specification for control systems can be very often presented in the form of models. Test cases should be then generated systematically out of the models [29, 30] . The most popular black box testing techniques include boundary value analysis, equivalence partitioning, decision table testing, state transition testing and use case testing (see e.g. [3, 22] ). Boundary values analysis is a testing technique in which tests are designed to include boundary values of input functions to stimulate the system. The idea comes from the boundary, which is the area where testing is likely to yield defects. Equivalence partitioning is a technique that divides the input data into groups that are expected to exhibit similar behavior, so they can are likely to be processed in the same way. The groups are called equivalence partitions (or classes) and can be also identified for outputs, interval values and parameters. Decision tables are a good way to capture system requirements that contain logical conditions. State transition testing is much used within the embedded software industry and technical automation where the system behavior can be represented using state diagrams. Tests can be also specified from use cases or business scenarios. A use case is a sequence of steps that describe the interactions between an actor (a user of the system) and the system. White box testing (also called structure-based testing) is based on an identified structure of the software or system. The structure can be considered as the code itself (i.e., statements, decisions or branches), a call tree (a diagram in which modules call other modules), a menu structure, business process or web page structure. Test cases designed with the help of white box testing techniques take into account such input values to cover relevant instruction in the code (instruction testing), decisions (decision testing), conditions, etc. It should be emphasized that most of the presented techniques and methods are seldom applicable in testing software systems where the dynamics cannot be neglected [20, 27] . The dynamical systems are modeled by difference or differential equations and have usually infinitely many states. There is a need for another approach that will handle continuous aspects of the system (see e.g. [6, 17] ). This is because of testing dynamics aspects of such systems requires tests that utilize time continuous input signals and time continuous output signals (even when the system is digitally processed). The process of selecting just a few of the many possible scenarios to be tested is a difficult and challenging task and currently is most often based on qualitative best engineering judgment. Some results [5, 11, 15, 28] developed for hybrid systems can be also applicable to dynamical systems and to fractional-order systems (see e.g. [21] ) which recently are of interest to many scientists and engineers. The paper is organized as follows. In the next section, modeling concepts of the functionality realized by the PID controller are introduced. These concepts are explored further in the next sections and are the base for creating test artifacts such as: test oracle (Section 3), notation of tests (Section 4), implementation of a test comparator (Section 5), test coverage (Section 6) and test generation (Sections 7 and 8). Experimental results are given in Section 9. Conclusions are in Section 10. An embedded PID controller is a system that can be considered as a combination of computer hardware and software designed to perform a dedicated control function. The PID controller ( Fig. 1 ) works in a closed-loop system and attempts to minimize the error e(t) by adjusting the control input u(t). The error is calculated as the difference between a measured process output y(t) and a desired set point y sp (t). The control signal is a result of the following calculation where The control signal is thus a sum of three terms: the P-term (which is proportional to the error), the I-term (which is proportional to the integral of the error), and D-term (which is proportional to the derivative of the error). Introduce the notation w t e t 1 0 (1) can be written as: or, equivalently, in matrix notation as: where w t w t w t W  The physical and implementation constraints imposed by computer system resources lead to the assumption that the space W is bounded. The assumption means that the space W is contained in a circle of finite radius. The formulas (1) and (3) specify mathematically the system's behavior in clear and unambiguous form. It can be used in computer simulations in an early phase of development to validate the system concept, calibrate parameters and optimize the system performance. In the next phase, the physical system is designed (i.e., hardware and software) that shall meet the specified requirements in the form of the equations (1), (3). Testing process shall be considered as the last phase in the development process that allows verifying that the physical system behavior is identical to that observed during computer simulations. If the tests fail then the system needs to be redesigned. The physical system that is being tested for the correct operation is often referred as system under test (SUT). The term test oracle describes a source to determine expected results to compare with the actual result of the SUT [1] . The role of such source in the model-based approach is often played by the model (see Fig. 2 ). The approach stipulates that the same input is applied to both the SUT and to the model. The input signal is physical in case of the SUT (e.g., voltage, current or resistance) and virtual in case of the model; from logical point of view both signals are equivalent. The judgment whether the result of a test is in conformance with the model is delegated to a test comparator. The test comparator is usually a tool that compares the actual output produced by the SUT with the expected output produced by the model. One of the fundamental tasks of software testing is the creation of test cases. A test case can be considered as a set of inputs, execution preconditions and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement [13] . Adapting this definition to the SUT modeling concepts (1), a single test case T case ( ) j can be defined as: where j=1,2,…,N, N≥1 is a label to indicate different test cases, →  is an expected output function, T (j) stands for test execution time. Notation (5) and the model (1) play the key role in the test selection method presented in Section 8. When the system model is described by the equation (3)  The test comparator can be considered as a tool that implements a mechanism for determining whether a test passes or fails [14] . In the concept illustrated on Fig. 2 , this tool compares the actual output produced by the SUT with the expected output produced by the model (1) or (3). A possible practical realization of the comparison function for a given test case (5) is presented below:  where z denotes the test result, that is, z=0 when the test passes, z=1 when the test fails, ε>0 is the tolerance range, u j s ( ) ⋅ ( ) stands for the output produced by the SUT. In the similar way, the comparison function can be defined for notation (6):  The degree to which a given test suite T suite addresses all specified requirements for a given system is determined by a test coverage measure [13] . The most obvious quantification of the system's behavior exercised by the test suite is computed by dividing the number of the system states explored by the test suite by the cardinality of the entire state space. However, the formula has limited usefulness for dynamical systems (and PID controller belongs to this class of systems) because the state space for such systems contains usually infinite number of states. In following part of this section it is presented a method for calculation of test coverage that was taken from the paper [25] .The method described therein has been adapted to the model (3). The test coverage C h (T suite ) of the test suite T suite can be defined as follows:  is the transformed state space created from the system state space W,  will contain the information about the states covered by the test suiteT suite . In the example presented on Fig. 3 , bounded two-dimensional internal state space W (the area embraced by the bold solid line) has been transformed to the space  In this section, an algorithm for generating test cases is presented. The algorithm uses the modeling concept (3) of the SUT to generate test cases and calculate test coverage according to the method presented in the previous section. It explores transformed state space by using input signals that steer the system from an initial state to a final state. The selection and completeness of test cases is quantified by the coverage metric (10). The main idea of the presented strategy is to check that the functional specification in the form of the equation (3) is correctly implemented, which is variously referred to in the literature as conformance testing [14] , correctness testing [16] or functional testing [13] . 1°: Set the parameters: For safety critical systems there would be recommended to decrease the granulation of the partitions h i . However, it should be clear that too small granulation significantly increases the number of test cases and overall testing effort. Remark 2. The system (3) is controllable as the rank of the controllability matrix is equal to the size of the system, that is, rank[E EF]=2 (see e.g. [20] ). This means that there exist generally many different controls which steer the system from the zero initial state to the final state w a at time T>0. For example, minimum energy control [20] is probably the easiest computable control steering the system to a desired state under the assumption that the constraints posed on the system are not violated. In this section, the test selection problem is formulated as an optimization problem. Representative test cases are constructed during optimization procedure using the model (1). The test selection is combined with the test execution and these two activities are conducted at the same time. The main advantage of the approach is focus on Fig. 3  In order to evaluate the efficiency and usability of the presented algorithms as well as their ability to find faults they were applied to the real system. The faults in the form of incorrect parameters of the PID controller have been deliberately introduced to the system implementation. For better illustration of the results the parameters have been modified by 20% from the correct values. In practice, these faults can be caused by the use of fixed-point arithmetic; they can also result from errors in the identification procedure and can be a direct consequence of programmer error. Introduction of incorrect parameters values to the control system can result in different time to reach the steady state than expected, larger overshoot in the system and in the worst case in instability of the closed-loop system. Good control quality depends strongly on the correct settings what is especially important in optimal control problems [7] applicable, for example, for electric motors [8] and internal combustion engines [26] . Consider the model (1) of the PID controller with the following parameters Next, the functionality described by the equation (1) has been implemented in software, which runs in a microprocessor on the embedded hardware platform, however with incorrect values of the parameters, that is The entire system has been tested with the help of the algorithm 1 which has been implemented and executed for the following input parameters: h=[0.3,0.2] T , δ=0.7, T=20 [s], |w 1 (t)|≤1.5, |w 2 (t)|≤1.0 (system implementation constraints).The test suite that guarantees the coverage level higher that δ consits of 10 test cases. Elements of the generated test cases of the form of (6) are graphically presented in Figs. 4 and 5. Comparison of the actual trajectory obtained from the SUT with the expected trajectory is shown in Fig. 6 . The output from the SUT for the first test case is not within the tolerance range ε=0.1 relative to the expected output, therefore the test case is qualified as fail. This proofs existence of the fault in the system. Consider the following set of admissible error functions: , , : that can be used in the optimization procedure (algorithm 2) to find such test cases that maximize the difference (17) between the outputs produced by the tested system and its model within the time T. The implementation of the algorithm with the Nelder-Mead simplex (direct method) [23] leads to the following local optimal solution: Elements of the generated test cases of the form of (5) are graphically presented in Fig. 7 . The figure includes also for comparison purposes the actual trajectory obtained from the tested system. The main advantage of the testing method based on the algorithm 2 is a significant reduction of test cases, which the search is done using the optimization procedure. The algorithm focuses on error prone situations. As a result, the time and cost associated with the testing of the system can be significantly reduced. Since the effort put into testing is, according to estimates [2] , from 30 up to 90 percentage of the overall effort in the projects, the benefits coming from even a very small reduction of this factor can be very profitable. It should be also noted that the algorithm 2 performs the search for test cases while using the physical system and its mathematical representation. Thus, to start the process of testing both the model and the real system are required for. Moreover, the formulation described in the algorithm 2 takes the form of a functional optimization problem, which may appear difficult to solve as it requires transformation to a value optimization problem. The paper has presented two different methods for testing embedded PID controllers to provide required quality of the system, assure compliance with safety standards and eliminate errors at the stage of system design. Elimination of errors in the early stages of product development can increase system reliability and reduce the risk of failures during the operational phase. All elements of the testing process (i.e., concept of testing, notation of test cases, implementation of a test comparator, test coverage, selection of test cases) have been formulated and described in using the appropriate mathematical notation. The key role in the presented approach plays the mathematical model that represents intended behavior of the designed system. In this way it was possible to develop methods for testing systems where the dynamics plays an important role and where classical testing techniques cannot be applied to. The presented approach can be easily generalized to other microprocessor-based control systems. Controllers with dynamic compensator [27] , electric motor controllers [7, 8] , controllers of internal combustion engines, neural networks controllers [9] and fuzzy logic controllers [10] are examples of the systems that can be verified using the algorithms described in this paper.
During this phase, special attention also needs to be paid to the implementation aspects, as outlined in REF .
Mathematical methods for verification of microprocessor-based PID controllers for improving their reliability
Eksploatacja i Niezawodnosc - Maintenance and Reliability
Eksploatacja i Niezawodnosc - Maintenance and Reliability
Computer Science