KR20060125594A - Model for communication between manufacturing and enterprise levels - Google Patents

Abstract

A communication model between a manufacturing and enterprise level is provided to offer capability for directly controlling/modifying a manufacturing process, and offer effect for capturing data and identifying each event generated in a plant floor. An enterprise communication controller(500) performs communication with a controlling/monitoring device by connecting to the network and includes embedded software. The software reads the data from the controlling/monitoring device, receives a non-claim message from the controlling/monitoring device, and transmits the data and the message to a receiving place by connecting to the network. The controlling/monitoring device is a PLC(Programmable Logic Circuit) and the data is a discrete data point read from the PLC.

Description

MODEL FOR COMMUNICATION BETWEEN MANUFACTURING AND ENTERPRISE LEVELS}

Figure 1 shows the structure of a prior art standard from low level to enterprise level.

2 shows the functions necessary for the operation of the present invention.

3 shows a high level structure of the device according to the invention.

4 shows a high level diagram of the structure of a workbench component according to the present invention.

5 illustrates a system component of an enterprise communication controller.

6 shows a process in which a project and a trigger are added.

7 illustrates the functionality of an enterprise communication controller based on run-time data triggers.

8 illustrates the functionality of an enterprise communication controller based on run-time logic trigger.

9 shows the function of the enterprise communication controller after a power failure.

Fig. 10 shows the function of the enterprise communication controller when the connection between the low level and the enterprise level is accidentally released and the storage and next functions are activated.

11 illustrates the operation of a watchdog facility or a system health monitor.

12 illustrates the operation of exporting a configuration.

Figure 13 shows an alternative embodiment for a direct connection to a further external device.

14 shows an alternative embodiment for connection to multiple PLS via a PLC communication channel.

Figure 15 shows an alternative embodiment for connecting to multiple PLCs using device drivers.

16 illustrates a PLC for which a write back event is requested.

17 illustrates an enterprise for which a write back event is requested.

18 shows an alternative embodiment in which a PC with device drivers is used in place of an enterprise communication controller.

Figure 19 illustrates the logic of configuring a user level application and the logic server subsystem of the enterprise communication controller.

Figure 20 illustrates a pieceplay server subsystem of a user level viewer application and an enterprise communications controller.

Figure 21 illustrates an expression server subsystem of a user level expression composer application and an enterprise communication controller.

The present invention relates to a communication model between manufacturing and enterprise level.

In equipment manufacturing, it is common to find automated processes controlled by low level automation, process control, and monitoring systems. The low level automation system may include, for example, a dedicated robotic device or other automated system controlled or monitored by a programmable logic controller. Various sensing devices and instruments may be used in monitor processes such as photo eye barcode readers, and temperature sensors. In order to operate the overly complex manufacturing and assembly systems used in recent years, many enterprises use multiple structures, such as the example of the prior art shown in FIG. Conventional multi-structures include enterprise level business planning system (enterprise resource planning, or ERP) 102; Operation level (manufacturing execution system, or MES) 104; Mid-level process optimization system 106 (eg, human machine interface (HMI), surveillance control data collection system (SCADA), viewable plant floor status, data collection for upstream reporting); And a low level process automation or control system 108 that includes a detector or other instrument 110.

Most consumers may find it difficult to install and maintain if the number of systems required to implement the mid level control system 106 is large. The mid level control system 106 is often only a very complex, for example, a small manufacturing resource planning (MRP) system for planning, but too simple and limited in functionality, for example, SCADA / HMI data status. In addition, there is a division typically responsible for standard computer information technology (IT) equipment between the IT support group and the plant floor support group.

Often, it is desirable to have the right to directly access information currently available only on the plant floor, such as, for example, the number of units read or generated by the detector at ERP level 102. A major stumbling block in achieving a direct connection between an enterprise level system and a plant floor device is that it has its own non-standard communication protocol in the devices used on the plant floor. Standard communication mechanisms (e.g., message queues) at the enterprise level 102 differ from standard communication mechanisms (e.g., DeviceNet and other proprietary protocols) at the low level manufacturing device levels 108, 110. There is a difference. In addition, many layers between the ERP level 102 and the controller and detectors 108 and 110 are each easy to communicate directly between these different levels.

Thus, it is desirable to have a means of directly communicating between low level control and sensing levels 108 and 110 and enterprise level 102 in order to be able to collect data directly from the manufacturing floor and directly control the manufacturing process.

The present invention not only provides the ability to directly control and modify the manufacturing process but also provides a means of capturing data and identifying individual events occurring on the plant floor. The identified individual is typically at the enterprise level 102 of the organization. You must have the following capabilities to allow the collection of data: First, an entity at enterprise level 102 should have the ability to identify data of interest. The entity at enterprise level 102 should then be able to identify the circumstances in which it wishes to receive data updates. Finally, data needs to be transferred from the plant floor to a specific place at an enterprise level 102, such as a database or enterprise level application. This step is shown in FIG. In box 50, the user must select data to be sent from the low level to the enterprise level. In box 52, the user must determine the data to be transmitted at any time and in any condition. Finally, in box 54, the user specifies the destination of the data.

The high level view system of the present invention is shown in FIG. The main part of the system is, in a preferred embodiment, a functional microcomputer plugged into the same backplane 202 as the PLC 204 on the plant floor that controls the manufacturing process and collects data through the detector. Enterprise communication controller 500. The enterprise communication controller 500 must represent the original protocols of all manufacturers' PLCs that are currently being monitored because the PLCs communicate with the PLCs via the inserted backplane 202. The enterprise communication controller 500 will run a real-time operating system such as, for example, Windows CE, VX Works, QNX, or embedded Monta Vista Linux, and not only can read data from or write data to the PCL, but also from the PLC. You will have installed software components that facilitate the selection and transfer of data at the enterprise level. In addition, enterprise communication controller 500 will link to a higher level of organization such as workbench client and enterprise level 600 via standard Ethernet protocols. Workbench 810 is a software component that typically runs within a intranet or at a client location on a desktop that remotely crosses any network and is used to configure a software component of the enterprise communications controller 500. The workbench 810 is the destination of data within the enterprise level 600, such as data that the user is interested in, events that initiate data transfer from the enterprise communication controller 500 to the enterprise level 600, and database applications 602. Have them identify and name them. Enterprise level 600 generally consists of databases and business applications commonly used by companies for the operation of an organization. Certain pieces of data flow, for example, directly from the enterprise communication controller 500 to a particular database 602 at the enterprise level 600 or to an application 602 running at the enterprise level 600 via various network protocols. Can be

The above advantages and other features of the present invention will become apparent from the following detailed description of the preferred embodiments of the invention as shown in the accompanying drawings, in which like, functionally similar and / or structurally similar elements are referred to throughout the same reference numerals. Represented by

The model of the present invention is described in detail below. In discussing particular example embodiments, it is to be understood that this is for illustration only. Those skilled in the art will recognize that other components and structures may be used without departing from the spirit and scope of the invention.

An exemplary embodiment of the present invention uses a two-layer structure to perform communication between the enterprise level 600 and the plant floor. This structure may be used in place of or in addition to the typical prior art multi-structure of the type shown in FIG.

Enterprise communication controller 500 is an essential part of the present invention and connects to one or more existing PLCs and forms a connection between upstream enterprise system 602 and PLC devices such as databases and applications. In an exemplary embodiment, the present invention provides the ability to have information such as, for example, the number of defects, product completion and product rework, or progressive levels available directly to the enterprise level system 602. The present invention provides tight connectivity, high integration, modules, and component-based mechanisms to provide information directly from the control domain to the enterprise through a combination of hardware components and software modules for interfacing to the higher level enterprise system 602.

In addition, the enterprise communication controller 500 may obtain information from the enterprise level 600 and update the condition of any one connected PLC. This "light-back" characteristic can be used to change product activation based on input from enterprise level 600.

In addition, enterprise communication controller 500 may retrieve data from the enterprise level and locate it on a PLC controller for use in production. This information is initiated by a change in state on the enterprise communication controller 500 and can be used to collect recipes for use in production.

In a typical embodiment of the present invention, the user may configure a system to move data from the factory floor to the enterprise level 600 as shown in FIG. In block 52 the user selects the data to be collected, limits the results of the data transmitted in block 52, and defines where the data should be transmitted in block 54. The functionality described in blocks 50, 52, and 54 of FIG. 2 is provided to the workbench component shown in FIG. 3 using the concept of a project as shown in FIG.

Project 620 is a group of triggers that define the results that cause some of the data named tag 624 to be sent to enterprise level 600 as shown in FIG. 3. Trigger 622 may be viewed as a predetermined response of the result occurring at the factory floor. When the result occurs, the response is configured to initialize a function, such as writing or updating a row of data to a database table, putting a message 626 into the message queue, or sending an email. The result is that the trigger to perform causes a predetermined state (data trigger) or the receipt of a spontaneous message from the PLC (logical trigger).

The tag 624 is merely a method of identifying any data point in the PLC in a more intimate manner, eg, "manufacture count" instead of "data point 12 on PLC 2".

A data trigger is a trigger that is performed as a result of a state of state that includes any data point read from the PLC. For example, a data trigger is performed periodically at a set frequency, at a predetermined time, or as a result of a change in a data point, for example, if it is determined that a data point changes or is greater, smaller or equivalent to a value something to do.

Logic triggers occur as a result of spontaneous receipt of messages through the backplane 202 from the ladder logic of the PLC. For example, a state occurs that determines the need for PLC ladder logic to be communicated or handled in addition to the PLC. For example, a temperature sensor on a manufacturing line senses a temperature above a certain level, indicating a dangerous condition that may be required outside of function.

In addition to the state under the performance of the trigger, the trigger also provides some other pieces of information, among which (1) it may consist of multiple data point values, messages and micro values, the trigger payload being generated when the state occurs. the content of a notification known as a trigger payload; (2) a format in the transmission of messages, such as ASCII, XML, or database insert / update; (3) How data is propagated, such as DB2, Oracle, Microsoft SQL, IBM Websphere MQ, Message Queue, JMS, TCP, UDP or Email.

5 shows the architecture of the system of the present invention and consists of the main components of the enterprise communication controller 500, the client 800 with the workbench 810, and the enterprise computer 600.

The enterprise communication controller 500 is preferably a component that plugs into the same backplane 202 to which the PLC 204 is plugged. Thus, the enterprise communication controller 500 has the ability to communicate with the PLC 204 via the backplane 202. Enterprise communication controller 500 is comprised of a standard, multi-purpose computer having an operating system and various software components of the present invention installed therein. Preferably, enterprise communication controller 500 will operate a real-time operating system version, such as VX Works, QNX, MontaVista Linux or Windows CE operating system. It will also be equipped with a specialized connector that can plug into the enterprise communications controller 500 backplane 202. The connector will necessarily be configured according to the type of PLC 204 to which the enterprise communication controller 500 is being interfaced. Of course, other manufacturers' PLCs will have differently configured backplanes 202. In addition, as shown in FIG. 5, an application programming interface is provided to the software component of the present invention to communicate directly with the PLC 204 via the backplane 202, and in particular, to retrieve a particular data point from the PLC There is a driver 522 that provides an enterprise communication controller 500 that has the ability to read and write new values to specific data points within the PLC 204. To have a physical connector, the backplane API 522 may be special ordered according to the manufacturer of the PLC.

Client 800 is a computer that operates at some level remotely within an organization or over some network, such as the Internet. The computer is a user interface that allows a user of the system to define a project 620, name a data point with a tag 624, and add a trigger 622 to the project 620 and the trigger 622 to be performed. Activate the stateful software workbench. The information is in communication with the enterprise communication controller 500 in the process described later.

The enterprise communication controller 500 is equipped with a transaction server component 550 having specific software components including the scanner unit 520 and various functional components. Although the functional components of the present invention have been divided as described, those skilled in the software art will be convinced that any provision of the described functions will appear different but result in an architecture that provides the same functionality as the specific embodiments described and that such changes It should be noted that it is interpreted in the scope of the present invention.

The scanner component 520 is generally responsible for communicating with the workbench 810, tracking the tags 624 and triggers 622, determining when trigger results occur, and communicating with the PLC 204. .

The tag scanner 524 may identify the names or tags of various data points on the PLC 204, retrieve specific data from the PLC 204, or write the specific data to the PLC 204 via the backplane API 522. Component.

The trigger scanner 526 is a component that determines when to perform various triggers. For example, the trigger scanner 526 determines whether a certain tag 624 satisfies some logical state, such as exceeding a predetermined value, and if so, for example, to send a message to the database 602 within the enterprise server 600. The tag scanner 524 can be queried to determine the appropriate function to take in response to the trigger 622, which is the transmission to the < Trigger scanner 526 is also responsible for periodically checking or subscribing to changes in the value of any tag 624 and taking appropriate functions.

Component proxy 528 in scanner 520 is a component that interfaces with workbench 810, receives messages, and determines where to send the messages. Some messages from the workbench 810, such as instructions for creating, granting, stopping, and removing a of the trigger 622, may need to be passed directly through the proxy 528 to the trigger scanner 526. will be. In addition, some commands passing from the workbench 810 through the proxy server 528 will need to be sent to the dispatcher within the transaction component. The command will be described later.

The time synchronization manager 534 in the scanner 520 is responsible for maintaining synchronization between all clocks in the system, including the option to keep a clock inside the PLC 204. The time synchronization manager will synchronize time to the enterprise communication controller 500 within the PLC 204 and within the enterprise communication controller 500 via the instructions of the external master clock or through the clock. Preferred time indications may be apparent in the components of the workbench 810. The purpose of the time synchronization manager 534 is to synchronize all parts of the software within the enterprise communication controller 500 with some messages coming from the factory floor through the PLC 204, which may have a time designation contained therein.

The log manager 532 is a component that logs all the functions that occur within the controller 500 and keep the information in a logged state. In a preferred embodiment, the log manager 532 stores information in two separate logs, two logs first for user functions and second for function exceptions of the log manager 532 at periodic intervals or critical It may also be configured to report via email in the results. For example, if an exception occurs (eg, enterprise communication controller 500 attempts to communicate with enterprise server 600 and cannot do so), an entry in the exception log generated by log manager 532 is removed. There will be. In addition, the creation of the project through its workbench 810 and its associated triggers, and the start and stop of the project are also maintained in the log results through the log manager 532. The log manager 532 may generate and maintain an completed trail.

The user manager 530 is responsible for creating users and authenticating them. Various users logged into workbench 810 are allowed to do various tasks according to their privilege level. For example, a particular user may not be allowed to create a trigger 622, but may not be able to operate a predefined project 620 and view the results. The user manager can authenticate various levels of privilege. There are two models of user management. In one, a user privilege table is maintained on the enterprise communication controller 500. In an alternative model, user manager 530 may be integrated into a central user privilege list or an enterprise level user management system, such as a central authentication system such as LDAP or Kerberos, to allow user management in a single location within the enterprise. The level of privilege will be stored in a centralized enterprise level system and used by the local user manager 530.

In this embodiment of the present invention, all components within scanner 520 of FIG. 5 operate in a single process in enterprise communication controller 500. In addition, transaction component 550 is an independent process and all components within transaction component 550 can operate in a single process independent of scanner process 520. Scanner 520 and transaction component 550 may communicate with each other via standard mechanisms provided by an operating system for interprocess communication. However, alternative architectures in which some may operate in separate processes are acceptable as shown in FIG. 13.

Transaction component 550 is generally responsible for maintaining various information in non-volatile storage local to enterprise communication controller 500 and for sending and receiving messages to and from enterprise server 600.

The dispatcher 554 in the transaction 550 component receives messages from processes at the enterprise level 600, from the workbench 810 or from the scanner proxy 528 and in the transaction component 550. Determine where the message needs to be sent. In this respect it is very similar to scanner proxy 528 within scanner 520. For example, if the trigger scanner 526 in the scanner 520 determines that a message needs to be written to the database, the message will be sent to the dispatcher 554 via the scanner proxy 528 and the dispatcher ( 554 will send the requirements to the database interface 552, which will eventually update the database on the enterprise server and respond via a dispatcher to the success or failure of its operation. Dispatcher 554 will dispatch the message to various other components within transaction component 550 depending on (1) where the message is sent and (2) how the message is sent. For example, if a message generated within scanner 520 is sent to an MS SQL database on enterprise server 600, dispatcher 554 may determine where to send the message to perform the task.

Persistence manager 556 within transaction component 550 needs to run a system including all defined projects, all triggers, all transport elements, and anything else that needs to be saved so that the system needs to be restarted. Responsible for maintaining all information that becomes The information is stored in a file 504 in an internal disk or other nonvolatile memory device in the controller 500, and is primarily used when the controller 500 needs to lose power and resave. The last known current state of all software components on the controller 500 is read from the file 504, allowing the controller 500 to persist when power is stored.

Database interface 552 is part of a transaction transfer mechanism for transferring data from enterprise communication controller 500 to enterprise level 600. The database interface 552 is responsible for storing information that is read from the PLC into the database on the enterprise level 600 via any of a number of database communication protocols. The database can be any form of database, such as DB2, Oracle, or MS / SQL database. Database interface 552 may be a single component or may be multiple components, each of which is responsible for a particular type of database.

Message queuing interface 812, SMTP interface 813, and TCP interface 814 are part of transaction component 550 that is responsible for transferring data and messages from enterprise communication controller 500 to enterprise level 600. to be. These interfaces provide an enterprise level that can accommodate data through a variety of methods, such as receiving information from the message queue, analyzing the contents of emails sent to a specific address via SMTP, or reading data from a TCP / IP socket. 600 may be used to move data into the application. Message queuing can be provided through tools such as Websphere Message Queues, Java Message Queues, JBOSS JMS message queues, or Weblogic JMS message queues.

The store and dispatch component 558 is configured to store unintended messages in the application or database 602 at the enterprise level 600 if communication is not available between the enterprise communications controller 500 and the enterprise level 600. Element. The message is stored in a storage and dispatch database 506 on a local hard disk or other nonvolatile storage within the enterprise communication controller 500. The store and send component 558 will send any stored message within the store and send database 506 to the enterprise level 600 when communication is restored. These messages will be sent in the path from which they were originally received.

6 illustrates a process in which projects and triggers are added to enterprise communication controller 500 using workbench 810. The user sends a message 1 to the proxy 528 stating that the user wants to create a project. The message transmitted from the workbench 810 via the arrow 1 may be a creation of a project, adding a trigger to the project, naming a data point with a tag, and the like. Scanner proxy 528 sends the message to dispatcher 554 via arrow 2. The dispatcher 554 determines the result that this requires to be stored in the file 502 via the persistence manager, and thus the message 3 alternately stores the information in the file 504 via the arrow 4. And the success or failure of the operation is sent to the persistence manager, which returns to the dispatcher 554 via the arrow 5. Once the dispatcher 554 receives the status from the persistence manager 556 via arrow 5, it sends the information to scanner proxy 528 via arrow 6. At this point, the information is stored permanently in file 504. The scanner proxy 528 then sends a message to the tag scanner 524 and the trigger scanner 528 via arrows 7 and 8 to distinguish between the ones to add a trigger or tag to the project, respectively.

Data triggers and logic triggers are shown in FIGS. 7 and 8, respectively. To illustrate the data trigger in FIG. 7, we will assume that project 620 has already been created and trigger 622 has been defined. To illustrate data triggers, we assume that we want to trigger a message to the enterprise server when a particular data point on the PLC has changed. For example, when a data point representing a production count is incremented in one PLC, the user at enterprise level 600 wants to be notified. In this case, the tag scanner 524 will poll a particular data point representing the production count at the PLC 204 at a predetermined rate, for example once every second. Thus, a message is sent from the tag scanner 524 to the backplane API 522 every second to recover the data, and the data is propagated to the trigger scanner 526 via the arrow 1. The trigger scanner 526 obtains the value of the data and finds out whether the value has changed between the current reading of the data and the previous reading of the data, and if so, the trigger scanner 526 takes the data, packages the message, and the arrow (2). ) To the dispatcher 554. The message sent from the trigger scanner 526 to the dispatcher 554 includes information about the transmission, ie where data will be sent within the enterprise level 600 and how the data will be sent. Dispatcher 554 determines where the message needs to be sent for proper handling. For example, if a message is sent through the message queue, dispatcher 554 will send the message to message queue handler 812 via arrow 3 within enterprise level 600. Message queue handler 811 within enterprise level 600 then forwards the message to message queue manager 812 via arrow 5 within transaction component 550 saying that the message has been received. The information is sent to the dispatcher 554 via arrow 6 and a status message is sent to scanner proxy 528 via arrow 7. If an acknowledgment sent via arrow 5 is not received, dispatcher 554 will eventually store and send database 506 via message store and dispatch component 558 for transmission to enterprise server 600. It should be noted that this will cause it to be stored in. In addition, an arrow 7 pointing to the scanner proxy 528 can cause a log message to be recorded via the log manager 532.

Referring now to FIG. 8, FIG. 8 illustrates the flow of information that occurs as a result of a logic trigger, which is a trigger that occurs within the ladder logic of a PLC. The flow of messages in FIG. 8 is very similar to that of FIG. 7 except for arrows 1 and 8. Arrow 1 in FIG. 8 indicates a message coming directly from the PLC via the backplane API 522. The information passes through a tag scanner 524 and a trigger scanner 526 that will determine what will happen as a result of receiving a message from the PLC. For example, the message may be an error condition detected by the PLC 204 or may be a message sent as a result of a change in a particular data point on the PLC 204, for example. In any case, the ladder logic of the PLC 204 will determine when the message will be sent. In other words, PLC 204 determines which entity at enterprise level 600 it needs to know about the data it sends. Continuing from this point, message execution and propagation through the scanner 520 and transaction component 550 to the enterprise server 600 when a status message is received by the scanner proxy 528 via arrow 7. Data trigger in FIG. 7 except that a message is sent to the PLC 204 via arrow 8 and to the backplane API 522 to inform PLC 204 that the data was successfully sent at the enterprise level. Same as described in After some period of time, if the PLC 204 fails to obtain confirmation of a successful transmission, the PLC 204 will probably have some logic to be executed to handle the failure. In that case, the PLC 204 will probably retry the data transfer or set an alert indicating that the data transfer has failed.

9 depicts the process by which the controller 500 restores itself after a power failure. In this case, the purpose is to restore the enterprise communications controller 500 to the state prior to the power down. Status information is accessed from the file 504 through the persistence manager 556. Proxy 528 sends a message to dispatcher 554 via arrow 1. Dispatcher 554 determines that persistence manager 556 needs to complete the request and sends a message to persistence manager 556 via arrow 2. Persistence manager 556 recovers the previous state of enterprise communication controller 500 from file 504 via arrow 3 and relays to scanner proxy 528 via the inverse of arrow 4 to forward the dispatcher ( 554). Scanner proxy 528 may then recover all triggers 622 to trigger scanner 526 via message arrow 7 and all tags 624 to tag scanner 524 via arrow 6. Can be recovered.

10 depicts the storage and shipping operational features previously discussed. Storage and dispatch features are required when a message needs to be sent to the enterprise server 600 but cannot be sent by a failed network connection. The storage and dispatch component will periodically attempt to recover communication with the enterprise server 600. When communication is restored between enterprise controller 500 and enterprise server 600, all messages stored in storage and dispatch database 506 are sent to enterprise server 600 in the order in which they were received. In the case where the message queue handler 812 is shown in FIG. 10 where the transmission of the selection for the particular message, the message queue handler 812 is communicated by the message queue manager 811 at the enterprise server 600 to the communication channel arrow 1. Upon determining that there is an error, message queue handler 812 sends a message to store and dispatch manager 558 via arrow 2. The store and dispatch manager 558 recovers via arrow 2 all messages that need to be sent through the message queue. The store and dispatch manager 528 periodically attempts to reconnect to the message queue manager 811 at the enterprise server 600 via arrow 3. When the connection is restored, the store and forward manager 528 sends the stored message from the enterprise server 600 to the message queue manager 811 via arrow 3. The acknowledgment is then sent back from the store and dispatch manager 558 to the message queue handler 812 via arrow 4 and normal operation resumes via arrow 1. A copy of the data is then removed from the storage and dispatch database 506. The same storage and forwarding mechanism can be applied to any supported transport mechanism.

11 depicts the operation of the monitoring instrument system itself monitor. The monitoring instrument facility 502 determines whether the processor on which the scanner 520 and the transaction component 502 are running is up and running. The watchdog instrument component 502 periodically communicates with the operating system to recover information about the process through their process identifiers. If the monitoring instrument monitor determines that the process identifier of one of the processes indicating that the process is no longer running is invalid, the running process is stopped and both processes are restarted in their proper order, preferably at this point. In, the previous state of the enterprise communication controller 500 is recovered from the file 504.

12 illustrates the functionality in which the configuration of enterprise communication controller 500 is exported to workbench 810. For example, this may be useful when the setup needs to be replicated on different enterprise communication controllers 500. Workbench 810 sends a message to scanner proxy 528 in scanner 520 via arrow 1. The scanner proxy 528 sends a message to the persistence manager 556 via arrow 2. Persistence manager 556 retrieves the current state from file 504 and returns to scanner proxy 528 via arrow 3 and returns to workbench 810 on client 800 via arrow 4. .

As shown in FIG. 4, workbench component 810 is an interbase with a user's workstation and enterprise communication controller 500. Typically, workbench 810 will run on a user level computer at the enterprise level 600 of the organization. However, since the workbench 810 communicates with the enterprise communications controller 500 via standard Internet protocols, the workbench 810 can be located on virtually any computer inside or outside the organization. As described above, one of the functions of the workbench 810 allows a user to create a project 620. The workbench 810 allows the construction of the project and storage of the project with the enterprise communication controller 500, where it will be added to the file 504 by the persistence manager 556. Workbench 810 also provides the ability to start, stop, export, and import project 620. Workbench 810 may interact with multiple enterprise communications controller 500 during the same session to perform the actions as listed above in each enterprise communications controller 500.

The project consists of a group of triggers 622 that are defined as being in a situation where data is sent from the enterprise communication controller 500 to the enterprise server 600. The trigger can include a tag 624, a message 626, a macro 628, and an expression 629. Tag 624 is defined as a data type trigger, while message 626 is defined as a logic type trigger. The macro settings 628 defined within the trigger allow the trigger to simply perform predefined data processing. The expression parser 629 allows a user to process data from either the PLC or the enterprise server 600. For example, the user can create an expression to change the numeric value, such as changing from Celsius to Fahrenheit before sending to the enterprise server 600. Also included in trigger 622 is information in the transporter 630 that may be used to transfer data from enterprise communication controller 500 to enterprise server 600.

Workbench 810 may be used to define transport 630. Transport 630 is a mechanism by which a user can provide destination and format information for data as it is transmitted from enterprise communication controller 500 to enterprise server 600. Transports can be any of a number of types, including TCP, message queues, databases (for related databases), and SMTP (email). The created transport type depends on the application and / or database on which the user wishes to send data. In order to communicate with an application running on enterprise server 600, the application must be able to understand one of the protocols and be able to recognize messages over that protocol. Typically, data may be sent to a specific location (ie, application) on the enterprise intranet, a location on the Internet, or stored in the enterprise server 600 in a database such as DB2, Microsoft SQL, or an Oracle database. The format of the data can be any of a number of formats including XML, ASCII, or database inserts / updates.

Workbench 810 also allows a user to view tags 624 returned by enterprise communication controller 500. The tag 624 is named as a data point in the PLC ladder logic program that represents a memory location in the PLC. The workbench 810 may provide a tree view of the tag from which the current value of the data point in the PLC ladder logic program may be read.

The log viewer 632 in the workbench 810 provides a means of viewing system event and exception error logs. The log viewer 632 is a tool that allows a user to view a log generated by the log manager 532 on the enterprise communication controller 500. Typically, these logs may include audit logs and exception logs, which can be used as diagnostic tools for tracking and interpreting user activities, errors, and system messages. Typically, activities that occur in PLC204 are logged by date, time, activity, type, and / or user.

Workbench 810 is also central to the management of any enterprise communication controller 500 that may be connected thereto. The management module 640 sets the network settings 644 of the enterprise communications controller 500, includes setting of IP addresses, defines users and their privilege levels 648, and various transport protocols 650. Providing license management functionality for workbench software that may be required, and viewing the status of ladder logic programs of all PLCs installed in the same chassis with the enterprise communication controller 500 via the module status 652. It provides a means for performing such management functions. In addition, the management function 640 may include means for providing an external time synchronization signal to the enterprise communication controller 500 and all PLCs connected thereto. The workbench's time management function 646 allows the user to set the current time, set synchronization settings, and set up a synchronization server that functions as an external time reference for the entire system. The synchronization setting includes a frequency update, and the controller 500 may function as a client for an external time reference, or otherwise as both a client and a server for another enterprise communication controller 500. It is also possible to set a synchronization protocol, such as a simple network time protocol (SNTP), a user data protocol (UDP), a TCP protocol, or another commonly known protocol used for synchronizing time. . The management function also provides a means for defining an exception notification list based on a group of email addresses.

When the workbench 810 is started, it has the ability to search the network for an available enterprise communication controller 500 that can be connected to the Internet or intranet. The search range of workbench 810 for available enterprise communication controller 500 may be limited by defining an IP subnet address.

There are several other embodiments of the present invention. FIG. 13 illustrates another embodiment in which the enterprise communication controller 500 is in direct communication with a PLC via a backplane API522. The configuration may be necessary where the enterprise communication controller 500 needs to communicate with additional devices, such as RFID readers, in which case the BP API522b may be different for communicating with external devices. The configuration also requires multiple tag scanners 524a and 524b to interface with various devices (PLC and RFIP readers).

In some customer configurations, a single enterprise communication controller 500 may need to communicate with other PLCs without any enterprise communication controller 500 option. This is done in communication with the PLC communication module instead of using the backplane API. As shown in Figures 14 and 15, there are two versions in which this can be done. In FIG. 14, the enterprise communication controller can interface with the PLC 204a in the manner described for the first embodiment of the present invention. To communicate with the additional PLC 204b, the PLC 204a is connected with the PLC 204b through the PLC communication port 210. In addition, the enterprise communication controller 500 then interfaces with the PLC 204b via the connection. For example, the connection between the communication ports 210 of the PLCs 204a and 204b may be serial communication via an RS2332 connection or TCP / IP. As shown in FIG. 18, FIG. 15 illustrates another form of configuration in which an enterprise communication controller is configured with a customer device driver 502 to communicate with an additional PLC 204b via a PLC communication port 210.

In some factory floor environments, there may be a need for an enterprise system that not only collects data from the floor but also transmits information to the floor. There may be processing information required at the factory floor, or the production request may be changed based on sales. There are two ways to initiate the data transition from enterprise level to PLC level: PLC request or enterprise push.

 In FIG. 16, if there is a data transformation requesting a spontaneous request or data retrieval from a PLC retrieving data, trigger scanner 526 receives a request for data via arrow 1. The request is sent to sender 554 via arrow 2. The sender 554 selects the appropriate transmission controller to execute the request and sends the information. In this example, since the requested information may remain in the database, the request is sent to the database interface 552 via arrow 3. The database interface 552 requests the appropriate information from the enterprise database server 560 via arrow 4 and receives the information via arrow 5. The information is returned to sender 554 via arrow 6 and then sent to proxy 528 via arrow 7. It is then fed to the backplane API522 via arrow 8 for transmission to PLC204. The information can now be used by the PLC204 for the control process.

In addition, there is a host that initializes the write back shown in FIG. 17 which serves the same role as the PLC data request. In this case, the reality at enterprise level 600 is to change to something on the factory floor. This is done via a message initialized at enterprise level 600 propagated to PLC204, recording data with one or more tags. The flow of data is the same as that shown in FIG. 16 except that an initial request is sent from the enterprise server 600 and sent to the processing server 550 via the message queue manager 811.

In another embodiment of the present invention shown in FIG. 18, the enterprise communication controller 500 may not be useful for a particular type of PLC or the associated PLC may not have the ability to communicate over the backplane. . In this case, there is an option to modify the first embodiment of the present invention so that communication with the PLC204 is made via means other than the backplane API522 to execute an external PC501, or "Universal Enterprise Communication Controller" (UECC). In this case, the specialized device driver 502 replaces the functionality of the backplane API522. All other capabilities of the solution are maintained. The device driver 502 may maintain one or more common factory layer communication mechanisms including serial communication, TCP / IP, data highway +, and Profibus. Typically, these connections are made via an RS232 connection between the UECC 501 and the PLC communication module 210 via Ethernet or arrow 1. However, some PLCs require a connection with their PLC controller 212 via arrow 2. In this embodiment of the invention, the UECC 501 can communicate with multiple PLCs at any given time.

As shown in FIG. 19, extension of the above structure tends to include a logic composer 812. The logic composer 812 allows the end user to build a workflow or logic flow based on a series of "function blocks" that provide the end user with rich functional settings. For example, these functions may include test provisions, data manipulation, sending and receiving from any transport, looping through logic areas, request information from the enterprise or PLC level, and other workflow items. Logic composer 812 directly affects each component present and organizes the main activities in the box. This provides a general business logic flow in addition to the other features already provided. After the logic flow is built on the client, it is sent to the logic server 814 via arrow 1 for storage and execution. Logic execution engine 816 of logic server 814 1) stores the resolution in logic storage component 818 via arrow 2; 2) create a list of affected PLC data tags via arrow 3 and store them in reference table 820; 3) The necessary data is recorded through the puff / sub client 822 and the pub / sub server 824 through arrows 4 and 5, respectively. Once the system is running, the logic execution engine 816 receives the data transformation via arrows 6 and 7 and then performs the necessary business logic or data manipulation. As a result, information can be sent to the required user via one or more options. The updated / inferred information may be returned to the PLC204 by the scanner 520 via the arrow 8, and the updated / inferred information may be returned to the enterprise server 600 by the processing server 550 via the arrow 9. ) Or the updated / inferred information may be deplayed by the display server 640 as an end user via arrow 10.

In addition, the architecture of the present invention may include a display subsystem consisting of three main components, as shown in FIG. 20: a runtime viewer 850 for viewing data, a workbench display composer defining a screen ( 842, and a runtime display server 840 that maintains screen / data updates and maintains display resolution. In one embodiment of the invention, the workbench 810 allows a user to define operations and data / message exchanges between the PLC and the enterprise server 600. In addition, the user has a need to view data from various clients to define a screen that meets their viewing needs. The display subsystem is a reliable tool that allows these resolutions to be generated within the enterprise communications controller 500 to provide this data to any client.

Display composer 842 is an extension to workbench 810 that allows for the resolution of the screen on which data is displayed. The screen may include a fill bar, text field, button, warning indicator, or other display object linked with a data tag in the PLC 204. The display composer 842 transmits the screen resolution information to the request coordinator unit 844 of the display server 840 via the arrow 1. The request coordinator 844 stores the display resolution locally on the display storage 842 or references a display that can be stored on a separate central server. Request coordinator 844 also analyzes the content of the display resolution, generates a list of PLC data tags that need to be notified to the display, and stores this list in reference table 846. The request coordinator 844 uses the list of PLC data tags to request the pub / sub client 822 via arrow 4 to inform the PLC of the conversion in the data. Via arrow 5, pub / sub client 822 registers these requests by enhanced pub / sub server 824 for scanner 520 of the first embodiment. Once the tag is updated in the PLC based on factory floor changes, the pub / sub server 824 changes in the situation to the request coordinator 844 via the pub / sub client 822, arrows 6 and 7 Send. The display information is then updated and sent via arrow 8 to the appropriate viewer. The viewer application 850 on the client 800 may be a proprietary viewer or may be a typical commercial web browser. Depending on the client, the protocol of arrow 8 can be proprietary or can be standard HTTP or HTTPS.

Extensions of the above structures tend to include the expression parser shown in FIG. 21, which allows the user to further manipulate the data prior to sending data to the enterprise level 600. The current structure allows writing of data points or tags defined on the device to various output sources. Association of data points to output sources takes place while defining the payload of the trigger. While recording these initial data pointer values, there are cases where it is desirable to record the calculated values for the output source. The input to the operation may consist of reading data point values from the device with a constant value defined by the user. The enhancement allows the user to define mathematical equations while constructing data point values and constant values as part of the trigger payload. The result of the equation occurs on the device and uses data point value reading when the corresponding trigger is fired. The enhancement extends the data recording capability to include calculated values as well as tag and constant values.

Using expression composer 818, workbench 810 allows a user to generate mathematical equations as a data source in the trigger payload. In addition to dragging and dropping tag values to the payload resolution, the user can also drag and drop predefined macro values (time stamps) and user defined macro values (constants) into the trigger payload. can do. Expression composer 818 also provides the user with the ability to drag the formula into the trigger payload. Dropping the formula macro into the trigger payload initializes the expression composer 818 and provides it to the user at the resolution of the mathematical expression evaluated at runtime on the device. The editor allows the user to enter constant fractional values with mathematical operators from an interface that reassembles the standard calculator. In addition, the editor allows the user to drag and drop fractional data points into the equation.

21 shows the flow of data for the expression composer characteristics described above. The expression composer 818 is a user level client application running on the client 800 that allows the user to graphically create mathematical and logic expressions. The expression resolution is sent to the expression parser engine 872 in the expression server 870 via arrow 1. The equation resolution is stored locally in the expression store 874. Expression parser 872 analyzes the expression resolutions, evaluates the expressions, and generates a list of PLC data tags that need to be known to store them in reference table 826 via arrow 3. The expression parser 872 uses the PLC data tag list to make a request to the PLC notifying any change in the data involved, via the arrow 4 to the publish / write client 822. Publication / recording client 822 registers these requests with publication / recording server 824 via arrow 5 and notifies any changes of these data items via arrows 6 and 7. The result of the evaluation of the expression can be sent to the user via arrows 8 and 9 in the manner described above to send the message to the enterprise level 600.

While preferred embodiments of the present invention have been described herein, it should be understood as one of ordinary skill in the art in the art, and the scope of the present invention tends to include equivalents and other items that perform similar functions. The scope of the invention is defined in the claims below.

The present invention not only provides the ability to directly control and modify the manufacturing process, but also has the effect of capturing data and identifying individual events occurring on the plant floor.

Claims (48)

In systems that communicate data with control and monitoring devices: A controller coupled to and in communication with the control and monitoring device, the controller comprising a controller having a network connection and software installed on the controller; The software reads data from the control and monitoring device, receives an unclaimed message from the control and monitoring device, and the software transmits the data and message to a destination via the network connection. And a system in data communication with the monitoring device. The method of claim 1, The control and monitoring device is a programmable logic controller (PLC) and the data is a discrete data point read from the programmable logic controller. The method of claim 2, And the data is transmitted over the network connection in response to the occurrence of one or more trigger conditions. The method of claim 3, wherein The at least one trigger state is selected from a group consisting of receipt of an unclaimed message from the PLC, a change in a data point read from the PLC, and a satisfaction of a logical state with respect to the data point read from the PLC System for data communication with a control and monitoring device. The method of claim 4, wherein The controller is programmable to define the trigger condition. The method of claim 2, And the software transmits the data to a destination via the network connection in response to a request received through the network connection. The method of claim 5, The programming of the trigger state comprises a format for causing the data to be transmitted in accordance with information about the destination of the data and the satisfaction of the trigger state. The method of claim 7, wherein And the data is formatted before being transmitted to the destination via the network connection. The method of claim 8, The format data is transmitted over the network connection using one or more other protocols including TCP, message queue, SMTP, and SQL database calls. The method of claim 7, wherein The software inserts the data into a database or updates data already residing in the database, the database residing on a computer connected to the controller via the network connection. system. The method of claim 8, And said software transmits said format message to an application running on a computer connected to said controller via said network connection. The method of claim 7, wherein Further comprising one or more configuration files contained in non-volatile memory on the controller, the configuration files all including a record of defined project, transfer and general purpose settings, the software recovering itself from a power failure condition. Restoring to a previous state using the configuration file according to claim 1, wherein the system is in data communication with the control and monitoring device. The method of claim 7, wherein And a volatile working storage area containing a current state of all reference discrete data points read from the PLC. The method of claim 8, And a temporary storage area included in the nonvolatile memory device on the controller, wherein the format data is stored when the network connection is not used. The method of claim 14, And the software retransmits all the format data stored in the temporary storage area when the network connection is used. The method of claim 8, And at least one log file stored in a nonvolatile memory device in the controller, wherein the software registers the log file. The method of claim 8, And a user application running on a computer connected to the controller via the network connection, the user application causing the user to configure and program the controller. The method of claim 18, And the user creates a project consisting of one or more trigger states, the project being downloaded to the software in the controller via the network connection. The method of claim 18, And the user defines a specific destination of the data and an associated trigger condition with the particular receiver. The method of claim 19, And said particular destination is selected from the group consisting of an application running on a computer with a network connection, a database residing on a computer with a network connection, and an email address. The method of claim 20, And the controller directly transmits the data to the specific destination associated with the trigger condition when the trigger condition is satisfied. The method of claim 20, And the user specifies a method used to transmit the data to the specific destination. The method of claim 22, And wherein the method is selected from the group comprising TCP messages, SQL database calls, and SMTP messages. The method of claim 2, And said controller and said PLC share a common backplane, said controller communicating with said PLC via said backplane. The method of claim 24, And the controller shares a plurality of PLCs with a common backplane and communicates with the plurality of PLCs via the shared backplane. The method of claim 24, The PLC is connected to the second PLC via a communication channel, and the controller communicates with the second PLC via a PLC sharing a backplane. The method of claim 24, Wherein said communication channel comprises a serial connection or a TCP / IP connection. The method of claim 2, The software further comprises a communication device driver, the device driver causing the controller to communicate with a second PLC via a communication channel. The method of claim 28, Wherein said communication channel comprises a serial connection or a TCP / IP connection. The method of claim 2, And said controller modifies said discrete data point on said PLC. The method of claim 30, Said PLC requesting specific data from said controller, said controller retrieving said data requested by said PLC via said network connection. The method of claim 7, wherein Control and monitoring further comprising a user application configured to configure the controller, to define the trigger condition, and to define the destination for the data, the computer being connected to the controller via the network connection. A system in data communication with a device. The method of claim 2, The software further comprises a logic server that tracks changes in the data read from the PLC and applies logic operations to the data read from the PLC. The method of claim 33, wherein And a logical composer application running on a computer connected to the controller through the network wqj to construct a logic flow for the logical server. The method of claim 2, The software further comprises a display server for maintaining and updating a user display connected to the controller via the network connection. 36. The method of claim 35 wherein And a viewer application running on a computer connected to the controller via the network connection to view the display maintained and updated by the display server. The method of claim 36, And the viewer application is a web browser. The method of claim 2, And an expression server that evaluates the repair or logical expression and uses the data read from the PLC. The method of claim 38, And an expression composer application running on a computer connected to the controller via the network connection to configure a repair or logical expression for the expression server. The method of claim 23, wherein The controller is a PC, the software further comprising a device driver, the device driver causing the PC to communicate with one or more PLCs through one or more communication channels. The method of claim 40, And said at least one communication channel comprises one of a serial connection or a TCP / IP connection. In a system that communicates data with a PLC: A controller coupled to and in communication with the PLC, the controller reading a specific data point from the PLC; The controller, Network connection; A software component installed in the controller that evaluates a trigger condition and transmits one or more of the data points read from the PLC to a predetermined destination via the network connection when the trigger condition is satisfied; And And a user application running on a computer connected to said controller via said network connection to configure said controller, define said trigger condition, and define said predetermined destination. The method of claim 42, And the predetermined destination is selected from the group consisting of an application running on a computer with a network connection, a database resident on the computer with a network connection, and an email address. The method of claim 42, The controller is plugged into the backplane of the PLC and communicates with the PLC via the backplane. The method of claim 42, The trigger state is selected from the group consisting of the receipt of an unclaimed message from the PLC, a change in a data point read from the PLC, and a satisfaction of a logic state with respect to a data point read from the PLC A system for communicating data with. In systems that communicate data with control and monitoring devices: A PC coupled to and in communication with one or more of said control and monitoring devices; The PC, Network connection; And Software installed on the PC, the software including device drivers that read data from the one or more control and monitoring devices and receive unclaimed messages from the one or more control and monitoring devices; And said software transmits said data and messages to a destination via said network connection. The method of claim 46, Said at least one control and monitoring device is a programmable logic controller (PLC) and said data is a discrete data point read from said at least one programmable logic controller. The method of claim 47, The PC is connected to one or more PLCs via one or more corresponding communication channels, the communication channel comprising one of a serial connection or a TCP / IP connection.

Images