0
Select Articles

Recon Figureable Logic Control for Manufacturing Systems PUBLIC ACCESS

[+] Author Notes

Dawn M. Tilbury received the B.S. degree in Electrical Engineering from the University of Minnesota in 1989, and the M.S. and Ph.D. degrees in Electrical Engineering and Computer Sciences from the University of California, Berkeley, in 1992 and 1994, respectively. In 1995, she joined the Mechanical Engineering Department at the University of Michigan, Ann Arbor, where she is currently Professor, with a joint appointment as Professor of EECS, and is currently the Associate Dean for Research in the College of Engineering. Her research interests include distributed controlof mechanical systems with network communication, logic control of manufacturing systems, reliability of ground robotics, and dynamic systems modeling of physiological systems. She was elected Fellow of the IEEE in 2008 and Fellow of the ASME in 2012, and is a Life Member of SWE.

Mechanical Engineering 136(12), S16-S23 (Dec 01, 2014) (8 pages) Paper No: ME-14-DEC7; doi: 10.1115/1.2014-Dec-7

This article explores optimistic use of reconfigurable logic control for manufacturing systems. The rapid advancement of computing and networking technologies is enabling more data to be gathered, stored, and analyzed. It is possible for all of the machines in a manufacturing plant to be connected to the Internet of Things (IoT), with their production data stored either in a local database or in a cloud system. This opens up new avenues for online decision-making based on real-time data coming from the system. However, it also introduces significant cybersecurity challenges that will need to be addressed for successful deployment. Traditionally, security in a manufacturing plant was handled through physical separation and access gates with badge identification. Connecting the manufacturing plant to the Internet results in multiple opportunities for improving performance through better data analytics, as well as myriad challenges for safety, security, and privacy.

High-volume discrete manufacturing systems can produce upwards of hundreds of thousands of parts per year. With a single line, that translates into several parts being produced every minute. The total process is broken down into operations that can each be performed at a station – the part must arrive at the station, be fixed, processed, and released within the cycle time. A typical part will go through hundreds of stations from the beginning of the line to the end. At each station, a continuous controller such as a CNC (computer numerical controller) ensures that the part is processed correctly, for example maintaining the feeds and speeds on a machine tool. The logic control coordinates all of the different machines, together with the material handling systems (e.g., conveyors, gantries, or robots) and interfaces with the human operator. A high-level view of a manufacturing system is shown in Figure 1, with raw materials arriving and processed materials (finished parts) leaving. The logic controller sends inputs to the machines based on the values of the sensors and the operator commands.

Figure 1 The logic controller sends commands to the machines based on the sensor feedback and operator input

Grahic Jump LocationFigure 1 The logic controller sends commands to the machines based on the sensor feedback and operator input

In a typical discrete manufacturing plant, there are dozens of PLCs (programmable logic controllers). Each PLC coordinates the stations and material handling within a physical region of the plant. It may interface to an RFID (radiofrequency identification) system that keeps track of which part is where, and what processes each part has gone through. The RFID tag may also be used to track quality inspections of the parts. It is not uncommon for a single PLC to be associated with several thousand I/O (input-output) points – these discrete I/O are mostly binary (on/off) sensors and actuators, and can include limit switches, proximity sensors, flow sensors, hydraulic valves, and motors. Although continuous controllers are used to control the speed of motors, logic controllers often interface with these motor controllers to turn them on or off, and to set the reference speeds, etc.

Logic control can be thought of as a rule-base, a set of “if-then” statements. “If the proximity sensor indicates a part has arrived, and the RFID tag indicates it is part type 2, then tell the gantry to move the part into machine 3.” Each of these statements is quite simple; the complexity arises when there are thousands of statements, and possibly conflicting rules.

In the automatic mode, the logic controller keeps the system operating automatically. As long as parts are entering the system, and there are no errors, the logic controller keeps the parts moving between the machines via the material handling systems. The logic controller is also responsible for detecting and handling errors, and interfacing with the operator to help the system recover from these errors. The complexity associated with the error-handling modes of a logic controller is considerable. Logic controllers also interface with the safety system in a plant. For example, when a safety gate is open, certain operations are prohibited, but others may be necessary for troubleshooting.

The operator interacts with the logic controller through an HMI (human-machine interface). There are often buttons to push (either manually or via a touchscreen), to start or stop the system as a whole, or to step through a manual mode of operation. The manual mode is useful for debugging, when the operator wants the system to go one step at a time, instead of automatically. In the manual mode, the operator must push a button for each operation to occur – in effect, it adds an additional “and” condition to each logical statement.

Logic controllers can be written in many different languages. Most logic controllers implemented on PLCs are written in one of the standard languages from the IEC (International Electrotechnical Commission). More formal languages for logic controllers have also been considered to enable verification of certain logical properties.

2.1 Industry Standards: IEC 61131 and 61499

The IEC 61131-3 standard brings together the most common programming languages into a single standard, and defines data types, variables, and how programs are written and executed on PLCs [1]. In the US, Ladder Diagram (also called Ladder Logic) is a popular logic control language. This language is based on the previous practice of hard-wiring the logic to control manufacturing systems using electro-mechanical relays. It can be understood by electricians, and if an output is not enabled, it is very easy to find the correct rung in the ladder and see which inputs are prohibiting the output. For example, in Figure 2, Output C1 is on if either Xfer or S2 are true, and S1 is true. Note that after C1 turns on, it is ‘latched’ so that Xfer and S2 can turn off, and C1 remains on (S1 must remain on).

Figure 2 Ladder Logic

Grahic Jump LocationFigure 2 Ladder Logic

The other four programming languages are also widely used. SFC (Sequential Function Chart) is similar to a flow chart, with steps that define the actions and transitions that define decision points. It is based on Petri nets which will be discussed below. Structured Text is a textual language, using if-then-else rules to encode logic. Instruction List is a low-level textual language, similar to assembly language. Function Block Diagram (FBD) encapsulates the logic in a function block, with well-defined inputs and outputs.

Many PLC programming environments support more than one language, and even mixing of multiple languages in one program. For example, any of the other languages can be encapsulated in a function block.

The distributed control standard IEC 61499 is based on function blocks [2]. Each function block has two types of inputs (events and data), an execution control chart (ECC), and a set of algorithms written in one of the 61131 languages. Input events can trigger a change of state of the ECC, execution of one or more of the algorithms, and generation of output events and/or data. Function blocks can be combined by connecting the outputs of one to the input of another in a network arrangement.

2.2 Formal Methods

In recent years, many academic groups have considered the problem of developing logic controllers that can be verified as correct, according to some specification. The formalism of Discrete Event Systems (DES) is used, in which the system evolution is defined according to the occurrence of instantaneous discrete events. Examples of such events include the push of a button by the operator, the tripping of a limit switch, or the turning on of a machine. These events occur at discrete moments in time, instead of over some time interval, and can either be inputs or outputs. Sometimes the events are classified as controllable or uncontrollable, where actuators are controllable and disturbances and sensors are uncontrollable (from the point of view of the control designer).

The most general way to describe a discrete event system is through its language, which is the set of strings (ordered sets of events) that the system can generate. Although general, languages are typically made up of infinite sets and can be difficult to work with. The two most commonly used DES approaches for logic control development are Finite State Machines (FSM) and Petri nets.

A finite state machine is a quintuple, S = {X, Σ, α, x0, Xm } where X is a finite set of discrete states, Σ is the set of discrete events, α:X×ΣX is the transition function. α(x1, σ1)=x2 indicates that if the system is in state x1 and event o1 occurs, then the system will transition to state x2. Note that the transition function is rarely complete: not every event can occur in every state of the system. x0 is the initial state of the system, and Xm is a set of marked states. A simple finite state machine representing a clamp is shown in Figure 3. The states X={x1,x2,x3,x4} are shown in black, and indicate whether the clamp is open, closing, closed, or opening. The events σ12 in blue are used to command the clamp to close or open, and the events γ12 in red represent limit switches that indicate whether the clamp has closed or opened completely. The transition function a is indicated in Table 1.

Figure 3 A simple finite state machine with 4 states (in black), 2 controllable events (blue) representing outputs and 2 uncontrollable events (red) representing inputs.

Grahic Jump LocationFigure 3 A simple finite state machine with 4 states (in black), 2 controllable events (blue) representing outputs and 2 uncontrollable events (red) representing inputs.

At a low level, finite state machines are relatively simple and easy to understand, as shown above. Multiple FSM can be combined through parallel composition. The combined set of states is the cross-product of the states in each individual FSM, and the set of events is the union of the sets of events. Taking the combination of three FSM each with 4 states and 4 events leads to a new FSM with 43=64 states and 12 events. This exponential increase in the number of states leads to the “state explosion” property for large systems. Techniques have been developed to reduce the number of states, but in general, large combined systems can quickly become unwieldy.

A Petri net is represented as a bipartate graph, with two types of nodes: places (circles) and transitions (bars). Nodes are connected by arcs, which can have weights (in ordinary Petri nets, all of the weights are equal to one). The marking of a Petri net assigns a non-negative integer to each place, indicated by a number of tokens (dots) shown in the circle. A transition leaving a place is enabled if there are at least as many tokens in the place as the weighting of the arc. When the transition fires, the number of tokens indicated by the weight are removed from the input place and added to the output place.

A firing sequence of an ordinary Petri net is shown in Figure 4. Here, the places model operations, with the active operation indicated by a token. Transitions model events, which transition the system from one operation state to another. Note that this Petri net exhibits both concurrency (with two operations happening simultaneously) and synchronization (since unclamp will not start until both drill on and drill retract have finished).

Figure 4 Evolution of a simple Petri net

Grahic Jump LocationFigure 4 Evolution of a simple Petri net

Petri nets can be used as analysis tools for event-based systems that are concurrent, synchronized and distributed. They can be used to verify three key properties of a discrete-event system: Liveness (avoidance of deadlock), safeness (no request of ongoing operations), and reversibility (ability to return to the initial state). Safe Petri nets can be directly translated into SFC, one of the IEC 61131-3 languages for logic control, as discussed in Section 2.1.

A logic control programmer typically starts from the mechanical definition of the system and the tasks that must be performed. In current industry practice, it is uncommon for a formal specification (written in a mathematical language) to be used. Many logic control programmers have only a high-school degree plus significant on-the-job experience [3]. Much of the programming work that is done is based on experience, and most programs are based on a previously-written program for a similar system. Some proprietary company standards exist from which pre-defined logic blocks can be put together to create a logic program.

3.1 Supervisory Control Theory

Supervisory control theory is a formal method based on finite state machines that can be used for control [4, 5]. The events in an FSM are divided into and uncontrollable events. The key idea is that the controller disables controllable events that could lead the system into an undesirable state (uncontrollable events cannot be disabled). Techniques exist to design supervisors that are optimal in the sense that they are maximally permissive – they do not unnecessarily restrict the behavior of the system while guaranteeing that it does not enter any undesirable states.

The application of supervisory control theory requires a detailed behavior-based model of the manufacturing system, as well as a formal model of the desired behavior (expressed as an FSM), which typically does not exist in current practice. Creating such models can be timeconsuming, and require significant effort. In addition, since the supervisory control theory only disables events, it is not directly adapted to implementable logic control that must send commands to turn on motors, etc. Additional constructs such as forced events have been added to apply supervisory control theory to logic control for manufacturing systems.

Computational complexity also becomes an issue with large-scale systems. If sufficient formal models exist for a manufacturing system, modular and hierarchical approaches can be applied to develop supervisors that satisfy the specification and are guaranteed to be correct by construction. In one approach, the global system is decomposed into modules and interfaces are introduced between the modules to restrict interaction. These interfaces allow global properties to be verified by local analysis – each module only needs to be composed with its neighbor [6].

Andersson et al. use supervisory control theory to develop cell-level controllers [7]. To avoid the state explosion problem, they use a hierarchical approach, where the interactions between components are specified by the coordination of operations, and the low-level control (within a component) is specified by the execution of operation. Supervisory control theory is applied to define a supervisor over the coordination of operations, and after this has been accomplished, an extraction algorithm is applied to result in an easy-to-read control format that can be implemented on a PLC. The method has been applied to a manufacturing cell at Volvo in Sweden.

3.2 Modular Finite State Machines

Modular finite state machines (MFSMs) are a low-level logic control language built on the concept of FSM [8]. In contrast to standard FSMs, which are just defined by a set of events, each module of an MFSM has a set of input events and output events, called triggers and responses. Triggers come from the environment, cause a change in state, and then responses are sent. The responses can go to another module (becoming a trigger), causing another state change and response, and so on, until the final responses are sent to the environment. With the modular nature, the logic can execute across several modules, and a single trigger can generate multiple responses.

MFSMs were designed to be verifiable from an input-output point of view. They rely on the idea of assume-guarantee. Each connection point of an MFSM has a set of trigger and response events, and a specific language that it generates. If the logic within the module is consistent with all of the interfaces, then the composed system can be verified in a modular fashion, avoiding the state-explosion property.

A sample of a single MFSM module is shown in Figure 5. The module starts in the initial state (Idle), indicated by the bold oval. The only trigger that is defined to occur in this state is rise (signifying a button press that causes a voltage to increase), coming from interface U.1. When this trigger event occurs, the MFSM transitions to the Working state, and the start response is sent out through the interface U.2. There are two different ways that the MFSM can transition back to Idle — either the binary signal on U.1 can fall (in which case a stop response is issued through U.2), or a done trigger can be received through U.2.

Figure 5 A single module of an MFSM, with two interconnections – one to the environment (a binary signal that can rise or fall) and the other to another module.

Grahic Jump LocationFigure 5 A single module of an MFSM, with two interconnections – one to the environment (a binary signal that can rise or fall) and the other to another module.

MFSMs can also be written in an Event-Condition-Action (ECA) formalism [9], inspired by work in active databases. All of the triggers from the environment come into a Main module, which has only one persistent state (Idle). Peripheral modules keep track of the state of the system. Depending on the trigger and the current state, responses are generated to the environment and the internal state is updated. A simple ECA-MFSM is shown in Figure 6. The environment consists of the button, the light, and the robot. When the button is pressed (2.rise), the logic checks the state of the robot. If the robot is already working, nothing happens. If the state of the robot is currently idle, the light is turned on and the robot is commanded to start. When the robot signals that it is finished (4.done), then the button is turned off and the robot state is updated to indicate it is now idle. The logic control tracking the state of the physical system is quite common (here, the logic tracks the state of the robot, idle or working), and can add significantly to the complexity of the logic control.

Figure 6 A simple logic controller written as an ECA-MFSM

Grahic Jump LocationFigure 6 A simple logic controller written as an ECA-MFSM

3.3 Model-Based Design

Henry et al. have developed a method to design logic controllers for automated manufacturing systems using the concept of operations [10]. This approach requires a detailed formal model of the system to be controlled, expressed in a formal language. Operations have conditions, effects, and constraints, and have associated resources and products. For example, an operation might consist of extending a cylinder, using the resource of the cylinder and a product that is moved from one location to another through the action of extension. A very detailed model of this operation is used to capture all of the conditions and constraints that must be satisfied for it to occur. However, once all of these models are available, a controller can be constructed by concatenating these operations using a graph search.

Valente et al. have proposed a holistic approach to logic control design, starting with an analysis of the production system and policies at a conceptual level [11]. A model is developed for each module of the system, including its interaction with other modules, as well as its capability for reconfiguration, using finite state machines. These models are then translated into executable control code, and evaluated for robustness through hardware-in-the-loop and software-in-the-loop simulation. The approach has been applied to a shoe manufacturing process in Italy.

4 Validation and Testing of Logic Controllers

As discussed above, some methods for developing logic controllers can be formally verified. Some approaches can check the code for internal correctness. If a model of the system and environment is available, the performance of the controller when connected to the environment can be verified. Since formal models are not always available, extensive testing of the controller is often required. Re-use of existing code from previous projects can reduce the amount of testing required.

4.1 Anomaly Detection

Even well-written logic controllers often have some bugs, and detecting these can be challenging, especially when the bugs are intermittent and do not trigger a fault, but rather just cause incorrect behavior. We developed a method for detecting these anomalies – out-of-the-ordinary behavior of a logic controller that doesn’t cause a fault [12]. A high-level view is shown in Figure 7. Our method requires observing the entire stream of events (inputs and outputs) coming through a system, and uses this event stream to build a model.

Figure 7 Detecting anomalies through observation of event streams

Grahic Jump LocationFigure 7 Detecting anomalies through observation of event streams

The key idea is that the anomaly detection system does not interfere with the normal operation of the plant. It only observes events that are sent between controllers, sensors, and actuators. It uses these streams of events to automatically build Petri net models of the synchronous system operation. The only information that is required to build these models is information about what are the shared resources in the system (and their capacities), and which events acquire and release these shared resources. From this information, and two sets of event streams that are labeled as normal and anomalous, the method automatically builds a set of Petri net models that capture the system operation. Since it may be impossible to know exactly the plant model just from the observed behavior, we use a set of models that capture some aspects of the behavior. Based on how well a new stream of data can be accepted by this set of Petri net models, it is classified as either normal or anomalous.

The method was applied to manufacturing process at an engine manufacturer [13]. In a system with two gantries feeding six machine tools, occasionally one of the gantries picked up a new part, at least one machine was available to process it, but the gantry waited for an unknown reason. Eventually the part was delivered to a machine, but productivity was being lost. We used data recorded from almost 1000 parts, including more than 40,000 messages from the six PLCs (each with up to 40 words of data).

From these raw PLC logs, events were extracted for each gantry and events were extracted for each gantry and CNC to build the formal models. The anomaly detection system was able to identify the specific sequence of events that led to the lost production, enabling the PLC programs to be revised to eliminate this condition.

TESTBED: RFT

Much of the Research Described in this Article has been inspired by and implemented on the Reconfigurable Factory Testbed (RFT). This testbed was constructed as part of the Engineering Research Center for Reconfigurable Manufacturing Systems at the University of Michigan, and has been extended and expanded over the years as the research evolved.

The current testbed includes three industrial-scale robots (two Fanuc and one ABB) and four Denford CNC milling machines, connected by a conveyor system [16, 17]. Parts go through the system on pallets, are read by RFID tags, and are put into and out of the machines by the robots. The robots can also do some assembly (pick and place).

Figure 10 shows a schematic of the testbed. Recently, in a partnership with Rockwell Automation, the existing physical testbed has been retrofitted with a single network (Ethernet I/P) replacing a plethora of networks (DeviceNet, Profibus, Bluetooth, WISA, etc.), and a single system-level controller and HMI (ControlLogix) replacing a hierarchy of several research-grade cell- and system-level controllers.

4.2 Hybrid Process Simulation

To facilitate product launch with shorter times and lower costs, We have developed the concept of hybrid process simulation (HPS) [14]. HPS is a formalized methodology for applying the Hardware in the Loop (HIL) approach with multiple real and simulated components. HIL combines simulated and actual machines, leveraging the strengths of simulation (for well-known processes) while also reducing the drawbacks that come from potentially large inaccuracies in simulation models (for less-well known processes). Simulation enables better decision making in planning and more accurate performance analysis in the early development stages. System and component simulation models, however, do not always exist, and even with a model, a highly complex control system cannot be fully validated until it is tested against the actual system.

Integration of simulation is more accurate, since it includes the same components that will be used in the final process. Testing with real components makes inaccurate and unavailable models less of an issue and reduces process setup time, thereby reducing the overall cost of deployment. The HPS approach starts with a pure simulation model, and then progresses to a “hard-wired” simulation model – in which all of the machines, robots, material handling devices are simulated, but all of the controllers, networks, and databases are real. See Figure 8. The physical parts of the system are then replaced one at a time, allowing for incremental validation of the cell controllers and system-wide performance, until the entire system is realized in its final, physical form, as shown in Figure 9.

Figure 8 Schematic of a hardwired simulation, where the robot simulations are supplied by the vendor (Fanuc), the conveyor simulation is built using an open-source software, and the controllers and networks are in their final, physical form.

Grahic Jump LocationFigure 8 Schematic of a hardwired simulation, where the robot simulations are supplied by the vendor (Fanuc), the conveyor simulation is built using an open-source software, and the controllers and networks are in their final, physical form.

Figure 9 The physical system, with two Fanuc robots and a conveyor, and a Cell Controller.

Grahic Jump LocationFigure 9 The physical system, with two Fanuc robots and a conveyor, and a Cell Controller.

Figure 10 Testbed at University of Michigan, including robots, machines, conveyor.

Grahic Jump LocationFigure 10 Testbed at University of Michigan, including robots, machines, conveyor.

There remains a lot of opportunity for research in the area of reconfigurable logic control for manufacturing systems. Many logic programs are still written as they were decades ago; progress is slow in this area. Although manufacturing is a high-volume enterprise, the manufacturing systems themselves are low-volume — a large company may only build or reconfigure a handful of plants in any given year, and systems can run continuously for a decade or longer. Thus, the legacy issues are significant, and can be a barrier to large-scale changes.

On the other hand, the rapid advancement of computing and networking technologies is enabling more data to be gathered, stored, and analyzed. It is possible for all of the machines in a manufacturing plant to be connected to the Internet of Things (IoT) [15], with their production data stored either in a local database or in a cloud system. This opens up new avenues for on-line decision making based on real-time data coming from the system. However, it also introduces significant cybersecurity challenges that will need to be addressed for successful deployment. Traditionally, security in a manufacturing plant was handled through physical separation and access gates with badge identification. Connecting the manufacturing plant to the internet results in multiple opportunities for improving performance through better data analytics, as well as myriad challenges for safety, security and privacy.

was introduced to the challenging problems in logic control for large-scale manufacturing systems through the NSF Engineering Research Center for Reconfigurable Manufacturing Systems, directed by Prof. Yoram Koren, and co-directed by Prof. Galip Ulsoy. Thanks are due to the many students who worked on these research problems with me over the years, including Lindsay Allen, Emanuel Almeida, Eric Endsley, William Harrison, Rick Hill, Seungjoo Lee, Mory Lucas, and Euisu Park. We had excellent relationships with our industry partners at Ford, GM, Lamb Technicon, Rockwell, Siemens, and many others.

Lewis, R. W., 1998. Programming Industrial Control Systems Using IEC 61131-3 Revised Edition. The Institution of Electrical Engineers.
Lewis, R. W., 2001. Modelling Control Systems Using IEC61499: Applying Function Blocks to Distributed Systems. Institution of Electrical Engineers, London. [CrossRef]
Lucas, M. R., and Tilbury, D. M., 2003.“A study of current logic design practices in the automotive industry”. International Journal of Human-Computer Studies, 59(5), pp. 725-753. [CrossRef]
Ramadge, P. J. G., and Wonham, W. M., 1989. “The control of discrete event systems”. Proceedings of the IEEE, 77(1), January, pp. 81-98. [CrossRef]
Cassandras, C. G., and Lafortune, S. L., 2007. Introduction to Discrete Event Systems, 2nd ed. Springer. [PubMed] [PubMed]
Hill, R. C., Cury, J. E. R., de Queiroz, M. H., Tilbury, D. M., and Lafortune, S., 2010.“Multiple-level hierarchical interface-based supervisory control”. Automatica, 46(7), July, pp. 1152-1164. [CrossRef]
Andersson, K., Richardsson, J., Lennartson, B., and Fabian, M., 2010.“Coordi- nation of operations by relation extraction for manufacturing cell controllers”. IEEE Transactions on Automation Science and Engineering, 18(2), pp. 414-429.
Endsley, E. W., Almeida, E. E., and Tilbury, D. M., 2006. “Modular finite state machines: Development and application to reconfigurable manufacturing cell controller generation”. Control Engineering Practice, 14(10), October, pp. 1127-1142. [CrossRef]
Almeida, E. E., Luntz, J. E., and Tilbury, D. M., 2007.“Event condition action systems for reconfigurable logic control”. IEEE Transactions on Automation Science and Engineering, 4(2), pp. 167-181. [CrossRef]
Henry, S., Zamaï, E., and Jacomino, M., 2012. “Logic control law design for automated manufacturing systems” Engineering Applications of Artificial Intelligence, 25, pp. 824-836. [CrossRef]
Valente, A., Mazzolini, M., and Carpanzano, E., 2014. “An approach to design and develop reconfigurable control software for highly automated production systems”. International Journal of Computer Integrated Manufacturing.
Allen, L. V., and Tilbury, D. M., 2012. “Anomaly detection using model generation for event-based systems without a pre-existing formal model”. IEEE Transactions on Systems, Man, and Cybernetics—Part A, Systems and Humans, 42(3), May, pp. 654-668. [CrossRef]
Broderick, J. A., Allen, L. V., and Tilbury, D. M., 2011.“Anomaly detection without a pre-existing formal model: Application to an industrial manufacturing system”. In Proceedings of the IEEE Conference on Automation Science and Engineering (CASE).
Harrison, W. S., Tilbury, D. M., and Yuan, C., 2012. “From hardware-in-the-loop to hybrid process simulation: An ontology for the implementation phase of a manufacturing system”. IEEE Transactions on Automation Science and Engineering, 9(1), January, pp. 96-109. [CrossRef]
Giusto, D., Iera, A., Morabito, G., and Atzori, L., eds., 2010. The Internet of Things. Springer. [CrossRef]
Moyne, J., Korsakas, J., and Tilbury, D. M., 2004.“Reconfigurable factory testbed (RFT): A distributed testbed for reconfigurable manufacturing systems”. In Proceedings of the Japan-USA Symposium on Flexible Automation, American Society of Mechanical Engineers (ASME).
Luntz, J. E., Moyne, J. R., and Tilbury, D. M., 2005.“On-line control reconfiguration at the machine and cell levels: Case studies from the reconfigurable factory testbed”. In Proceedings of the IEEE Conference on Emerging Technologies and Factory Automation, Vol. 1, pp. 641-648.
Copyright © 2014 by ASME
View article in PDF format.

References

Lewis, R. W., 1998. Programming Industrial Control Systems Using IEC 61131-3 Revised Edition. The Institution of Electrical Engineers.
Lewis, R. W., 2001. Modelling Control Systems Using IEC61499: Applying Function Blocks to Distributed Systems. Institution of Electrical Engineers, London. [CrossRef]
Lucas, M. R., and Tilbury, D. M., 2003.“A study of current logic design practices in the automotive industry”. International Journal of Human-Computer Studies, 59(5), pp. 725-753. [CrossRef]
Ramadge, P. J. G., and Wonham, W. M., 1989. “The control of discrete event systems”. Proceedings of the IEEE, 77(1), January, pp. 81-98. [CrossRef]
Cassandras, C. G., and Lafortune, S. L., 2007. Introduction to Discrete Event Systems, 2nd ed. Springer. [PubMed] [PubMed]
Hill, R. C., Cury, J. E. R., de Queiroz, M. H., Tilbury, D. M., and Lafortune, S., 2010.“Multiple-level hierarchical interface-based supervisory control”. Automatica, 46(7), July, pp. 1152-1164. [CrossRef]
Andersson, K., Richardsson, J., Lennartson, B., and Fabian, M., 2010.“Coordi- nation of operations by relation extraction for manufacturing cell controllers”. IEEE Transactions on Automation Science and Engineering, 18(2), pp. 414-429.
Endsley, E. W., Almeida, E. E., and Tilbury, D. M., 2006. “Modular finite state machines: Development and application to reconfigurable manufacturing cell controller generation”. Control Engineering Practice, 14(10), October, pp. 1127-1142. [CrossRef]
Almeida, E. E., Luntz, J. E., and Tilbury, D. M., 2007.“Event condition action systems for reconfigurable logic control”. IEEE Transactions on Automation Science and Engineering, 4(2), pp. 167-181. [CrossRef]
Henry, S., Zamaï, E., and Jacomino, M., 2012. “Logic control law design for automated manufacturing systems” Engineering Applications of Artificial Intelligence, 25, pp. 824-836. [CrossRef]
Valente, A., Mazzolini, M., and Carpanzano, E., 2014. “An approach to design and develop reconfigurable control software for highly automated production systems”. International Journal of Computer Integrated Manufacturing.
Allen, L. V., and Tilbury, D. M., 2012. “Anomaly detection using model generation for event-based systems without a pre-existing formal model”. IEEE Transactions on Systems, Man, and Cybernetics—Part A, Systems and Humans, 42(3), May, pp. 654-668. [CrossRef]
Broderick, J. A., Allen, L. V., and Tilbury, D. M., 2011.“Anomaly detection without a pre-existing formal model: Application to an industrial manufacturing system”. In Proceedings of the IEEE Conference on Automation Science and Engineering (CASE).
Harrison, W. S., Tilbury, D. M., and Yuan, C., 2012. “From hardware-in-the-loop to hybrid process simulation: An ontology for the implementation phase of a manufacturing system”. IEEE Transactions on Automation Science and Engineering, 9(1), January, pp. 96-109. [CrossRef]
Giusto, D., Iera, A., Morabito, G., and Atzori, L., eds., 2010. The Internet of Things. Springer. [CrossRef]
Moyne, J., Korsakas, J., and Tilbury, D. M., 2004.“Reconfigurable factory testbed (RFT): A distributed testbed for reconfigurable manufacturing systems”. In Proceedings of the Japan-USA Symposium on Flexible Automation, American Society of Mechanical Engineers (ASME).
Luntz, J. E., Moyne, J. R., and Tilbury, D. M., 2005.“On-line control reconfiguration at the machine and cell levels: Case studies from the reconfigurable factory testbed”. In Proceedings of the IEEE Conference on Emerging Technologies and Factory Automation, Vol. 1, pp. 641-648.

Figures

Tables

Table Grahic Jump Location
Table 1 The state transition function a for the finite state machine in Figure 3.

Errata

Some tools below are only available to our subscribers or users with an online account.

Related Content

Customize your page view by dragging and repositioning the boxes below.

Related Journal Articles
Related eBook Content
Topic Collections

Sorry! You do not have access to this content. For assistance or to subscribe, please contact us:

  • TELEPHONE: 1-800-843-2763 (Toll-free in the USA)
  • EMAIL: asmedigitalcollection@asme.org
Sign In