Patent Application
20090089029
The subject specification relates generally to simulation of industrial control systems, and more particularly to execution timing management to improve simulation performance.
Simulation and modeling for automation has advanced considerably. In one instance, manufacturers employ simulation for business purposes. While some have utilized simulation to close sales with suppliers, other manufacturers employ simulation for supply chain planning. For example, if it is known how many items are produced for a given line, then it can be determined where production needs to occur and what equipment needs to drive the production while yielding confidence in the final production outcome. Entities can also predict delivery schedules from simulations. Design engineers are using simulation to alter their designs to make products easier to manufacture, whereas many companies are now creating simulations of entire plants before a plant is built or refurbished.
One recent trend is the use of simulation to train plant personnel. There are two main areas where simulation has helped in training. In one, simulation allows less skilled workers to practice and gain experience “operating” plant equipment before taking the reins in the real world. In another, simulated operation offers an accelerated form of training. For instance, input/output (I/O) simulation software provides a shortcut to training on actual equipment that may not even be available at the present time, where training materials can be created from simulated manufacturing design. Training is often considered a secondary use of simulation, but the savings it produces can be considerable nonetheless. Another recent development in simulation mirrors progress in other areas of computer technology: standardization of data. One of the trends in simulation is the ability to share data. Thus, users share data in many directions, from product design and manufacturing to robot simulation and ergonomics, for example.
Three-dimensional modeling is also gaining ground in manufacturing simulation. Three-dimensional modeling first was applied in the aerospace and automotive sectors. Often, designers model robots in 3-D, then select the location for the respective operation such as “weld” and instruct the robot to perform along those lines. As for parameters such as pressure and the robot's maneuverability, such parameters can be built into the simulation and delivered by the robot manufacturer, thus preventing a simulation from inadvertently instructing the robot to perform an operation that is beyond its capabilities. Often times the robots are controlled from one or more industrial controllers that can also be simulated.
When a company has its manufacturing process fully simulated, it becomes easier to analyze a product design and observe how well it performs in a manufacturing setting. Since the design and manufacturing are not yet “live,” there is an opportunity to turn back to the design engineer and request changes before it is cost prohibitive to do so. Such changes at the simulation stage are generally much less costly to implement than at the actual manufacturing stage. Thus, early on in the life of the product, designers can analyze the simulated manufacturing process, and adjust a given product for desired manufacturability. The ability to alter a product design prior to manufacturing in order to cause the entire process work more efficiently offers significant potential savings over the traditional design process. This process is often referred to as front-loading, where a designer can identify glitches in manufacturing through simulation and then facilitate planning on how to overcome such problems. With front-loading, products can be designed so it performs well in the manufacturing simulation which should mitigate problems in actual production thus mitigating overall system costs.
Simulation can also be implemented end-to-end, thus demonstrating how every process in a plant performs together over a designated period of time. For instance, simulation can occur from the IC (industrial controller) level up to warehouse management and other supervisory systems. One area where simulations of the entire plant are taking hold is with new plants or newly refitted plants. Before manufacturers determine what equipment they need and where it should go, they simulate the plant's entire operations. Dynamic simulation thus provides a model for a new plant to ensure the plant is designed properly.
Thus, simulation for industrial control systems offers many benefits-notably the ability to determine viability of a system before expending the resources to implement the systems. Although simulation can reduce the cost of the overall system design by helping to mitigate redesign efforts and overcome unforeseen difficulties, there is a cost in performing the simulation itself. There is a cost in learning how to use a simulation tool and coming up to speed when developing control system models for the tools. Additionally, there is a cost in the processing time it takes to execute a given simulation.
The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
System and methods are provided to facilitate simulation of components of an industrial control system. Simulation execution time can be decreased by conducting the simulation in a parallel computing platform; however, depending on the scenario being modeled, inhibitors for parallelism can be present in the logic of the simulation. Such logic is determined by the relationships between simulated components. In an aspect, an optimization component analyzes the logic of the model that is simulated and identifies inhibitors for parallelism. The optimization component then restructures code modules provided to a simulation component at the time of configuring a simulation scenario, aiming at mitigating said inhibitors. Optimized code(s) and model(s) to execute a simulation can result in a reduction of execution time. Additionally, execution time can be reduced by applying an adaptive time step during simulation of state propagation of devices. Active controls of components that energize and de-energize the state propagation determine whether a time step employed for model propagation is to be adapted. Time adaptation, model reorganization/optimization, as well as distributed computing can be employed concurrently to increase simulation performance.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.
It is noted that as used in this application, terms such as “component,” “module,” “model,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution as applied to an automation system for industrial control. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computer. By way of illustration, both an application running on a server and the server can be components. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers, industrial controllers, and/or modules communicating therewith.
System(s) and method(s) are provided to facilitate simulation(s) of components and processes of an industrial control system. Various strategies for enhancing simulation performance are described hereinafter. A simulation can be deployed in a distributed computing platform, wherein execution time can be decreased by exploiting several computational resources that concurrently perform the simulation. Optimization of code modules that describe a simulation model can be performed based on analysis of the logic of the simulation, as well as identifying computational bottlenecks. Execution time can also be reduced by applying an adaptive time step during state propagations that take place within the simulation. Time adaptation, model reorganization/optimization, as well as distributed computing can be employed concurrently to increase simulation performance as described in greater detail below.
In industrial control processes, scenarios aim at putting forward a time dependent abstraction of the collection of devices and controllers in a particular operation condition—e.g., food processing, beverage packaging, car assembly, and so forth. In reference to
In the case that a client application accesses user interface 120, a scenario would normally be conveyed as output of a configuration script or even as results of a previous simulation. Such results can be stored in the simulation component or in other appropriate component.
Referring back to
Propagation typically corresponds to state transitions, and it generally is associated with time propagation. However, there are scenarios in which the propagation is in configuration space, e.g., a scenario associated with a molecule undergoing deformation due to the application of an external field. In process engineering, configuration space propagation can correspond to reassembling tools, or resources, in a production plant to attain a desired output. Still referring to
It is noted that components (simulated or real) associated with the system 100 can include various computer or network components such as servers, clients, industrial controllers (ICs), communications modules, mobile computers, wireless components, control components and so forth that are capable of interacting across a network. Similarly, the term IC as used herein can include functionality that can be shared across multiple components, systems, or networks. For example, one or more ICs can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, I/O device, sensors, Human Machine Interface (HMI) that communicate via the network that includes control, automation, or public networks. The IC can also communicate to and control various other devices such as Input/Output modules including Analog, Digital, Programmed/Intelligent I/O modules, other programmable controllers, communications modules, sensors, output devices, and the like.
The network can include public networks such as the Internet, Intranets, and automation networks such as Control and Information Protocol (CIP) networks including DeviceNet and ControlNet. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, and so forth. In addition, the network devices can include various possibilities (hardware or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, or other devices.
Display component 235 also presents the results of simulations. Depending on the simulation, display component 235 can render an animation and display graphics and parameter listings simultaneously, or sequentially, depending on user input in response to the animated results. While a simulation is executing, or computing, status data can de rendered in display component 235, to alert an operator of the level of completion of the simulation. Moreover, such display component can simulate end-user characteristics of one or more devices, one or more controllers, or any combination thereof. In this manner, which is similar to the instance in which simulation component 140 simulates the operation of a vehicle (plane, car, train, etc.), where display component 235 presents information according to the typical information a user would be provided with in such vehicle.
Simulation component 140 conducts a simulation as configured with component 225. A computing component 245 executes instructions, and generates and processes data. Data relevant to conduct the simulation (e.g., parameters describing operational limits of devices and controllers, technical specifications of said devices and controllers) and results generated by the simulation are stored in data store 254. Legacy data can also be stored in data store 254, as well as reports generated by simulation component 140 or components linked to it. In an aspect, instructions for a model of a scenario reside in a code module store 251. It should be appreciated that once simulation component 140 determines a model related a received scenario 130, the model is stored in model store 248. Models successfully employed in a simulation become legacy models, which can be used as a part of a new simulation. In particular, models are cast in terms of modules, e.g., control modules, I/O modules, fault time modules, packaging modules, that provides with functionality to simulate a specific aspect of a specific scenario (e.g., scenario 130).
The set of modules employed in a simulation depends on the relationships between the components (e.g., devices and/or controllers) to be modeled, and the logic of such relationships. As discussed above, timing component 160, in conjunction with simulation component 140, can be responsible for increasing/decreasing execution time of a simulation. To the accomplishment of that, timing component 160 employs algorithms that are stored in algorithm store 265. In an aspect, one such algorithm can be based on transforming of an actual time, or timeline, (τ) to a fictitious time, or timeline, (τf) that can be based on scaling (σ) of time steps—e.g., Δτ′=σΔτ, where σ>0 is a real number—that are employed in the time propagation of state transitions. In an aspect, scaling can be accomplished by accelerating or de-accelerating a synchronizing clock to which simulation component can be synchronized. It should be appreciated that depending on the state transition and the logic underlying the relationships between components in a scenario (e.g., scenario 130) being modeled, such time-step scaling may not be feasible as it can corrupt the logic of the simulated process.
In an aspect, in order to manage execution time and accelerate or de-accelerate a simulation, timing component 160 employs an optimization component 265 that facilitates analysis of the relationships between the one or more components (e.g., devices and/or controllers) of the scenario being modeled (e.g., an industrial control system) to infer one or more groups of components are operationally coupled. Operationally coupled components are components that take part in a specific portion of the modeled process conveyed in a scenario (e.g., scenario 130). Furthermore, the optimization component 275 can determine that one or more relationships among components (e.g., devices and controllers) being simulated, and the logic associated with the plurality of conditions describing the relationships (or interactions) among one or more of those components, are inhibitors of a run-time acceleration or de-acceleration. In particular inhibitors can prevent actual-to-fictitious time scaling transformations. In such a case, an optimization component can infer a partially restructured process intended for simulation in a specific scenario (e.g., scenario 130) in order to mitigate acceleration/de-acceleration inhibitors and afford run-time acceleration or de-acceleration of a simulation.
As used above and hereinafter, the term “infer” refers to the ability to reason or draw conclusions about the current or future conditions of a system, based on existing information about the system. Artificial intelligence (AI) can be employed to identify a specific context or action, or generate a probability distribution of specific conditions (e.g., logic in a simulated industrial process that is conductive to time scaling) of a system without human intervention. Artificial intelligence relies on applying advanced mathematical algorithms—e.g., decision trees, neural networks, regression analysis, cluster analysis, genetic algorithm, and reinforced learning—to a set of available data (information) on the system. In particular, an AI-based component, such as optimization component 275, can employ one of numerous methodologies for learning from data and then drawing inferences from the models so constructed, e.g., hidden Markov models (HMMs) and related prototypical dependency models, more general probabilistic graphical models, such as Bayesian networks, e.g., created by structure search using a Bayesian model score or approximation, linear classifiers, such as support vector machines (SVMs), non-linear classifiers, such as methods referred to as “neural network” methodologies, fuzzy logic methodologies, and other approaches that perform data fusion, etc.) in accordance with implementing various automated aspects described herein.
In cases time inhibitors prevent an algorithm (e.g., an algorithm store in algorithm store 265) from using a fictitious timeline to accelerate/de-accelerate execution time, a simulation can be executed in a distributed computing environment, as illustrated in
It should be appreciated that while a master (master processor 383)-slave (processors 3861-386K) configuration is presented in
Simulation component 340 can also access an intermediary optimization component 275 in order to further speed up gains originating in the multiple computational resources 383 and 3861-386K. In an aspect, optimization component 275 facilitates a prototyping (simplified) simulation of one or more components of an industrial control system introduced through a scenario 130. Such a simulation can uncover a plurality of computational bottlenecks—e.g., portions of the process that require access to multiple data generated in disparate portions of the process that are executing at disparate speeds—and one or more inhibitors for parallel computing. Information gathered in a prototyping simulation can (i) be conveyed in display component 235 for a user to reconfigure the simulated process, or for verification purposes in connection with integrity of the simulation (for example, a user can configure a scenario with known computational bottlenecks and verify those bottlenecks with the ones predicted by the prototyping simulation); and (ii) be employed to restructure the distribution of tasks associated with the simulation and the available computational resources 383 and 3861-386K, in order to enhance simulation performance and effectively reduce simulation run-time. Such restructuring is carried out by optimization component 275 and, in an aspect, it consists of redesigning the set of modules employed in the simulation to attain an optimal logic in the industrial process put forward in scenario 130, or it can consist of selecting alternative modules that require less communication between tasks or exploit time management strategies available in timing component 360 (for instance, via algorithms stored in 365). The set of modules describe the operability of the components (e.g., one or more devices or one or more controllers) in the scenario. Both cases, (1) selection/redesign of modules and (2) exploitation of time management strategies, can result in accelerated simulation execution time. These cases are discussed next.
(1) It should be appreciated that selecting/redesigning modules based on prototyping simulations (termed here “module prototyping”) can entail generating new modules (or generally code), with appropriate inheritance and data structures.
(2) In connection with strategies for time management mentioned above, an accelerated execution can arise from an adaptive time step with feedback algorithm (ATSWFA) described herein. Such algorithm is based on event driven simulations of multi-state components. ATSWFA can remove computational bottlenecks associated with state propagation that are pseudopassive. A pseudopassive state propagation can be one that requires rare, asynchronous control events. Examples of pseudopassive propagation include: filling a mixing tank or beverage container, conveyor belt transportation, paint drying stage in a car assembly line, etc. Such processes can need active control in the event a fault timer issues an alarm. Considering the case of filling a beverage container, the process need not require active control unless a dispenser issues a fault timer indicating the dispenser failed to energize or de-energy (see
The information regarding lack of active control can be fed back to a simulation component (e.g., simulation component 140), which can subsequently adapt the time step Δt to reflect the absence of active control—e.g., Δt1 525, Δt2 530, and Δt3 535, which span the pseudopassive time span τP 540. Thus, actual number of steps (3 in case illustrated in
Another facet of timing management of a simulation execution is increasing execution time.
The advantage of employing a data-packet switched delay is that computational resources at simulation component 140 and timing component 160 are not consumed during the pause that takes place between indicating to timing component 160 to transmit a data packet. Upon the data packet returning to simulation component 140, the simulation that requested the delay can proceed. Alternatively, data packet can be communicated by simulation component 140 to delay node 630, bypassing time component 160. Communication of the data packet to delay node 630 can be asynchronous and non-blocking. Depending on the nature of the delay, e.g., length, originating instruction, and so on, data packet can be conferred intelligence and carry a set of instructions to execute in delay node 630. Such instructions can run a specific loop for a specific length of time and return to simulation component 140, but other instructions are also possible.
As an alternative to data-packet transmission for effecting a simulation execution delay, simulation component 160 can receive or acquire, from timing component 160 or a networked machine (e.g., delay node 630), a specific time delay upon initiating a simulation. For instance the time delay can be conveyed in relative terms with respect to real-time simulation execution, e.g., “run ⅕ real time.”
In view of the example systems shown and described above, methodologies that may be implemented in accordance with the disclosed subject matter, will be better appreciated with reference to the flowcharts of
At act 720, a model to simulate one or more components of the industrial control system described in the scenario is selected. Selection of a model is primarily based on the operational characteristics of the one or more components to be described and their interactions. In an aspect, code modules describe the operability of the one or more components (e.g., devices and/or controllers). In another aspect, a model is also selected so as to describe a behavior of the one or more devices, controllers, or a combination thereof. Behavior as used herein can encompass equipment (e.g., a device such as a robotic arm, or a furnace) response as part of a process controlled by the industrial control systems characterized in a scenario (e.g., scenario received at 710). Such responses include triggering alarms, setting up electric fields, controlling temperatures, igniting motors, and so on.
At act 730, execution time to simulate the one or more components being modeled is reduced or extended. Various aspects discussed in connection with
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system bus 1018 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 8-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 1016 includes volatile memory 1020 and nonvolatile memory 1022. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1012, such as during start-up, is stored in nonvolatile memory 1022. By way of illustration, and not limitation, nonvolatile memory 1022 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. Volatile memory 1020 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 1012 also includes removable/non-removable, volatile/non-volatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 1012 through input device(s) 1036. Input devices 1036 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1014 through the system bus 1018 via interface port(s) 1038. Interface port(s) 1038 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1040 use some of the same type of ports as input device(s) 1036. Thus, for example, a USB port may be used to provide input to computer 1012, and to output information from computer 1012 to an output device 1040. Output adapter 1042 is provided to illustrate that there are some output devices 1040 like monitors, speakers, and printers, among other output devices 1040, which require special adapters. The output adapters 1042 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1040 and the system bus 1018. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1044.
Computer 1012 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1044. The remote computer(s) 1044 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1012. For purposes of brevity, only a memory storage device 1046 is illustrated with remote computer(s) 1044. Remote computer(s) 1044 is logically connected to computer 1012 through a network interface 1048 and then physically connected via communication connection 1050. Network interface 1048 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 1050 refers to the hardware/software employed to connect the network interface 1048 to the bus 1018. While communication connection 1050 is shown for illustrative clarity inside computer 1012, it can also be external to computer 1012. The hardware/software necessary for connection to the network interface 1048 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
Various aspects or features described herein may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . optical disks [e.g., compact disk (CD), digital versatile disk (DVD) . . . ], smart cards, and flash memory devices (e.g., card, stick, key drive . . . ).
Moreover, as used in the subject application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
