Validation, off-line programming and optimisation of industrial control logic

Mechatronics 13 (2003) 571–585

Validation, off-line programming and optimisation of industrial control logic Fredrik Danielsson *, Philip Moore, Patric Eriksson University of Trollh€attan/Uddevalla, Box 957, S-461 29 Trollh€attan, Sweden

Abstract This article proposes a classification of different methods for validation, off-line programming and optimisation of control logic. The classification is an overview of different methods available and includes advantages and disadvantages for each method. The method overview points out a superior method, control system emulation, which is the most cost-effective and flexible method. The control system emulation method is also general and may be applied to validate and optimise control logic in various applications. Further, the method is compared with several other methods for validation of industrial control systems. However the method requires a standardised system architecture. This article proposes such architecture for the control system emulation method. Here, a control system emulator has also been implemented with the specific system architecture described in this article. An application case is also provided to demonstrate an approach to the integration of a control system emulator into a virtual manufacturing system. Ó 2003 Elsevier Science Ltd. All rights reserved. Keywords: Industrial control system; Validation; Emulator; Simulation; PLC

1. Introduction Since the introduction of industrial control systems in the late 1950s, one of the most important questions raised in the field has been: how control systems and control logic can be verified. This article presents a survey of different methods for verification of industrial control logic. These methods are divided into four main classes with subclasses. In reality there can also exist hybrids based on the methods described here.

*

Corresponding author. Tel.: +46-520-475183; fax: +46-520-475099. E-mail address: [email protected] (F. Danielsson).

0957-4158/03/$ - see front matter Ó 2003 Elsevier Science Ltd. All rights reserved. doi:10.1016/S0957-4158(02)00030-2

572

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

The main purpose of this paper is to describe a method for validation of industrial controllers. This method can also be used for optimisation of control logic for a specific control system. In this context, the term industrial control system refers to both the traditional programmable logic controller (PLC) and digital controllers. Normally, a modern system is a hybrid system, which includes both the logic part and the analogue part. Therefore, the term industrial control system is used instead of the old term PLC. In this article a method called control system emulation has been utilised to investigate how an implementation of a verification system can be designed and implemented. The method has been implemented with a specific system architecture, which is also described in this article. The control system emulation method does not in itself demand a specific architecture, i.e., it is possible to design a unique system for each control system. Yet, to realise the method, there is much to gain with a system architecture. The architecture that is described here includes methods for synchronised and distributed simulation. Time synchronisation of all subsystems to form a complete system is one of the most important features of the control system emulation validation method. The possibility to verify large systems with the use of distributed simulation is another important feature. The control system emulator has also been connected with a simulation application. To create a realistic simulated world, modelling should describe the geometric and physical properties of the objects simulated. The model will also represent the state of the assembly of objects in the workspace. The model must include theoretical models of the equipment such as robots, sensors, etc. A geometric model provides information about dimension, volume and shape of objects in the workspace. Objects can be represented in many ways. The most common technique is constructive solid geometry where objects are defined as constructions or combinations of primitive objects. Physical properties such as inertia, mass, friction, etc. may also be included in the model to make the model more accurate. However no model can be totally accurate. To deal with this problem, tolerances can be included in the model [1]. Focus in this article is the validation of the method and it is assumed that the production system model used is validated. Many types of simulation techniques and software packages for computers exits. The last 15 years have forced robot simulation forward and seen the establishment of institutes and techniques dealing with robotic simulation. Many robot simulation applications also offer a 3-D environment, where the world can be viewed as a wire frame model or as a solid model in full 3-D. To facilitate operations, robot simulation applications can be equipped with collision detection algorithms, check for singular position and reachability, etc. Within this work two different robot simulation software packages have been tested with success. Many researchers have undertaken research in the field of industrial control system verification [2–8] and others. They have produced theories and applications concerning different verification methods. There are two main fields within the research domain control system verification: (I) research only about control system logic verification [9] and (II) research about verification mixed with methodologies

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

573

for control logic design [10]. Suttie [11] has done a classification and identified five different methods for verification of industrial control systems. The focus of this article is confined to control system logic verification research area (I) and control system emulation. The industrial control system emulation method is implemented using a special protocol and architecture that supports distributed and synchronised simulation. Both the architecture and the verification method are tested in application cases. The industrial control system emulation method has several advantages compared to other methods. The main benefits are that (I) a complete validation can be done; (II) this validation can be done with time synchronisation between the model and the control system; and (III) this can be carried out with unmodified control logic.

2. Methodology for verification of industrial control systems and control logic In this section a classification of different methods for verification of industrial control systems and control logic are suggested. The classification will include methods for industrial control systems and control logic, i.e., these verification types are not separated in two different classifications. All methods are summarised in Table 1. Table 1 includes five main features and one disadvantage for each class. 2.1. General method overview Since the introduction of industrial control systems in the late 1950s, one of the most important questions raised in the field has been how control systems and control logic can be verified. Suttie has identified five methods for verification in [11]. These five verification methods have been reclassified here to include 18 methods and are structured in four main categories, namely, hardware, CPU response, logic analysis, and simulation. The methods are briefly defined as follows: 1. Hardware methods, see [12] a. On-line test on the real equipment, i.e., no prevalidation. b. Monitoring, i.e., on-line monitoring with e.g., patch panels, lamps, a debug tool, oscilloscope, etc. c. Hardwired test panel, i.e., simulation of the process with electrical components such as transistors, condensers, coils, lamps, switches, etc. 2. CPU response methods [13] a. Response program within a single processor, i.e., the control logic communicating through a memory interface with the response program. b. Response program dual processors, i.e., two control systems or more communicating through I/Os, serial links or over networks. 3. Logic analysis methods a. State space search, i.e., the input variables for the logic are varied (sometimes through all combinations) and the output state space is analysed [9]

574

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

Table 1 Methods for verification of industrial controls systems and control logic Method

Validation

Real control

Synchronised

Operator

Main disadvantage

Special hardware

1.a

No prevalidation Limited Limited

Yes

Yes

Yes

No pre-validation

Full installation

Yes Yes

No Yes

No Yes

No Yes No No Yes No No

No Yes Yes Yes Yes No No

Yes Yes No No No No No

Difficult to analyse Difficult to build panels Difficult to analyse Difficult to analyse Difficult to analyse Difficult to analyse Difficult to analyse Difficult to analyse No test of the real logic No test of the real logic Difficult to generate logic No real controller No real controller Hard to maintain real time Timing problem Hard to maintain real time Lack of emulators

Control system Control system and test panel Control system Dual control systems

1.b 1.c 2.a 2.b 3.a.1 3.a.2 3.b.1 3.b.2 4.a.1

No

No

No

4.a.3

Complete Complete Limited Limited Limited Limited Method test Method test Complete

Yes

No

No

4.b 4.c 4.d.1

Complete Complete Complete

Yes Yes Yes

Yes Yes Yes

No Yes Yes

4.d.2 4.e

Complete Complete

Yes Yes

No No

Yes Yes

4.f

Complete

Yes

Yes

Yes

4.a.2

Control system Control system

Real control logic: if the validation is done on the real control logic or on a model of the logic. Synchronised: if the production simulation model and the logic are time synchronised or not. Operator training: if it is possible to carry out operator training with the method. Special hardware: if the method requires any special hardware (aside from an ordinary computer).

1. automatic search, 2. manual search. b. Lexical analyser, i.e., the control logic is transformed to a more readable form or to another language for analyses [14,15] 1. automatic conversion, 2. manual conversion. 4. Simulation methods, i.e., the industrial control system or the control logic are connected to a simulation model in a computer. a. Simulation/user interface <- -> logic simulator 1. method test, 2. structure/framework logic generator, 3. complete logic generator. b. Simulation/user interface <- -> logic emulator [6]. c. Simulation/user interface <- -> control system simulator [2–4]. d. Simulation <- -> real control system [5,16]

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

575

1. real-time simulation, 2. non-real-time simulation. e. Simulation for on-line control. f. Simulation/user interface <- -> control system emulator. Common to all these methods are that they consist of two parts, namely, (I) a part that corresponds to the industrial control system and (II) a part that corresponds to the production system. In all methods except 1.a (on-line test) the production system is a model of the real equipment. The four categories are briefly discussed and compared below. 1. The first category, hardware methods, denotes a rather limited test where method 1.a (on-line test) involves no validation of the system before installation. This means that all tests must be conducted on the real production equipment. It is true that 1.b (monitoring) and 1.c (hardwired test panel) result in a validation before installation, but these two validation methods can be complicated and it is difficult to analyse the total effect of the control logic. 2. The methods in the second category have the benefit that it is easier to build and change the model in a CPU response model than in hardware methods. Some control system manufacturers even supply resources to facilitate the development of response programs. On the other hand, the problem of analysing the effect still remains. Another problem with this method is that industrial control systems are not adapted to building large models, i.e., the amount of RAM-memory and the CPU power is a limiting factor. Most of the control systems do not support simulated I/O and therefore the logic must be adapted to the response program. This makes it impossible to use the verified program on the real controller without modification. 3. The third category, logic analysis methods, is used to generate state space charts. There are two methods used to create a state space search. The automatic search method, class 3.a.1, searches the state space using random search or some more sophisticated search method. A manual search method, class 3.a.2, requires that the user generate the search table. For both of these methods, the state space chart must be analysed after each simulation. This is often a difficult task since the state space can be rather large. However, methods exist which include simple rules to describe how input and output data can be varied so that errors can be detected in an automatic way. The only problem is that these rules may be as complicated as the logic itself. Logic analysis methods are more common for general logic languages such as Petri nets, which offer no validation of the analogue part. 4. In methods from the fourth category, simulation methods, the response program is replaced by a simulation model that can be executed on a computer. With these methods, the model of the production equipment can be more extensive and there often exists more support for building such models on ordinary computers than for method of the second category (CPU response methods). In logic simulator methods, class 4.a, no real control system forms part of the verification; instead, a model of the logic is included. Recall that a simulation model is not an exact representation of the logic. For that reason, one cannot use the verified logic without modification; the logic must be translated before it can be used

576

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

on the real controller. No translator exists for methods in class 4.a.1 (method test) and one can only verify if the logic method is correct or not. Methods from class 4.a.3 (complete logic generators), however, generate logic that can be used on the real controller, while methods from class 4.a.2 (structure/framework logic generator) only generates a structure for the logic, which must be completed with contents. In methods of class 4.b a logic emulator is connected to a simulation model. The advantage compared to logic simulators is that the same notation is used in the emulator as in the controller, i.e., exactly the same control logic (including program language) is used both on the real controller and in the emulator. A drawback with this method is that the behaviour of the control system, e.g., scan times, network throughput and memory limits, is ignored. Even though the high-level control logic representation is exact in the emulator, the verified logic must often be translated or compiled before it can be used on the real controller. The reason is that the low level byte representation of the logic in the logic emulator differs from the real controller. A model of the control system is used in methods of class 4.c, control system simulators, and all logic will be represented in the same way as in the real controller. The benefit is that while the logic is as transparent as in control logic simulators, a control system simulation model includes far more details on how the real controller behaves. Moreover, there exists a special standard in the control system simulator field called realistic robot simulation (RRS) [20]. By means of a commonly defined RRS interface, control system simulation models provided by robot manufacturers can be integrated into computer aided robotic simulation systems. Still, since as control system simulator is only a model of the control system, it does not exactly correspond to the real controller. Hence the verified control system is the simulator rather than the real controller. Methods of class 4.d (real control systems) use no model of the controller. Instead, the real controller is connected to the simulation, e.g., through a serial cable or over a network. Hence there is not modelling error like in control system simulator, but other problems are present. Real control systems are often real-time computers that need inputs with exact timing while simulation models often lack real-time performance. If the logic used is insensitive to the timing, these methods will work well. On the other hand, since the simulation model and the control system run on different CPUs, they will be at a different logical time at any point in real time. This disadvantage can be serious if, for example, timers are used in the logic. With this method the real control system must be dedicated for simulations (i.e., it cannot be used for production during simulations) and usually the control system is mounted in a huge control cabinet far away from the simulation station. It is also possible to connect the simulation model to the real equipment for online control, as in methods of class 4.e (on-line control). These methods have the same demand for real-time performance as in 4.d (real control systems). A great benefit is that the same logic that drives the simulation will also drive the real equipment. In method 4.f (control system emulators), an emulator of the real controller is used. The difference between a simulator and an emulator is that the emulator is an exact representation of the real controller [17]. The emulator method has the advantage that it can be synchronised with the simulation, i.e., the system can be

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

577

considered to run in virtual real time and this solves the major drawback with method 4.d. Since the emulator is an exact representation of the real controller is it easy to exchange logic between the real controller and the emulator. This method will be discussed in more detail in the next section. The methods here are strictly divided in different classes and subclasses. In reality hybrids can also exist of different methods that are derived from the methods described above. All methods have advantages and disadvantages and all methods are still used today; even if class 4 will most likely gain popularity in the future since it needs no extra hardware and since simulation of production equipment is used more and more. We will probably also see a new standard for emulators and simulators for industrial controllers in the near future where method 4.f will play a major role. There are many benefits when using an emulator (method 4.f) for control system verification: 1. The entire function of the control system can be tested including the logic without modification. 2. It is often possible to use the usual development tools on the emulator since the controller is an exact representation of the real controller. 3. The method offers the opportunity to test large systems as will be shown later. 4. The simulation model can be synchronised with the emulator. 5. No specific hardware is needed (such as the real control system or the production equipment). However the control system emulation method suffers from two major drawbacks: 1. Currently few emulators exist that can be synchronised against a simulation model. 2. The effort to make simulation models that represent the production plant. The industrial control system field lacks an equivalent to the robot simulation module RRS [18]. In the RRS project suppliers of robot controllers and simulators cooperate in order to define a common architecture for robot controllers and simulation software. In the next section a detailed description of a proposed system architecture for control system emulators is given. Most of the methods above include a response program or a simulation model, i.e., a second program is needed. How can we justify that a new program is needed to verify the first one? Is this really an effective way of using project time and resources? This effort must be related to methods of class 1 (i.e., no validation of the system before installation) and all the disadvantages of an unverified program. 2.2. The method used in this study In this article, the method control system emulation (method 4.f above) is described. As mentioned before, this method uses an emulator that is connected to a simulation model. The reason why it is possible to build an emulator of a control

578

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

system is that almost all control systems are computers that work with digital representation, i.e., all states are digital (even the analogue part of a controller is internally represented with digital numbers). It is also possible to connect other equipment to the emulator such as a control panel, etc. To be able to connect a real control panel it is necessary for the emulator to run in near real time, since almost all communication protocols are sensitive to time disturbance. On the other hand it is possible to connect a control panel emulator or simulator that is insensitive to time disturbance since the time can be synchronised between the control system emulator and the control panel. To be able to perform validation, off-line programming and optimisation of control logic with the method control system emulation one needs the following components: 1. a control system emulator which emulates the target control system, 2. a simulation model, which simulates the production equipment, 3. a system architecture which connects all simulation models and controllers together to form a complete verification system.

3. A proposed system architecture for control system validation This section is focused on method control system emulation 4.f and discusses how this method can be implemented; it is assumed that the production system model used is validated. To take full advantage of this method (method 4.f) a system architecture is needed. The task of the system architecture is to join all subsystems to a complete EVS 1 system. There are many ways to create such a system architecture. For purposes of this experiment an open architecture has been chosen. This will simplify the inclusion of more than one emulator and simulator (i.e. the number of subsystems are not limited by the architecture). The advantage is that such a system can verify large PSs where several emulators and simulators are involved. To be able to run large EVS and to synchronise them a distributed approach has also been chosen. In a distributed system each subsystem can run on a separate CPU to form a cluster. The simulation cluster increases the total simulation power. 3.1. Distributed simulation To handle distributed simulation and synchronisation, a Synchronised Distribute Simulations Protocol (SDSP) was developed. SDSP is currently based on the TCP/IP 1

The notation ÔsystemÕ is frequently used but allows for several interpretations. To clear this up some definitions for the concept in the present context are introduced. The entire verification system (EVS) includes all subsystems needed to perform control system verification. A subsystem is a specific part of the EVS, e.g., a control system emulator. A production system (PS) is used to denote the plant that is subject for the verification.

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

579

Fig. 1. The three different layers in the system architecture for clients and servers.

communication protocol over LAN or Internet. SDSP consists of three layers, see Fig. 1. The first layer is a so-called adaptation layer and its purpose is to hide operating system (OS) dependent functions such as TCP/IP, threads, etc.; this layer is called the operating system adaptation layer (OSAL). The OSAL layer has been successfully tested on several platforms, e.g., IRIX, Solaris, Linux, and NT. The second layer is the SDSP protocol layer that includes low-level functions for sending and receiving data, connecting new subsystems, etc. The third layer is called the client layer and is a collection of high-level commands to maintain the implementation of clients. The client layer includes high-level functions for synchronisation, I/O updating, etc. 3.2. The SDSP server In order to handle the virtual time and all I/Os a SDSP server was developed that controls the EVS and all subsystems. The SDSP server handles all common information for the EVS, such as I/Os, simulation parameters, model status, etc. The SDSP server is also responsible for the EVS simulation clock and the synchronisation procedure between all subsystems. A synchronisation procedure of the different modules is important since no module runs in real time. This procedure makes it possible to run the system in non-real time and still verify a real-time system. The EVS system as a whole can be described as a discrete simulation with a time step ttick , even if a sub-system/simulation can and will be continuous. Using a server that is responsible for all advanced functions such as synchronisation, makes it easier to implement clients. It is, of course possible to create a system without a central server, but it takes more effort to implement each client since each client is responsible for synchronisation and must keep track of all other clients.

580

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

3.3. Other subsystems The main parts of the EVS are emulators, simulators and the SDSP server. To facilitate the verification process different auxiliary subsystem such as a connection block, a signal debugger, a data acquisition module, and a DDE module exist. The connection block program is a virtual representation of the connection block in the plant, where one can make hardwired cross-connections between different subsystems, connect I/Os to buttons such as an emergency shutdown and set an I/O to a constant value. The connection block is a tool allowing for easy connections without interfering with the simulation. The DDE module is a module to connect nonstandard SDSP clients to the EVS, e.g., MATLAB, FIX, factory link, databases, etc.

4. Industrial control system emulator A control system emulator includes three parts: a hardware emulator, an OS emulator and a logic emulator. These three parts will be discussed in the following sections. 4.1. Emulation of hardware The process of emulating control system hardware includes emulation of all hardware specific details such as interrupts, I/Os, timers, etc. (see Fig. 2). When emulation of hardware is discussed in this context it refers to a logical emulation of hardware functions and not electrical emulation of each component. Even if it is possible to emulate the function of all parts of the hardware, the most important aspect is that all hardware that the OS or logic expects to be there is emulated. The most common way for the OS and the logic to communicate with the hardware is through fixed memory addresses. It is therefore necessary to include a memory module in the emulator. The memory module will map all memory references to the right place in the memory on the emulator to avoid conflicts with the OS on the emulator. If the processor in the control system differs from the one in the emulator computer then a processor emulator or a byte code interpreter is needed. A byte code interpreter may also be necessary if there is a conflict with the normal OS and the emulated OS (e.g. the emulated OS may use instructions or memory references which conflict with the normal OS).

Fig. 2. Industrial control system emulator.

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

581

4.2. Emulation of control OS Many control systems have an OS that manages all low-level functions in the same manner as an OS does on an ordinary computer. Analogue and servo control are typical functions that reside in the OS. Reasons that some functions must reside in the OS are that they need to be fast or that the normal control system language does not provide the functionality to control all hardware. If the hardware emulator discussed above is complete, i.e., if all components are emulated including the processor, then it is possible to use the OS from the controller without modification. However, it can be difficult to emulate all parts of the hardware and therefore it may be easier to make small modifications in the OS to make it run on the emulator. 4.3. Emulation of control logic If all parts are emulated as discussed above, including both the hardware and the OS, there is no need to conduct a special logic emulation unless the logic communicates directly with non-emulated hardware. A situation where the user needs to change the logic to make it run on the emulator is unwanted because the goal is to test the logic without modifications. Since the emulator is byte code compatible with the real controller it is possible to use the normal development tools used on the real controller to develop logic for the emulator. Using the normal control system development tools makes it easy to download a verified program to the real controller when the verification process is over. It is also easy to upload an existing program from a controller to the emulator for maintenance and further development.

5. An application case To be able to verify the method and architecture described above a system for control system verification was constructed. The verification system consists of five computers where computer 1 runs the SDSP server application and matlab, computer 2 the emulators and control logic development tools, computer 3 the production simulation and debugging tools, computer 4 the connection block application, and computer 5 the operator panel (see Fig. 3). The verification system has also been tested on a single computer and it yielded the same results. The only reason five computers where used was to verify the possibility of running large distributed systems and to decrease the simulation time. The emulator is based on BiFas (http://www.binar.se), which is a commercial industrial control system. BiFas can be described as a combined PLC system and motion controller, able to control up to 4096 I/Os and 10-servo axis. The BiFas control system has a development environment called BiSoft, which supports IEC 1131-3 [19]. The emulator was written in C/C++ and was developed as a SDSP simulation client (see Fig. 2). The emulator includes both the PLC part and the motion part of BiFas. The same theoretical model of servos that the real controller uses was implemented in the emulator as a model for virtual servos. Many tests to

582

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

Fig. 3. An example of a verification system.

verify the emulator logic part (i.e., the PLC module) and the analogue part (i.e., the servo module) have been done with 100% correspondence with BiFas. Within this project both Robcad [http://www.tecnomatix.com] and IGRIP [http:// www.delmia.com] have been used as platforms for production simulation. Robcad and IGRIP include tools for kinematics and geometric simulation and validated models of common industrial robots. These softwares have been extended with a module for SDSP, which makes them to subsystems in the EVS. The internal clock in Robcad and IGRIP has also been synchronised through SDSP with the EVS clock. The facility to simulate industrial robots within Robcad and IGRIP has been tested and combined with the EVS. This makes it possible to simulate and verify large systems, which include both industrial control systems and robot controllers. MATLAB was used as an oscilloscope interface to the EVS to track analogue and digital signals. 5.1. The gantry crane A gantry crane at H€ ogskolan Trollh€ attan/Uddevalla has been used for the purpose of verifying the logic part of the emulator and the off-line capability of the verification architecture. The function of the gantry crane is to serve six flexible manufacturing system (FMS) cells with material. The crane is capable of handling
300 different pallets by the use of internal storage places. Each FMS cell can then send an order to the crane to pick up or leave a specific type of material or a specific job number in the cell. The control system application for the crane then has to decide which cell it should serve first and where to find the desired material. The control system application is extensive and has many potential pitfalls. The control system application was designed using the proposed architecture over a period of 10 weeks. A 3-D geometry RobCad model served as a model for the gantry crane and the BiFas emulator was used as the control system. The 3-D model is based on the drawings and measurements of the gantry crane. It is a rough model; the focus here is the validation of the method and not validation of specific simulation models.

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

583

However, it was sufficient accurate for the purpose of validating the control system verification architecture and individual components such as the emulator. In the end of the project the control system application was downloaded to the real control system and the gantry crane was powered up for the first time with the new application. The first movements/orders were then performed at low speed to avoid any serious damage. After the function check two errors where found; a limit switch was missing in the application and one of the axes was not correctly calibrated. Approximately two hours were spent on debugging and application upgrading. The result was a full function application that could handle all planned orders, i.e., serve six FMS stations and reach all 300 storage places. The result of this test case shows that the proposed verification architecture can be used to off-line program complex control system applications without access to the real equipment. Even if it is hard to achieve a control system application without errors, the effort to implement the final parts in the control system application can be dramatically decreased with the proposed architecture. Compared to on-line programming (method 1), the machine downtime was reduced from 10 weeks to 2 h in this test project. The effect gained depends, to a large extent, on the complexity of the applications.

6. Conclusion In this paper a comprehensive classification of different methods for validation, off-line programming and optimisation of industrial control logic, and their respective advantages and disadvantages has been presented. The method control system emulation seems superior to the other methods because 1. the entire function of the control system can be tested including the logic without modification, 2. it is often possible to use the usual development tools on the emulator since the controller is an exact representation of the real controller, 3. the simulation model can be synchronised with the emulator, 4. no specific hardware is needed. However, there are still no standardised architectures for this method. A detailed proposed architecture is therefore given. The advantages of this architecture are: 1. an open architecture to verify large production systems with many control systems and simulation models, 2. a distributed approach which allows a subsystem to run on a separate CPU to increase the simulation power and to form a cluster, 3. time synchronisation, i.e., a procedure that makes it possible to run the system in non-real time and still verify a real-time system, 4. an open protocol that is independent of the OS, i.e., the possibility to mix computer platforms in a simulation such as Unix and NT.

584

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

This project has also shown how the method emulated industrial control system can be implemented and used to verify large and complex installations where many control systems interact with the production equipment. The project has also illustrated the advantages of a system architecture to facilitate distributed and synchronised simulations. Some major benefits compared to other verification methods were also pointed out. However, the method also suffers for two major drawbacks, namely the lack of industrial control system emulators and the effort to make simulation models that represent the production plant. We will presumably see an increasing use of such verification systems in the near future because of the high availability demands and the short product cycles in the industry. For the method to be widely spread the industry needs an international standard so that all control system manufacturers can develop their emulators and so that simulation manufacturers can adapt their systems to this type of verification.

Acknowledgements The authors wish to acknowledge the financial support by the Foundation for Knowledge and Competence Development and EC Structural Funds.

References [1] Requicha A. Towards a theory of geometric tolerancing. Robot Res 1983;2(4):45–60. [2] Hanisch H-M, Thieme J, L€ uder A, Wienhold O. Modeling of PLC behaviour by means of timed net condition/event systems. In: IEEE Symposium on Engineering Technologies and Factory Automation. 1997. p. 391–6. [3] Hassapis G. Soft-testing of industrial control systems programmed in IEC1131-3 languages. In: ISA Transactions 39. 2000. p. 345–55. [4] Joshi SB, Supinski MR. The development of a generic PC-based programmable logic controller simulator. Int J Prod Res 1992;30(1):151–68. [5] Degrace C. Interactive testing of programmable controller application software with process simulation. In: Industrial Computing Conference 2. 1992. p. 459–68. [6] Kelley M, LeQuoc S, Cheng RMH. A simulation program form logic relay circuits in process control. In: Advances in Instrumentation/Proceedings of the Annual ISA Conference, Pittsburgh. 1981. p. 25– 32. [7] Wilkinson S, Cope N, Dullinger D. Generation of PLC control data from the simulation of flexible manufacturing systems. In: Proceedings of CISS-First Joint Conference of International Simulation Society. 1994. p. 488–91. [8] Arne B, Leo A. A flexible and integrated control concept. Anals CIRP 1990;39(1):463–6. [9] Lu H, Ying Z, Warren Liao T. Simulation of programmable logic controller. Comput Indust Eng 1992;23(1–4):351–4. [10] Taholakian A, Hales VMM. PN < ¼ > PLC: A methodology for designing, simulating and coding PLC based control systems using Petri nets. Int J Prod Res 1997;35(6):1743–62. [11] Suttie I. Real-time simulation in control system development. In: Proceedings of the Industrial Computing Conference. 1994. p. 167–71. [12] Webb WJ, Reis AR. Programmable logic controllers: principles and applications. 4th ed. Englewood Cliffs, NJ: Prentice Hall; 1999 [ISBN 0-13-679408-4].

F. Danielsson et al. / Mechatronics 13 (2003) 571–585

585

[13] Goss DE. The PLC device and process simulator. In: Advances in Instrumentation and Control, Proceedings of the ISA International and Conference Exhibition. 1995. p. 1035–45. [14] Leduc RJ, Wonham WM. Discrete event system modeling and control of a manufacturing testbed. In: Canadian Conference on Electrical and Computer Engineering. 1995. p. 793–6. [15] Taholakain A, Hales WMM. PN () PLC: a methodology for design, simulation and coding PLC based control systems using Petri nets. Int J Prod Res 1997;35(6):1743–62. [16] Evans DS. Simulation modelling of sequential fluid power systems using integrated PLC/PC development aids. In: IEEE Colloquium (digest), 214. 1995. [17] LeBaron T, Thompson K. Emulation of a material delivery system. In: Proceedings of the 1998 Winter Simulation Conference. 1998. p. 1055–60. [18] Bernhardt R, Schreck G, Willnow C. Realistic robot simulation. Comput Contr Eng J 1995;6(4). [19] International Standard, Programmable controller––Part 3: Programming languages, IEC 1131 3:1993(E), 1993. [20] Bernhardt R, Schreck G, Willnow C. The realistic robot simulation (RRS) interface. In: Inteligent Manufacturing Systems. 1994. p. 321–4.