Patent Application
20090089234
The claimed subject matter relates generally to industrial control systems and more particularly to automatically generating deployable runtime code from simulation models.
Simulation and modeling for automation has advanced considerably in recent years. 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 has gained 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 programmable 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 to 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 manufacturing glitches 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 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.
Prior to implementing an industrial control program, simulations are often performed in an offline manner to determine projected performance for a particular control system. The simulation process often includes manually designing code or other modules that perform a given simulation and drive the actual production equipment. However, it is not economically practical to continually develop models or other types of simulation code from scratch. Programmers face an enormous amount of tedious work when they must repeatedly develop run-time code from scratch after simulations have been developed and executed.
The following summary presents a simplified overview of the invention to provide a basic understanding of certain aspects of the invention. This summary is not an extensive overview of the invention. Nor is the summary intended to identify critical elements of the invention or delineate the scope of the invention. The sole purpose of this summary is to present some features offered by the invention in a simplified form as a prelude to a more detailed description presented later.
Industrial automation simulation tools are provided that automatically generate code modules or models that are employed in the context of an industrial control simulation environment. Re-usable simulation instructions or add-on instructions can be provided to facilitate construction of an overall simulation model. After the respective model has been executed to desired satisfaction, actual industrial controller (IC) code or other type instructions can be automatically generated and loaded on run time equipment. This can include providing instruction templates for integrating into a given environment such as providing suggested code or integration instructions for interfacing one type of equipment with another e.g., integrating a drives package with an industrial controller and generating the instructions for the drive and respective controller. Actual code objects can be automatically generated to run a simulation on actual equipment, automatically generated after a simulation and downloaded to the equipment, or generated in a report format in order to verify a given system such as for highly regulated industries.
To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth in detail certain illustrative aspects of the invention. These aspects are indicative of but a few of the various ways in which the principles of the invention may be employed. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
A reduced subset of simulation and code generation components is provided to mitigate manual coding requirements that often accompany the process of simulating and implementing new control devices (such as industrial controllers) in an industrial control environment. In one aspect, a system that generates deployable runtime code modules is provided. The system includes an input component that accepts specifications in accordance with a user's desires, a simulation component that creates and executes a simulation of the control program to be implemented, and a code generation component that creates the deployable runtime code.
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 or thread of execution and a component may be localized on one computer or distributed between two or more computers, industrial controllers, or modules communicating therewith.
Referring initially to
A simulation component 130 constructs and executes simulation models in accordance with the specifications 110 set forth by the input component 120 as well as a cross-section of real time variables (e.g., a range of operating temperatures, variations in materials such as thickness, properties, and so forth) that inherently occur in an industrial control setting. The simulation component 130 also identifies suitable process control equipment (e.g., a batch server, an industrial controller, individual devices, I/O, and so forth), process control steps, or methodologies to accomplish the manufacture of a particular item.
When the simulation component 130 identifies the components or methodologies, it defines simulation models for the respective components or steps. Simulation models may be stored in a simulation database (not shown) that includes a history of simulations that have been previously run. It is to be noted that such simulation database may be accessed through remote connections such as the Internet. Other simulation models may be formed based on logic, historical simulation models, the user specification, or artificial intelligence. Alternatively, the simulation component 130 may prompt the user for a simulation model that is not found within the database, difficult to generate, or specific to the user.
When the simulation models have been identified and gathered, the simulation component 130 executes a simulation based on the simulation models, stores and returns the result of the simulation. By storing the results of the simulations, users can quickly identify failed or successful simulations, as well as simulation models that are similar to the current simulation for comparative purposes. If a problem occurs during simulation or the simulation fails, the simulation component 130 identifies the particular simulation models that were the root of the failure. In one aspect, the simulation component 130 simulates to the smallest level of granularity to facilitate the most accurate simulation possible. However, if a particular combination of simulation models has been run repeatedly, the simulation component 130 can identify this through the simulation database, notify the user that a repeated simulation has been executed, and refrain simulating that portion of the model (perhaps after prompting the user for permission).
A code generation component 140 creates deployable runtime code modules 150 that are employed to drive various controller components 160 throughout the industrial automation environment. The code generation component 140 receives results from simulation component 130 to automatically create the runtime code modules 150. In one aspect, the runtime code modules 150 may be obtained by translating the simulation models into the appropriate controller or device specific language modules. This may include ladder logic that drives industrial controllers, Sequential Function Charts, operational parameters or settings, programming language (e.g., C++, Java, assembly, and so forth) code to control various types of processors or other equipment. The code generation component 140 may generate several options for the user to select that may not fall within the user specifications but otherwise emphasize optimum or potential performance capabilities for the industrial automation system.
For example, the code generation component 140 can operate with a translation component (not shown) that will be described in more detail below. The translation component can map a code module that performs a desired function with a component of the simulation that corresponds to a portion of the specification 110. If a particular simulation component were a industrial controller processor that controlled a mixing operation for example, the translation component can map controller code or other parameters associated with a mixing process from the resultant simulation of such mixing. Code modules 150 can be collected and stored over time (according to various processes or functions) or automatically generated as will be described in more detail below.
It is to be appreciated that the code generation component 140 may be linked to the controller components 160 via various networks. The industrial control system 100 may employ such a connection by automatically implementing generated runtime code modules 150 in substantially any controller component 160 that is associated with the code generation component 140. For example, the simulations and code generation may occur on a computer located in the factory control room, where the computer is connected to the mainframe that oversees production in the factory. After a successful simulation has been run, and the runtime code generated, the user can program the mainframe with the updated runtime code and re-program selected industrial controllers to operate under the new specifications. Alternatively, an operator may load the deployable runtime code modules manually if the controller components 160 are not remotely accessible.
Additionally, the code generation component 140 can track and log actual industrial controller activity or responses and compare the actual data from the deployable runtime code modules that have been implemented to the simulation models. This provides a feedback loop with a record of simulation accuracy from past simulations and offers the user a continually updated database for improving correlation between simulation model results and real life occurrences. Statistical tools may then be used to estimate the accuracy of a particular simulation upon initial implementation of the runtime code modules. In another aspect, the system 100 is employed to automatically generate executable control code. This can include means for defining one or more specifications of a control system (input component 120) and means for simulating the specifications (simulation component 130). This can also include means for generating run time code (code generation component 140) from simulation of the specifications.
It is noted that components 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 controllers 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 controller 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.
Referring now to
Alternatively, the user interface 200 could automatically fill the parameter box labels for the user if existing parameters are commonly used. The user interface 200 could communicate with a database component (not shown) to determine possible parameters, parameter ranges, and parameter limits. Upon retrieval of the parameter data, the user interface 200 can present this information to the user in the form of a parameter box label 210 and a parameter field drop down selection box 220.
For instance, an industrial controller that controls a motor may be expected to have different operating speed settings or revolutions per minute (RPM) settings. First, the user interface 200 would communicate with the database component and determine the variables that could be included as parameters such as input voltage, operating speed (RPMs), and torque. User interface 200 may determine that the motor could accept three input voltage levels: low, nominal, and high, for example. The user interface 200 may further determine that the motor outputs run at either a low or high level of torque and that it can run between five hundred and one thousand RPMs. Upon determination of the parameter data, user interface 200 automatically labels parameter box 210 with an “Input Voltage” label and creates a drop down box in field box 220 that lists the three possible settings for the user to choose. Similarly, user interface 200 could label parameter box 230 as “Torque” and create a drop down box with the two possible settings from which the user could choose. Again, user interface 200 would automatically label parameter box 250 as “RPM setting”. In this situation, however, field box 260 could be left blank and the user interface 200 could prompt the user to input an RPM number between five hundred and one thousand.
It is to be noted that the claimed subject matter is not limited to parameters that are stored within a database. The user may input parameters that do not directly correspond to a particular component. For instance, a user could provide a parameter that recites output of one hundred units per day. The user interface 200 may facilitate the implementation of such a parameter through the determination of suitable process control equipment or processes (to be described in more detail below).
Turning to
The input component 320, 370 accepts and stores the specifications 302, 342 from the user for later use. In one aspect, the user enters the specifications 302, 342 into a computer terminal (that represents the user interface 310, 360) with a plurality of fields that pertains to different parameters regarding the user specification.
In another aspect, the user links the input component 370 to a database 340 that houses the specifications 342 and the specifications are accessed or downloaded as the need arises. In yet another aspect, the input component 320, 370 automatically generates the specification by analyzing historical data trends or by anticipating user specifications. It is to be appreciated that data utilized to facilitate automatic generation of specification 302, 342 can be housed within database component 340 or accessed through a network such as the Internet.
The input component 320 or 370 can determine if additional specifications would be needed to facilitate simulation and automatic code generation. If the user provides a high-level set of instructions as the specification, the input component 320, 370 can decompose the high-level specification into sub-parameters as the need arises. Decomposition can occur through a variety of techniques and the following examples are not intended to limit the scope of the invention. A logic component (not shown) can be used to determine suitable sub-parameters based on process control equipment to be used or processes to be implemented (described in more detail below). Database 340 stores the results of parameter decomposition to access for later use. For example, if a controller drives a motor, and the user submits a specification that includes a parameter calling for the motor to run at one thousand RPMs and the motor must have an input voltage of 12V to do so, the input component 320, 370 can utilize logic to associate the user specification with the known properties of the motor and return the additional parameter of 12V to the user interface 310. Similarly, if the user submits a specification 302, 342 of one hundred units of production per day, the input component 320, 370 may recognize that two processes are required to complete manufacture of a unit and that each process takes twenty-four hours to complete and thus, notify the user that the specification is not feasible through the current setup due to the time limitation. If it would be possible to meet a specification through the purchase of additional manufacturing equipment, or removal of a certain limitation, the input component 320 or 370 can notify the user of such possibility.
In accordance with another aspect, the input component 320, 370 can utilize artificial intelligence component (not shown) to automatically infer parameters to suggest to the user. The artificial intelligence (AI) component can include an inference component (not shown) that can further enhance automated aspects of the AI components utilizing, in part, inference based schemes to facilitate inferring intended parameters. The AI-based aspects can be effectuated via any suitable machine learning based technique or statistical based techniques, or probabilistic-based techniques or fuzzy logic techniques. Specifically, the AI is provided to execute simulation aspects based upon AI processes (e.g., confidence, inference). For example, a process for defining a parameter can be facilitated via an automatic classifier system and process. Furthermore, the AI component can be employed to facilitate an automated process of creating a parameter in accordance with historical user trends.
Referring to
If more than one component or process may be used to effectuate manufacture of a particular item, then the simulation component 402 employs logic component 450 to determine which component or process model to use. Logic component 450 can present business related information to the user to assist with the determination of the decision. For instance, logic component can present information to the user including cycle time for the product, costs associated with the process, level of automation of the process (e.g. how much babysitting operators will have to do), or amount of waste produced, and so forth.
When the identifier component 440 has identified the components or methodologies and defined simulation models for the respective components or steps, the simulation component 402 constructs, executes, and stores simulation results based upon the simulation models identified, as well as a cross-section of real-time variables (e.g., a range of operating temperatures, variations in materials such as thickness, properties, tolerance of materials, and so forth) that inherently occur in an industrial control setting. The real-time variables are stored in the database component 444, where the simulation component 402 generates and executes a separate simulation model for a given set of conditions. If a problem occurs during simulation or the simulation fails, the simulation component 402 identifies the particular simulation models that were the root of the failure. Generally, the simulation component simulates to the smallest level of granularity to facilitate the most accurate simulation possible.
The executed simulation models are then stored in database component 444 to provide a history of previously run simulation results. By storing the results of the simulations, users can quickly identify failed or successful simulations, as well as simulation models that are similar to the current simulation for comparative purposes.
To streamline future access, the database component 444 associates historical simulation results with simulation model components or process steps, associated components or process steps, and specification parameters that the simulation model may have been derived from. However, if a particular combination of simulation models has been run repeatedly, the simulation component 430 can identify this through the simulation database 410, notify the user that a repeated simulation has been executed, and refrain simulating that portion of the model after prompting the user for permission. This enables users to access a simulation history efficiently and circumvent costs or inefficient use of time associated with duplicate or even substantially similar simulations. Note that if multiple manufacturing paths exist, the simulation component 402 can simulate various paths and present the user with several options.
Alternatively, the simulation component 402 may prompt the user for a simulation model that is not found within the database, difficult to generate, or specific to the user. It should be appreciated that the user may provide such simulation model through a network such as the Internet. Simulation models may also be formed based on logic or artificial intelligence. In addition to logic component 450 or in place of the logic component described with reference to the system 400, the simulation component 402 can include an artificial intelligence (AI) component 460.
In accordance with this aspect, the AI component 460 automatically generates various simulation models. For example, if manufacture of an item incorporates processes A and B, and process A comprises steps C and D, while process B comprises steps E and F, AI component 460 can generate a simulation model that incorporates C, D, E, and F or combination thereof. The AI component 460 can include an inference component (not shown) that further enhances automated aspects of the AI components utilizing, in part, inference based schemes to facilitate inferring intended simulation models. The AI-based aspects of the invention can be effected via any suitable machine learning based technique or statistical-based techniques or probabilistic-based techniques or fuzzy logic techniques. Specifically, AI component 460 can implement simulation models based upon AI processes (e.g., confidence, inference). For example, a simulation model can be generated via an automatic classifier system and process which is described in further detail below.
A classifier is a function that maps an input attribute vector, x=(x1, x2, x3, x4, xn), to a confidence that the input belongs to a class, that is, f(x)=confidence(class). Such classification can employ a probabilistic or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. In the case of standing query creation and designation, for example, attributes can be file types or other data-specific attributes derived from the file types or contents, and the classes can be categories or areas of interest.
A support vector machine (SVM) is an example of a classifier that can be employed for AI. The SVM operates by finding a hypersurface in the space of possible inputs, which hypersurface attempts to split the triggering criteria from the non-triggering events. Intuitively, this makes the classification correct for testing data that is near, but not identical to training data. Other directed and undirected model classification approaches include, e.g., naïve Bayes, Bayesian networks, decision trees, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.
As will be readily appreciated from the subject specification, simulation tools can employ classifiers that are explicitly trained (e.g., via a generic training data) as well as implicitly trained (e.g., via observing user behavior, receiving extrinsic information). For example, SVM's can be configured via a learning or training phase within a classifier constructor and feature selection module. In other words, the use of expert systems, fuzzy logic, support vector machines, greedy search algorithms, rule-based systems, Bayesian models (e.g., Bayesian networks), neural networks, other non-linear training techniques, data fusion, utility-based analytical systems, systems employing Bayesian models, etc. are contemplated and are intended to fall within the scope of the hereto appended claims.
Other implementations of AI could include alternative aspects whereby based upon a learned or predicted user intention, the system can generate hierarchical notifications or prompts. Likewise, an optional AI component could generate multiple prompts to a single or group of users based upon the received content.
Turning now to
In addition to the resultant deployable runtime code module 532, artificial intelligence component 570 facilitates generating additional runtime code modules that may not fall within user specifications. These additional code modules optimize aspects of that the user may not have taken into account when submitting their specification. For example, AI component 570 may factor cycle time, costs associated with manufacture, level of automation, amount of waste produced, historical user trends, anticipated user desires through interpolation or extrapolation, etc. into determining which aspect to optimize in the additional code module.
The code generation component 530 includes an implementation component 550 that links the code generation component to various controller components throughout a factory. One possible aspect involves linking deployable runtime code module 532 to the controller components via a network. An industrial control system can program the automatically generated runtime code modules in controllers linked to the code generation component 530. Alternatively, an operator may load the deployable runtime code modules 532 manually if the controller components are not remotely accessible.
A monitoring component 560 is also provided to track and log actual controller activity or responses and compare the actual results from implementation to the simulation models. This comparison provides a record of simulation accuracy and offers the user a continually updated database for improving correlation between simulation model results and real life occurrences.
Turning now to
A code generation component 810 generates deployable runtime code module 840. An implementation component 844 then uploads the runtime code module 840 to controller components 850. Controller components 850 then provide feedback to monitoring component 860. The monitoring component 860 stores actual activity or responses from the controller to database 804 and associates the activity with the simulation results. Artificial intelligence (AI) component 870 can then calculate a comparison between the actual response and the simulation results. Upon determination of the comparison, the AI component 870 re-calculates a new version of the simulation model associated with the implementation of the deployable runtime code module 840 and compensates for the difference. For example if a controller drive controller is supposed to operate at one thousand RPMs and draw fifty milliamps of current, monitoring component might indicate that the RPM rate at which the motor is operating is nine hundred and ninety RPMS and that the motor is drawing fifty eight milliamps of current. In this situation, the AI component 870 will update simulation database 860 with a new simulation model (not shown) that accurately reflects the actual amount of current being drawn. Monitoring component 830 can also prompt the user to provide a new simulation model to account for discrepancies between the simulation model and the implemented runtime code module. Alternatively, the user can modify the simulation model with a compensation factor (e.g. real life variables such as friction, heat, and so forth).
At 910, the process receives a set of specifications as an input to the process. The specifications can include user design preferences, performance specifications, or target operating objectives, for example. The specifications can be automatically generated or retrieved from a database or network, such as the Internet. Proceeding to 920, the process then identifies possible methods or components suitable to accomplish manufacture of a desired item. At 930, identified methods or components are associated with a corresponding simulation model. It should be appreciated that artificial intelligence can be used to generate a simulation model for a component or process step that does not have a corresponding simulation model. At 940, simulation models for the suitable processes and components are collected and a simulation is executed. At 950, a deployable runtime code module is generated based on the results of the simulation executed at step 940.
The subject matter as described above includes various exemplary aspects of the subject invention. However, it should be appreciated that it is not possible to describe every conceivable component or methodology for purposes of describing these aspects. One of ordinary skill in the art may recognize that further combinations or permutations may be possible. Various methodologies or architectures may be employed to implement the subject invention, modifications, variations, or equivalents thereof. Accordingly, all such implementations of the aspects described herein are intended to embrace the scope and spirit of subject 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.
