This application claims priority to U.S. provisional application no. 61/835,679, filed June 17, 2013, the disclosure of which is incorporated by reference herein in its entirety.

1. Technical Field

The present invention relates to cyber-physical systems and a programmable logic controller therefor.

2. Discussion of the Related Art

Cyber-physical systems (CPS) are integrations of computation, networking, and physical processes. Embedded systems (e.g., hardware and software) monitor and control physical processes such as physical, chemical, and biological. Current programmable logic controller (PLC) applications exhibit similar features to CPS applications but they are not regarded as "cyber-physical". For example, a typical PLC application interacts with physical processes through sensors and actuators, and it is able to communicate with other embedded devices located at large distances. However, typical PLC applications are developed using a rather simplistic approach that prioritizes the hardware/software over the physical process under control. As a result, these simple control algorithms are not suitable for future applications where more intelligence is necessary to optimize the overall performance of the system. SUMMARY OF THE INVENTION

According to an exemplary embodiment of the present invention, there is provided a method of operating a programmable logic controller (PLC), the method including: receiving, at the PLC, external data; simulating a control strategy using the external data, wherein the control strategy is for a system under control of the PLC; and implementing, with the PLC, the control strategy.

The external data may be provided from a web service.

Simulating a control strategy may include: capturing the external data in a first function block; capturing simulation data in a second function block; and executing a program incorporating the first and second function blocks to generate the control strategy.

The first and second function blocks may be reusable and language independent components embeddable in PLC programs.

The simulation data may include model-based data.

The simulation may be performed in the PLC or outside the PLC.

The method may further include receiving local data from the system under control, wherein the control strategy is simulated using the local data.

According to an exemplary embodiment of the present invention, there is provided a method of operating a PLC, the method including: simulating a control strategy for a system under control of the PLC; and implementing, with the PLC, the control strategy.

The simulation may use internal or external data.

The simulation may be performed in the PLC or outside the PLC. Simulating the control strategy may include: capturing external data in a first function block; capturing simulation data in a second function block; and executing a program incorporating the first and second function blocks to generate the control strategy.

According to an exemplary embodiment of the present invention, there is provided a method of operating a PLC, the method including: determining a control strategy for a system under control of the PLC; and executing, under control of the PLC, the control strategy, wherein the control strategy is determined by using external data or simulation information of the system.

The simulation information may be obtained directly from the PLC or from an external source.

Determining a control strategy may include: capturing the external data or simulation information in a function block; and executing a program incorporating the function block to generate the control strategy.

The function block may be a reusable and language independent component embeddable in a PLC program.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and IB illustrate a comparison between a conventional programmable logic controller (PLC) and a cyber-physical (CPS)-PLC according to an exemplary embodiment of the present invention;

FIGS. 2 A and 2B illustrate a comparison between a conventional PLC workflow and a CPS-PLC workflow according to an exemplary embodiment of the present invention; FIG. 3 is a block diagram of a CPS-PLC use case according to an exemplary embodiment of the present invention;

FIG. 4 illustrates function blocks according to an exemplary embodiment of the present invention; and

FIG. 5 is a computer system in which an exemplary embodiment of the present invention may be implemented.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In an exemplary embodiment of the present invention, there is provided a cyber-physical programmable logic controller (CPS-PLC) architecture that leverages real-time properties (e.g., runtime), engineering (e.g., compatibility with sensors, actuators, HMIs, 10 devices), programming (e.g., IEC 61 131-3 editors and languages), and tools (e.g., compilers, optimizers, debuggers) of traditional PLC systems to control highly distributed CPS applications.

In an exemplary embodiment of the present invention, there is provided a model-based design tool compatible with classic PLC engineering tools that enable the design and engineering of complex control algorithms for CPS applications. Here, CPS-PLC functionality is encapsulated in reusable components compatible with IEC 61131-3 languages that allow highly distributed communication and provide multi-domain physical simulation capabilities.

PLCs are hard real-time control systems designed to interact with and control physical processes through sensors and actuators in harsh environments and for very long periods of time. The most salient feature of PLCs is their cyclic execution mechanism. The scan cycle time (also known as the sampling rate) refers to the period of time in which the system is expected to (1) read the state of the system under control (e.g., a plant) through the sensors, (2) compute the corrections to bring the plant to the desired state, and (3) send the corrective commands through the actuators. In addition, PLCs have a large user base supported by a mature toolchain that provides various programming languages, editors, compilers, debuggers (e.g., SIMATIC), and communication protocols (e.g., PROFIBUS, PPvOFINET). Traditional PLCs are unable to interact directly with the external world or processes. Hereafter, we introduce the CPS-PLC architecture that enables external communication.

The distributed nature of CPS applications has implications in traditional PLC systems. For example, FIG. 1 A shows a heating, ventilation, and air conditioning (HVAC) system 6 of a building 1 controlled by an automation network composed of a PLC 2, a human machine interface HMI 3, and an I/O module 4. Data of sensor/actuator 5 is read/written periodically by the I/O module 4 that communicates with the PLC 2. Data of sensor/actuator 5 is transmitted to the HVAC system 6. The PLC 2 is in charge of implementing a control algorithm that maintains the temperature of the building 1 at a desired set point (e.g., set by users through the HMI 3) by turning on/off the HVAC system 6 depending on the current temperature specified by the temperature sensor. Notice that in this configuration, the PLC 2 is communicating locally (via bus/network 7) to other automation devices within the building 1. Smart buildings are an emerging CPS application where networked, intelligent, sensitive and adaptable buildings maximize energy efficiency, comfort, and safety. This application requires more sophisticated control algorithms that interact with external data such as weather and utility company pricing information. FIG. IB shows the automation system that controls the HVAC system of a smart building using CPS-PLC 2b. Notice that this automation system communicates globally to external and distant data sources 8 and 9 including weather and utility company pricing information.

The availability of external sources of data 8 and 9 in the CPS-PLC 2b

accommodates more sophisticated control algorithms that adapt to varying physical and market conditions. These control algorithms often require simulation of physical processes (e.g., building simulation 10) in order to estimate optimal control strategies as shown in FIG. IB. The CPS-PLC 2b takes advantage of physical simulation 10 to improve the accuracy of the control strategies and also as the means for validation and verification of the control code itself. Existing PLC engineering tools do not provide simulation support and global communication support. Further disclosed hereafter are new model-based design tools based on the existing PLC toolchain where the control algorithms can be coupled to a physical simulation and can communicate with external data sources.

In the model-based design tools for CPS-PLC, existing engineering tools are leveraged for PLCs to minimize implementation effort and to provide users the necessary extensions for CPS-PLC programming in an environment they are familiar with. Since most PLC vendors provide tools compatible with the IEC 61 131-3 standard, the concept of function blocks (FBs) are used to provide the CPS-PLC functionality in reusable and language independent components that can be embedded in existing PLC programs including Instruction List (IL), Structured Text (ST), Ladder Diagram (LD), Function Block Diagram (FBD), and Sequential Function Charts (SFC). FIGA. 2A and 2B compare a traditional PLC application engineering workflow with a CPS-PLC workflow according to an exemplary embodiment of the present invention. In the traditional workflow shown in FIG. 2A, an automation engineer 1 first communicates with a mechatronics expert 2 to understand control and system requirements. Control code and algorithms create a PLC program that uses function blocks from a reusable component library 3 (typically provided by the PLC vendor but extendable by the users). A PLC toolchain 4 consisting of editors, compilers, debuggers, and optimizers transforms the high-level PLC program into executable code for a PLC 5. The PLC runtime is in charge of executing this program to control a physical system. An aspect of the traditional PLC workflow is that the communication between the mechatronics expert 2 and the automation engineer 1 is often informal using ad-hoc tools such as Microsoft Word, Powerpoint, and Excel.

FIG. 2B shows the CPS-PLC workflow. Notice that the automation engineer 1 is now required to interact with a Web Expert 6 and also with the mechatronics expert 2. However, this interaction is formalized through object references to external data 7 from web services 8 and simulation models 9 created with model based design (MBD) tools 10. The formalization of the interaction between different experts reduces the errors and improves the development time of CPS control applications. It is noted that the Web Expert 6 may not be a person but the body of knowledge necessary to make use of web technologies. The web is an environment that uses a large variety of data formats, protocols, languages, and standards different than those used in automation. Compared to the existing paradigm, Web Expert 6 is included to address new and critical aspects such as cybersecurity. To make use of external data 7 and simulation models 9 in the CPS-PLC 5, the automation engineer 1 is required to use new function blocks that provide the mechanisms for external communication and simulation to the CPS-PLC 5. These function blocks would typically be developed by the CPS-PLC vendor and shipped to the users in the form of reusable function blocks 3. With more sources of data (e.g., historical or real-time) and high-fidelity physical simulations, the automation engineer 1 can now develop more sophisticated control algorithms for CPS applications to create more efficient and intelligent systems. Due to the use of function blocks, the existing PLC toolchain 4 can be reused to edit, compile, debug, and optimize the CPS-PLC applications. Finally, the CPS-PLC runtime converts the object references between the external data sources 7 and physical simulation models 9 into periodic communication with instances of an external data stream 11 and the simulation executable 12. It is noted that the simulation can be either executed locally 13 in the CPS-PLC 5 or externally in a personal computer 12. Local simulations can be beneficial to improve the accuracy of control algorithms that require frequent interaction with face physical dynamic systems such as chemical processes. The dynamic interaction between the CPS-PLC with external data and external/local detailed physical simulation opens new possibilities for the use of this architecture in CPS applications.

A use-case of an exemplary embodiment of the present invention will now be described. The use-case will be referred to as the smart energy box.

The goal of the smart energy box, a CPS-PLC, is to analyze and provide smart energy strategies to a building automation system with the consideration of current smart building energy analysis (e.g., simulation) and demand response events (e.g., external data). It is possible to enable or disable strategy evaluation or just to use energy simulation alone or just demand response event alone. In the event of disabling both energy simulation and demand response, the building will run in the normal/default mode equivalent to the functionality of a traditional PLC. FIG. 3 shows the smart energy box prototype 5. A CPS-PLC (2) uses a Simatic Microbox PC running Simatic WinAC that uses function blocks to communicate periodically with external weather data (1) and to create an interface with an energy simulation (4) running in the controller (2). Once the control algorithm decides the best energy optimization strategy, the CPS-PLC communicates with the building equipment (3) using standard I/O interfaces. It is important to note that the smart energy box 5 is a prototype to demonstrate the capabilities of CPS-PLCs and although this example is related to smart building applications, the CPS-PLC architecture is applicable to manufacturing, mobility, transportation, and other CPS applications.

Weather conditions have a direct impact in the energy utilization of a building. The smart energy box 5 must predict the energy usage based on a real-time weather forecast and therefore we provide a weather adapter as a function block for the CPS-PLC programmer to access weather data streams 1 through the internet in real-time. The weather adapter is one of the main components of the smart energy box 5 because it provides two key functions: (1) retrieves the weather forecast information through a publicly available web service; (2) converts and stores the weather forecast information into the hourly weather data that the smart energy box 5 control algorithm and the energy simulation 4 can use during runtime to provide accurate energy utilization strategies that attempt to minimize cost, maximize the energy efficiency, and to guarantee the occupancy comfort for the occupants of the building. In this case, the smart energy box 5 connects to the National Oceanic and

Atmospheric Association (NOAA) weather service to retrieve real-time weather data 1 provided as 3 -hour interval reports for the next 72 hours and as 6-hour interval reports for the next 168 hours. NOAA uses the National Digital Forecast Database (NDFD) schema to deliver weather data. The web expert (see FIG. 2B) is responsible for converting the data with the NDFD schema into the internal weather representation of the smart energy box 5. The weather adapter of the smart energy box 5 is capable of fetching weather data from other sources such as Weather Underground.

The real-time weather data 1 that is imported by the smart energy box 5 may be shown on a user interface for the web expert to facilitate the data conversion between weather data formats.

The building modeling begins with a building modeling layout tool that allows building designers (analogous to mechatronics experts in FIG. 2) to visually create the shape of a building in a map. The user draws a perimeter polygon on the map, and specifies the number of floors, occupancy, lighting and HVAC configuration. These parameters are used to populate the simulation parameters of a Matlab/Simulink model that describes the energy dynamics of the building. Using a Mathworks code generator, the Matlab/Simulink model can be translated into Structured Text and executed directly on the CPS-PLC 2 or, alternatively, compiled into an executable simulation object that is executed in a personal computer and periodically communicates with the control code executed in the CPS-PLC runtime.

Another aspect of the CPS-PLC 2 is to reuse the PLC toolchain (see FIG. 2B) and to provide the extra functionality through reusable function blocks that users can embed in their applications to develop more sophisticated algorithm and control strategies. FIG. 4 shows two function blocks "FC1 check network for updates" and "FC2 StepV" that provide connectivity to external data sources (e.g., weather data) and to the local simulation (e.g., thermal-energy). Notice that both function blocks are assigned to the standard automation task (OBI and OB35) and this allows cyclic communication every 100 ms and 1 ms. The simulation function block is configured to 1 ms in order to achieve a real-time interaction between the simulated physical process and the controller.

This disclosure introduces the CPS-PLC, a hard real-time cyclic control architecture based on traditional PLCs that satisfies the requirements of emerging and future CPS applications. By allowing communication with external and geographically distributed data streams, and by providing a mechanism to couple control code with physical simulations, the CPS-PLC architecture accommodates more sophisticated control algorithms to improve the performance of systems. This disclosure also presents a CPS-PLC toolchain that, based on the existing PLC languages, extends their functionality through reusable components in the form of function blocks. Using a smart building CPS application, we demonstrated how our architecture uses a model-based design approach to develop complex control strategies that optimize the energy consumption of a smart building. CPS-PLC is also applicable to a broad range of emerging CPS applications including smart grid and energy applications, for example.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, PvF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article or manufacture including instructions which implement the function act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Referring now to FIG. 5, according to an exemplary embodiment of the present invention, a computer system 501 can comprise, inter alia, a central processing unit (CPU) 502, a memory 503 and an input/output (I/O) interface 504. The computer system 501 is generally coupled through the I/O interface 504 to a display 505 and various input devices 506 such as a mouse and keyboard. The support circuits can include circuits such as cache, power supplies, clock circuits, and a communications bus. The memory 503 can include RAM, ROM, disk drive, tape drive, etc., or a combination thereof. Exemplary embodiments of present invention may be implemented as a routine 507 stored in memory 503 (e.g., a non-transitory computer-readable storage medium) and executed by the CPU 502 to process the signal from a signal source 508. As such, the computer system 501 is a general-purpose computer system that becomes a specific purpose computer system when executing the routine 507 of the present invention.

The computer system 501 also includes an operating system and micro-instruction code. The various processes and functions described herein may either be part of the micro-instruction code or part of the application program (or a combination thereof) which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer system 501 such as an additional data storage device and a printing device.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware -based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular

embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.