A Component-Based Modeling and Validation Method for PLC Systems

Programmable logic controllers (PLCs) are complex embedded systems that are widely used in industry. This paper presents a component-based modeling and validation method for PLC systems using the behavior-interaction-priority (BIP) framework. We designed a general system architecture and a component library for a type of device control system. The control software and hardware of the environment were all modeled as BIP components. System requirements were formalized as monitors. Simulation was carried out to validate the system model. A realistic example from industry of the gates control system was employed to illustrate our strategies. We found a couple of design errors during the simulation, which helped us to improve the dependability of the original systems. The results of experiment demonstrated the effectiveness of our approach.


Introduction
Programmable logic controllers (PLCs) are widely used in industry for safety critical embedded systems. A PLC controls several physical plants concurrently. It receives signals from sensors and human inputs and produces control commands to actuators cyclically. A PLC embedded software system is different from conventional software. It is a reactive system that is designed for nonterminating work. The environments are always uncertain and changing with time. Some of the control requirements are real-time related. All of these issues make it hard to ensure the safety and reliability of the control system. Validating such systems is of paramount importance because they are widely used in industrial applications and must meet stringent safety requirements.
Several formal techniques are used to model and analyze PLC-based embedded systems. Most studies on PLCs have focused on PLC program modeling and verification. Mader [1] has presented an overview and classification of PLC models. Canet et al. [2] directly coded the existing program written in instruction list (IL) language into the input language of the SMV [3] model checker. They did not consider the aspect of time in the model. The Petri net is also a well-known method of modeling PLC systems. Heiner and Menzel defined a Petri net semantics of IL in [4]. Programs and environments were modeled as the Petri net. But the verification phase has not been considered. In [5,6], the signal interpreted Petri net (SIPN), which extended the Petri net with input and output signals, was adopted to model PLC systems. Such extension is powerful for modeling, but the Petri net tool is not strong enough to analyze the SIPN. None of the above studies are component based. As PLC system always has time constraints, timed automata were adopted to model this feature. A PLC program translation tool is given in [7]. It translates IL programs to timed automata that can be checked by Uppaal [8]. But the types of data are restricted to the Boolean type. Zhou et al. [9] proposed a more complete method than current ones of translation from IL program to timed automata. The translation is efficient which results in a reduced verification model. Wang et al. [10] 2 Advances in Mechanical Engineering used timed automata to model the PLC control software and environments and then systematically verified the functional and timed properties. A framework for specifying and verifying control logic components in industrial applications is proposed in [11]. The component includes specification and implementation and can be automatically translated into inputs of SMV.
Validation using formal methods suffers from wellknown complexity limitations. The modeling languages are not expressive enough to faithfully describe the actual behavior by using real-time constraints. Furthermore, validation by fully exploring the state space is prohibitive, as the model involves data and timing constraints. Timing constraints are necessary for analyzing the dynamic behavior and drastically increasing the complexity of the state space. Our modeling and validation method can avoid these shortcomings. In this paper we apply a new model construction methodology to PLC applications. The component concept is first employed in the PLC modeling area. The BIP [12] framework supports component-based modeling and validation. The BIP framework enforces the reusability of functional components. We propose a components library of the commonly used functions and a general architecture for device motion control system. The architecture decomposes the controller into three levels. Each level is modeled as a composition of functions. As the modeling and validation focus on the system level, we not only model the control software but also model the environment and human behavior. Environmental uncertainty is expressed in our model. As the system is very complex, we validate it by simulation. Requirements are formalized as monitors, composed of the global system model. The monitored system was extensively simulated in BIP. The simulation was carried out by BIP tool chain. We found and corrected two design errors that may correspond to bugs in the real system. This paper is organized as follows. Section 2 gives background on the BIP framework and associated tools. Section 3 presents the architecture and components library. Section 4 contains the case study. The validation work is shown in Section 5. Section 6 concludes the paper.

The BIP Framework
The BIP (behavior-interaction-priority) component framework is a formal supporting, rigorous design for heterogeneous component-based systems [13]. It allows the description of systems as a composition of atomic components characterized by their behavior and their interfaces. It supports a system construction methodology based on the use of two families of composition operators: interactions and priorities. Components are composed of the layered application of two operators.
In BIP, atomic components are finite-state automata extended with variables and ports. Variables are used to store local data. Ports are action names and may be associated with variables. They are used for interactions with other components. States denote the control locations at which the components await interaction. A transition is a step, labeled by a port, from one control location to another. It has an associated guard and an action that are, respectively, a Boolean condition and a computation defined on the basis of local variables. Connectors include sets of ports and interactions. Interactions describe synchronization constraints between the ports of the composed components. Interactions are used to specify multiparty synchronization between components as the combination of two protocols: rendezvous (strong symmetric synchronization) and broadcast (weak asymmetric synchronization). Interactions are defined using connectors. Every interaction has a guard, that is, an enabling condition and an action. The action can be an update function, operating on data associated with the ports participating in the interaction. Connectors are sets of ports augmented with additional information as follows. Within the connectors, every port is either a synchron or a trigger type of port. Trigger ports are used to initiate broadcasts; that is, any subset of ports containing at least one trigger port denotes a valid interaction of the connector. Rendezvous synchronization is obtained on connectors where all ports are synchrons. For such connectors, the only valid interaction is the maximal one, that is, the whole set of ports. Finally, connectors provide mechanisms for dealing with data associated with ports of interacting components.
The BIP framework is concretely implemented by the BIP language and an extensible toolbox [14]. The toolbox provides front-end tools for editing and parsing BIP programs, as well as for generating an intermediate model, followed by code generation (in C++) which is used for runtime validation. The correctness of the generated C++ code is confirmed by the formal semantics of BIP. Intermediate models can be subject to various model transformations focusing on the construction of optimized models for sequential [15] and distributed execution [16]. It also provides back-end tools including runtime for analysis (through simulation) and efficient execution on particular platforms. The toolbox provides a dedicated modeling language for describing BIP components and connectors. The BIP language leverages on C-style variables and date type declarations, expressions, and statements. It also provides additional structural syntactic constructs for defining component behavior, specifying the coordination through connectors.

The Component-Based Modeling Method
One of the advantages of the component-based modeling method is reusability. A system architecture and a component library are ways to achieve reusability. Motion control systems use PLCs to control the movements of mechanical devices that are powered by motors. The common parts of these systems are the functional control of all kinds of motors. Motors include constant speed motors and variable speed motors. Some devices are required to reach an exact position. Some require the devices to stop when meeting the limit switch. In particular, BIP separates behavioral and architectural aspects in modeling. Architecture is meaningfully defined as a combination of interactions and priorities. In addition, we discuss the expressivity of BIP and related Advances in Mechanical Engineering 3 component-based frameworks. In our discussion, we show that the combination of interactions and priorities gives BIP a universal form of expressiveness. Numerous translations are defined from existing models of computation and domainspecific languages into BIP.

System
Architecture. The global architecture of the BIP model is shown in Figure 1. This architecture is general and suitable for motion control applications. When we model the system with a component concept, we adopt the following decomposition principles.
(1) The software and hardware architecture partition is as follows. The architecture design can construct the system topology relations. The system run environment also has an impact on the partition. We first consider the natural physical organization. The system is decomposed into user, software system, and controlled devices. (2) Layered decomposition of the control software is as follows. In a PLC-based control system, the control software is organized as layers. The lower layer supplies services to the upper layer. The top layer is responsible for user interaction and operation flow. Different domains have different meanings. For example, the top layer of the motion control system manages scenario control. The middle layer is always a protocol. The bottom layer is the functional level, which takes charge of the interaction and controls the actuators and sensors. (3) The functionality decomposition of each layer is as follows. The father principle can follow a business step or function modular. For example, the first level is decomposed into the command scheduler and scenario components. This will enforce the reusability of the scheduler. The bottom layer is composed of individual functional components.

Motion Control Components.
Motion control systems always have similar basic functions. We summarize and model these functions in the library. When modeling and verifying other motion control systems, the system architecture and components in the library can be adopted directly to compose the system model. We formalize four kinds of frequently used control functions as follows:  Figure 3 are used to model the physical properties of variable speed devices. When the model receives a move command from the Var-SpeedControl component, it moves to the start state and then regulates the speed (according to the specified speed) at every tick time. When a limit is reached (either the UP LMT or the DOWN LMT), the device throws a signal that informs the VarSpeedControl that the device has reached that limit. The moving() and slowdown() functions are used to model the motion of the device. A random factor is added in every single moving step to model uncertainty. moving() is executed when the move command is received, while slowdown() is executed when no move command is received and the device keeps moving due to inertia.  is a cycle of steel track around the stage. Eight gates moving on the track in a queue can turn the stage into a closed round space. A gate warehouse is located near the stage. All gates can fold in the gate warehouse when they are not in use.

Case Study
The main functionality of the PLC system is to control the folding or unfolding of the gates into or from the gate warehouse and move along the steel track. The physical structure of this system is presented in Figure 4. A user can give commands in the control panel, and the PLC will execute the commands and sends electric signals to physical devices through PROFIBUS-DP network. The speed, location, and status of the devices are sent back to the PLC. The gates are 20 m long, 19 m high, and 1.2 m wide. They are made of wood and are very heavy. The gates have wheels at the bottom, so that they can slide along the track. Eight gates are stored in the gate warehouse. Only six of them can emerge from the gate warehouse and move along on the track. The last two emerge directly to their final (and fixed) position. Gates standing on a seat are pulled by push-pull units when they move straight into the gate warehouse. Two lifting platforms are used to lower or lift the seats of the gates. Each lifting platform is fixed with four latches. The latches are driven by constant speed motors. There are two limit switches at the end of each latch. Only when a latch is completely inserted or pulled out will the switches be able to send high-level signals to the PLC. In the folding or unfolding process, each pair of gates requires seven steps, and three pairs require a total of twenty-one steps. These steps are described below.  In the folding (backward) scenario, the steps are carried out in the opposite order.
In this system, human safety is of most importance. The gates, push-pull units, and lifting platforms are big and heavy. They move within a restricted space. Some of their motion routes cross. We should ensure that these devices do not crash into each other. There is an urgent stop button on the control panel. When something dangerous happen, a user can press the stop button and stop all devices within 0.1 s. The functional requirements include the following. (iii) A moving device must not exceed its upper or lower bounds.

Component-Based Modeling of the PLC System.
The software is the most important part. There are hundreds of devices moving in a restricted space that need to be controlled. Thus the kind of software that is required is complex. Based on the proposed general architecture for a motion control system, we built a distinct layered structure for this system shown in Figure 5.
(i) The top level is the main program. It stores the scenario information, executes user commands, and schedules the device controllers. The main program receives forward, backward, or uStop commands from the user and executes control sequences. It starts moving devices one by one with the preset order. The user can stop the scenario and restart the process with two direction choices (forward or backward).
(ii) A constraints checker is in the middle which controls the proper execution of devices based on the safety constraints. It receives status data from all devices and checks whether the device can move or not. It stores status data of all devices.
(iii) The bottom level, close to the physical environment, is the functional level. It includes four kinds of device controllers, respectively, the atch controller, gate controller, push-pull unit controller, and liftingplatform controller. If a device is required to move, it requests permissions from the execution control level. The latter checks the safety constraints and responds accordingly to the controller. Every time the data of a physical device changes, the controllers update the data of the execution control level. After a device moves to its preset destination, the controller sends a finish signal to the main program. The main program will start moving the next device and so on, until the whole scenario is completed, that is, when all devices reach their positions. Figure 6 executes the scenario and user commands. In order to increase the reusability of the system model, we separate the operations and scenarios into two components.   Figure 7 is very simple. If data is changed in the controllers, it receives a notify signal and renews the data by using the UpdateData() function. If controllers ask for permission to initiate a movement, the constraint() function calculates the result and sends it back to controllers. The constraint() function written in C-like language comes from the source code of this control system.

Functional Component.
The controller models of the gate, push-pull unit, and lifting platform are all instances of the VarSpeedControl(DevNo, Speed, Dest) component type. The controller models of the latches are instances of the Con-SpeedControl(DevNo, Dir) component type. In this application, we have six gate controllers, eight latch controllers, two lifting-platform controllers, and 5 push-pull unit controllers.

Environment Model.
In order to make this system a closed one, we model the controlled devices and the user in the environment. Latches are instances of ConSpeedDev(Dir) components. The gates, push-pull units, and lifting platforms are instances of VarSpeedDev(Dir, Speed) components.
In order to simulate the behaviors of a user, we design a random user model. The random user in Figure 8 makes a decision every 30 ticks by choosing forward, backward, uStop, or nothing with a random rate. This model tries to model all possible behaviors. This ensures that the controller acts correctly not only in the case of normal behavior but also when unexpected behavior occurs.
In this case, we have the PLC codes. The BIP model should be a correct abstraction of the codes. The software has the corresponding part with BIP component, but the correspondence is not exactly the same. For example, the gate control function in the PLC code calls for several subroutines. We model these subroutines in one component. But they are functional equivalents. Regarding specific data and operations in the BIP model, we obtained these directly from the PLC code in the following way. For this case study, the system model contains 46 atomic components and 185 connectors (interactions). The system is a compound component. The BIP script of the system consists of more than 2200 lines.

Validation
Validation of BIP models can be achieved by using runtime validation techniques. The runtime validation technique for BIP is based on the construction and execution of monitored systems. Historically, the validation approach is oriented towards finding errors rather than proving the absence from design. This approach has been adopted for BIP components as explained in [17]. It consists of constructing an executable model for evaluating safety requirements. Monitors are atomic components that observe the system state and react by moving to the error state where the safety properties are violated, that is, if an interaction has been executed or an invalid sequence of interactions has been executed. The BIP framework provides native support for building and running executable models for monitored systems.
Here we use the runtime validation of BIP, as the model is complex and constrains 2000 lines of C code in the constraint component. The runtime validation technique needs to construct and execute the monitored systems. (ii) Compose all of the monitors and the global system model to obtain the monitored system, say, Now, the model is ready for simulation. If the requirements are violated, the monitors will transit to the error state.

Modeling Requirements as Monitors.
Four requirements are modelled as monitors. When this requirement is violated, the monitor transits to the ERROR state.

Deadlock-Free
Property. The reactive embedded system should make rapid response to the input of the environments and executed infinitely. So the system should be deadlock free. For this property we do not need to build monitors, we run the BIP tool with model .

Stop Properties.
The device will stop if it meets the limit switch. For this property, if the monitor shown in Figure 9 catches the ReachLmt signal, before receiving next start signal, there should be no move signal from the device controller to device. This property concerns 16 devices (i.e., all devices, except for push-pull units).

Urgent Stop Properties.
The user stop command should be executed within 1 tick (0.1 s). Figure 10 is the formal model.

Safety Bound Properties.
Device movement cannot exceed the upper or lower bounds. Every device has the travel range, so 21 monitors are built for observation. From the INIT state, after a tick time, the monitor of Figure 11 gets the current position of the device. At the CHECK state, if the current position is less than the low bound or bigger than the upper bound, this monitor will transmit to ERROR sate and print LIMIT MONITOR: ERROR; otherwise it will transit to the INIT state. A different instance of this monitor has been used for every moving device in the system.

Validation Result. The BIP model
can be compiled to a program written in C++ by the BIP tool and then can be further compiled to an executable binary program. We ran the simulation program for seven hours, which corresponds to approximately four hours of a real system's lifetime. We discovered two design errors for the two types of users. this is that the limit position is reached if the position of the device is within a fixed range of the limit position. This is the case in physical deployment, where limit switch sensor checks if the device is near the sensor. In the linear case, assume that sensor is located at and that it checks if the device is in the range of [ − , + ]. The sensor sends the result every cycle, and each cycle takes time. If the speed parameter is not properly set, for example, the device is asked to move at a speed which is greater than 2 / . Then the sensor may fail to detect if the device has reached the limit position. Engineers have confirmed that they have actually experienced this kind of problem. Their speed parameters are chosen by test conducted on the real system. Our simulation can help in choosing the proper parameters.

Validation of Urgent Stop Property.
For the urgent stop property, we checked that the stop command takes effect within 1 tick. However, if the property is specified as one in which the stop command takes effect immediately, the simulation will fail. We investigated this situation and found that the stop command is a global command. It is possible that, at the time that user pressed stop, some device, say a movement takes some time. Then, the controller can capture the stop command after this tick. Consider In general, the simulation finds two potential errors in the system. The simulation on computers can also help engineers to choose the proper parameters instead of running experiments in the real world.

Conclusion
The paper reports on a component-based modeling and validation methodology for a type of control system implemented on PLCs. We have shown that, by using the BIP component framework, a complete model of the system can be obtained with the help of system architecture and component libraries. We propose a universal software architecture and components library for device motion control systems. The decomposition of the architecture into three layers enhances the readability of the model and allows its complexity to be mastered. Modularity is essential for incremental construction and modification. The library can offer commonly used components. This makes the modeling of such a control system convenient and dependable. Timing constraints are modeled by using a time progress signal tick in each component that represents the progression of time by one unit. The tick signals of all components are strongly synchronized.
We have presented a rigorous method for validating the global system model by simulation. The method consists of building a monitored system where the requirements are modeled by monitors that continuously sense the state of the system to be validated. Reaching an error state means the violation of some requirements. Following the BIP design flow, the following work is about the model based code generation. Although the BIP toolkit has the code generation subpart, it is for the generation of C++ code. The generated code cannot be used at all. We are developing a code generation algorithm and tool for the PLC hardware platform. The special features of a hardware platform should be considered.