外文翻译格式说明.doc

山东理工大学毕业设计（外文翻译材料）学 院：专 业：学生姓名：指导教师：电气与电子工程学院自动化于小涵季画外文翻译（原文）外文翻译材料格式要求：1. 页边距：上3.8磅；下3.8磅；左3.2，右3.2；页眉距边界2.8，页脚距边界32. 原文题目： Arial，小三；间距：段前18磅，段后12磅，间距21磅3. 原文正文：Times New Roman，小四；间距：段前0磅，段后6磅，间距21磅4. 译文题目：黑体，小三；间距：同原文题目5. 译文正文：宋体，小四；间距同原文正文6. 页眉页脚：原文页眉处写：外文翻译（原文），宋体，五号。译文页眉处写：外文翻译（译文），宋体，五号。原文译文的页脚统一编页码（不要单独编页码）。Plant Model Generation for PLC SimulationHyeong-Tae ParkAbstract:This paper reports an automated procedure for constructing a plant model for PLC simulation. Since PLC programs contain only the control logic without information on the plant model, it is necessary to build the corresponding plant model to perform the simulation. Conventionally, a plant model for PLC simulation has been constructed manually, which requires much effort and indepth knowledge of the simulation. As a remedy for this problem, we propose an automated procedure for generating a plant model from the symbol table of a PLC program. To do so, we propose a naming rule for PLC symbols so that the symbol names include sufficient information on the plant model. By analysing such symbol names, we extract a plant model automatically. The proposed methodology has been implemented and test runs performed.Keywords: agile manufacturing; CAD/CAM; CAPP; simulation1. IntroductionTo survive and prosper in the modern manufacturing era, manufacturers need to continuously improve their products, as well as their production systems. A modern manufacturing line is a highly integrated system composed of automated workstations, such as robots with tool-changing capabilities, a hardware handling system and storage system, and a computer control system that controls the operations of the entire system.Since the implementation of a manufacturing line requires heavy investment, proper verification of a lines operational status should be performed to ensure that the highly automated manufacturing system will successfully achieve the intended benefits. Simulation technology is considered to be an essential tool in the design and analysis of complex systems that cannot be easily described by analytical or mathematical models . Simulation is useful for calculating utilisation statistics, finding bottlenecks, pointing out scheduling errors, and even for creating manufacturing schedules. Traditionally, various simulation languages, including ARENA and AutoMod, have been used for the simulation of manufacturing systems. These simulation languages have been widely accepted both by industry and by academia; however, they remain as analysis tools for the rough design stage of a production line, because their simulation models are not sufficiently realistic to be utilised for a detailed design or for implementation purposes. For example, real production lines are usually controlled by PLC (Programmable Logic Controller) programs (Rullan 1997), but conventional simulation languages roughly describe the control logic with independent entity flows (job flows) between processes.- 22 -Production systems typically consist of simultaneously operating machines, which are controlled by PLCs, currently the most suitable and widely employed industrial control technology. A PLC emulates the behaviour of an electric ladder diagram. As they are sequential machines, to emulate the workings of parallel circuits that respond instantaneously, PLCs use an input/output symbol table and a scanning cycle. When a program is being run in a PLC it is continuously executing a scanning cycle. The program scan solves the Boolean logic related to the information in the input table with that in the output and internal relay tables. In addition, the information in the output and internal relay tables is updated during the program scan. In a PLC, this Boolean logic is typically represented using a graphical language known as a ladder diagram (IEC 2003).Since the abstraction levels of conventional simulators and PLC programs are quite different, the control logic of conventional simulators cannot be reused for the generation of PLC programs. Usually, electrical engineers manually write PLC programs by referring to the rough control logic of conventional simulators, as shown in Figure 1. Since PLC programming is a very tedious and error-prone job, it is essential to verify the PLC programs offline to reduce the stabilisation time of a production system. Previous approaches to a PLC program can be categorised into two groups:(1) verification of a given PLC programand (2) generation of a dependable PLC program. In the first group, various software tools have been developed for the verification of PLC based systems via the use of timed automata, such as UPPAAL2k, KRONOS, Supremica and HyTech, mainly for programs written in a statement list language, also termed Boolean (Manesis and Akantziotis 2005). Such software tools verify PLC programs to a certain extent; however, they remain limited. Since they mainly focus on the checking of theoretical attributes (safety, liveness, and reachability), it is not easy for users to determine whether the PLC programs actually achieve the intended control objectives. In the second group, many researchers have focused on the automatic generation of PLC programs from various formalisms including state diagrams, Petri nets, and IDEF0. These formalisms can help the design process of control logics; however, it is still difficult to find hidden errors, which is the most difficult part of verifying a control program. Figure 2. The concept of PLC simulation.To overcome the aforementioned problems, it is necessary to utilise simulationtechniques for PLC program verification. By simulating PLC programs, it is possible to analyse the control logic in various ways and recognise hidden errors more intuitively (David 1998). Although PLC simulation can be a very powerful tool for the detailed verification of a production system, the accompanying construction of a plant model is a major obstacle (the counterpart model of a control program). Since PLC programs only contain the control information, without device models, it is necessary to build a corresponding plant model to perform simulation, as shown in Figure 2. However, constructing a plant model requires an excessive amount of time and effort. Sometimes, the plant model construction requires much more time than the PLC programming. This serves as the motivation for exploring the possibility of finding an automatic procedure for generating a plant model from a given PLC program. Figure3.Symbol table of a PLC program.Although the objective of a PLC program is not to describe a plant model (device models), the symbol table of a PLC program can provide a glimpse of the plant model. As shown in Figure 3, symbols in a PLC program usually contain some information related to the plant. For example, EXLINE_MB_AGV_P1 means that the symbol is a signal that is related to the control of an AGV (Auto Guided Vehicle) belonging to the MB station of EXLINE line. The above scenario reveals the key idea of the present study. If we can develop a proper naming rule for PLC symbols, then it might be possible to extract a plant model by analysing the symbol names. This paper has two major objectives: (1) to propose a proper naming rule for PLC symbols and (2) to develop a procedure for generating a plant model by analysing the symbol names. The application area of the proposed methodology includes all types of automated manufacturing systems controlled by PLC programs, such as automotive production lines, FMSs (flexible manufacturing systems), and ASRSs (automatic storage and retrieval systems). The overall structure of the paper is as follows. Section 2 addresses the specifications of a plant model for PLC simulation. Section 3 describes a naming rule for PLC symbols, which enables the automatic generation of a plant model. Finally, concluding remarks are given in Section 4.2. Plant model for PLC simulationBefore explaining the specification of a plant model enabling PLC simulation, we want to address the importance of the PLC simulation. Chuang et al. (1999) proposed a procedure for the development of an industrial automated production system that consists of nine steps, as follows: (1) define the process to be controlled; (2) make a sketch of the process operation; (3) create a written sequence of the process; (4) on the sketch, add the sensors needed to carry out the control sequence; (5) add the manual controls needed for the process setup or for operational checks; (6) consider the safety of the operating personnel and make additions and adjustments as needed; (7) add the master stop switches required for a safe shutdown; (8) create a ladder logic diagram that will be used as a basis for thePLC program; and (9) consider the possible points where the process sequence may go astray. The most time-consuming task for the control logic designers is the eighth step, which is usually done by the repetitive method of code writing, testing, and debugging until the control objectives are achieved (Manesis and Akantziotis 2005). This is the reason why conventional PLC programming is often inefficient and prone to human error. As the configurations of production lines and their control programs become more complicated, there is a strong need for a more efficient PLC simulation environment. It is hoped that this paper will take positive steps in this direction.A PLC can be considered as a dedicated computer system having input and outputsignals. To run a PLC, the corresponding plant model (the counterpart system) is required to interact with the input and output of the PLC. The behaviour of the plant model should be the same as that of the actual system to achieve PLC verification. Since a production line consists of various devices, including robots, transporters, jigs, solenoids, proximity sensors, and light sensors (Groover 2006), we can consider a plant model as a set of device models. To build such a device model, this paper employs Zeiglers DEVS (Discrete Event Systems Specifications) formalism (Zeigler 1984, Kim 1994), which supports the specification of discrete event models in a hierarchical, modular manner. The semantics of the formalism are highly compatible with object-oriented specifications for simulation models. We use the atomic model of the DEVS formalism to represent the behavior of a device model. Formally, an atomic model M is specified by a 7-tuple:M =X, S,Y, , ,tX input events setS sequential states setY output events set SS: internal transition functionQ*XS: external transition functionQ=(s, e)s S, 0e t(s): total state of MSY: output functiontSReal: time advance functionThe four elements in the 7-tuple, namely ,and t, are called the characteristic functions of an atomic model. The atomic model of the DEVS formalism can be considered as a timed-FSA (finite state automata), and it is suitable for describing the behaviour of a device model. Once the device models (plant model) are obtained, it becomes possible to perform the PLC simulation. Currently, device models should be construed manually, which takes much time and effort. To cope with the problem, the objective of the paper is to propose an automated generation procedure for device models.Before explaining the automatic generation procedure of a plant model, let us take a look at the manual procedure to construct device models. To construct a device model, first it is necessary to identify the set of tasks that are assigned to the device. The activation of each task is normally triggered by an external signal from PLC programs. Once the set of tasks is identified for a device, it is then possible to extract the state transition diagram, which defines an atomic model of the DEVS formalism. Figure 4(a) shows a simple example of an AGV (Automatic Guided Vehicle) with two tasks, T1 (movement from p1 to p2) and T2 (movement from p2 to p1). As the two tasks should be triggered by external events, the shell part of the AGV must have two input ports, termed here as Signal_1 and Signal_2, as shown in Figure 4(b). From the set of tasks, it is possible to instantiate the state transition diagram. For this example, there are four states, P1, DoT1, P2 and DoT2. While P1 and P2 take external events from the input ports (Signal_1, Signal_2) for state transitions, DoT1 and DoT2 take internal events that are the end events of the two tasks (T1 and T2). The DEVS atomic model of the virtual device, corresponding to the AGV, can be described as follows:Shell of a virtual device:M=X,S,Y, ,t S=P1,DOT1,P2,DOT2 Y=T1Done,T2Done(DOT1)=P2 (DOT2)=P1(P1,Signal_1)=DOT1 (P2,Signal_2)=DOT2(DOT1)=T1Done (DOT2)=T2Donet(DOT1)=Time_1 t(DOT2)=Time_2Once a plant model has been constructed, it is possible to perform the PLC simulation, which enables the intuitive verification of a PLC program. Figure 5 shows the connections between a PLC program and a plant model. The plant model includes all device models of a production system, and the PLC program contains the control logic for the plant model. To integrate the plant model and the PLC program, it is necessary to define the mapping between the plant model and the PLC program, which is described by I/O mapping. To enable the visual verification of a PLC program, it is necessary to import 3D graphic models, which are controlled by the logical device models (the state transition diagrams). Since 3D graphic models are not always necessary, they are optional for PLC simulation. As mentioned already, the objective of this paper is to extract device models from the symbol names of PLC programs. To do so, it is necessary to develop a proper naming rule for PLC symbols. The naming rule will be addressed in the next section.3. Symbol naming for plant model generationAlthough IEC 61131-3 provides various standard specifications for a PLC, the naming rules of PLC symbols have rarely been brought into focus. Since there have been no standard rules for the naming of PLC symbols, it has been fully dependent on individual PLC programmers. To generate device models from PLC symbols, it is necessary to make PLC symbols that include enough information concerning the plant model. To achieve this objective, we interviewed many PLC programmers and analysed various conventional rules. As a result, we came up with a naming structure consisting of five fields: (1) line name, (2) process number, (3) device name, (4) input or output, and (5) task name (or state name). Figure 6 shows the naming structure for PLC symbols. If the PLC symbols are named according to the proposed naming structure, then it becomes possible to extract device models (atomic models of DEVS formalism) by simply analysing the symbol names. There are two types of symbols (signals), input or output, which are specified by the fourth field. The purpose of the output signal is to trigger a task that is specified by the fifth field. Thus, it is possible to identify the set of tasks of a device by analysing the output symbols. As mentioned already, once the set of tasks is identified for a device, it is then possible to extract the state transition diagram for the device model, which defines an atomic model of the DEVS formalism. While an output signal (symbol) is issued by a PLC to trigger a task, an input signal (symbol) is issued by a device to report the completion of the task to the PLC. This means that external transition functionsand internal transition functions of a device model can be automatically extracted from the output and input symbols, respectively. We demonstrate the generation procedure of a plant model from PLC symbols using an example, as shown in Figure 7. In the example cell, we assume a part is loaded manually on the AGV by a worker. When the AGV senses the existence of a part, it moves to transfer the part to the machine. After the transfer, the machine performs machining to convert the part into a finished product. In this case, the plant model consists of two device models: anAGV model and a machine model. The PLC program to control the simple manufacturing cell is shown in Figure 8(a), and its symbol table is shown in Figure 8(b). As shown in Figure 8(b), the AGV model has two output symbols and two inputsymbols. From the output symbols (EX_OP_AGV_O_GOP1, EX_OP_AGV_O_GOP2), we can intuitively recognise that the AGV has two tasks (movement from P2 to P1, and movement from P1 to P2). By using the output symbols, we can extract the state transition diagram, as well as the external transition functions, as shown in Figure 9(a). As mentioned already, an output symbol triggers a task of a device model, andan input symbol is made by the device to notify the completion of the task. Sincethe execution of a task is performed internally by the device, the internal transitionfunctions of a device model can easily be extracted from the input symbols(EX_OP_AGV_I_DONEGOP1, EX_OP_AGV_I_DONEGOP2). In this way, the device model of the machine can be extracted from the related symbols (EX_OP_MC_, etc.), as shown in Figure 9(b). The procedure for the construction of a device model can be described as follows. (1) Identify all corresponding pairs between output symbols and input symbols.While an output symbol triggers a task, the corresponding input symbol reportsthe completion of the task. For example, EX_OP_AGV_O_GOP1 corresponds toEX_OP_AGV_I_DONEGOP1. (2) Define the states of a device mode using the last naming fields of input/output symbols. In the case of the AGV, we can define four states, GoP1, DoneGoP1, GoP2, and DoneGoP2. (3) Define external (internal) transition functions using output (input) symbols. Once a plant model has been obtained, it becomes possible to perform the PLC simula