IN A PROGRAMMABLE LOGIC CONTROLLER

TECHNICAL FIELD

[0001] The present invention relates generally to the semantic contextualization of automation system data in a programmable logic controller. The disclosed technology may be applied to, for example, various automated production environments where programmable controllers are used.

BACKGROUND

[0002] A programmable logic controller (PLC) is a specialized computer control system configured to execute software which continuously gathers data on the state of input devices to control the state of output devices. A PLC typically includes three major components: a processor (which may include volatile memory), volatile memory comprising an application program, and one or more input/output (I/O) ports for connecting to other devices in the automation system. PLCs are utilized in various industrial settings to control automation systems. Automation systems typically generate a large amount of data in their daily operations. This data may include, for example, sensor data, actuator and control program parameters, and information associated with service activities.

[0003] Due to the ever increasing number of sensors and actuators installed in today's automation systems, the amount of data describing the underlying technical processes and control is growing. This data includes, for example, control input variables (e.g., sensors) and output variables (e.g., actuators), their historical data, as well as a description of the state of the control process. There is a huge potential to utilize this data to gain additional insights into the evolution and effectiveness of the processes and this data can be used for enhancements and optimization of the process, for example, through data analytics methods. However, is extremely difficult to make sense of the (potentially) available data if the context of data generation is not known. Contextual information that may be useful in understanding the data may include, for example, the location and specification of the sensor that generated the data, the function of the actuator the data refers to, the causal dependence of several related data items, an identifier of the product or batch that was processed when the data was generated, the description of the maintenance task that was executed shortly before the data is generated, the specific part of the control program that the data refers to, etc.

[0004] In conventional systems, contextual knowledge is statically defined by the application engineer during development of data analytics algorithms. That is, the application engineer codes analytics algorithms based on his or her knowledge of the contextual data that is available in the system. However, these conventional systems have several drawbacks. As an initial matter, at design and installation time, there is a huge effort required to specify what information should be contextualized, how it should be captured, and how it should be formalized. Moreover, the resulting analytics applications using the contextualized data are specific to a particular customer and/or domain; there is no standardization such that these applications may be reused without additional customization. Additionally, changes in the underlying automation infrastructure (e.g., adding a new sensor) require manual effort to adapt existing applications. Furthermore, even where contextual data is available, conventional systems typically do not make it available in a format that is easily provided to service providers and other third parties.

SUMMARY

[0005] Embodiments of the present invention address and overcome one or more of the above shortcomings and drawbacks, by providing methods, systems, and apparatuses related to adding context to data using semantic models expressed in a standardized, formal, domain- independent language directly when data is generated. At this point, the context is still known and made persistent for later analyses. This technology is particularly well-suited for, but not limited to, various industrial automation settings.

[0006] According to some embodiments of the present invention, a method of contextualizing automation system data in an intelligent programmable logic controller ("Intelligent PLC") includes the controller collecting automation system data and creating a structured representation of the automation system data. The Intelligent PLC selects a semantic context model from a plurality of available semantic context models based on relevance to the structured representation of the automation system data and creates semantically contextualized data using the semantic context model and the structured representation of the automation system data. The semantically contextualized data is stored by the Intelligent PLC on a non-volatile computer-readable storage medium operably coupled to the Intelligent PLC.

[0007] The characteristics of the semantically contextualized data used in the aforementioned method may vary according to different embodiments of the present invention. For example in some embodiments, the semantically contextualized data is created using the semantic context model and the structured representation of the automation system data by generating the semantically contextualized data as instances of an ontology associated by the semantic context model. In some embodiments, the semantically contextualized data is expressed using Resource Description Framework or Web Ontology Language (OWL). The semantically contextualized data in these embodiments may also be stored in a triplestore located on the non-volatile computer-readable storage medium operably coupled to the Intelligent PLC.

[0008] Furthermore, the aforementioned method may be enhanced and/or refined with additional features in some embodiments of the present invention. For example, in one embodiment, a sensor associated with generating the automation system data is identified, along with an ontological entity in the semantic context model related to the sensor. The semantically contextualized data then comprises an indication of a mapping between the sensor and the ontological entity. In some embodiments, the Intelligent PLC updates an active window of an event engine based on the automation system data. The event engine may then generate new events based on data in the active window. When the Intelligent PLC detects new events, it may automatically retrieve stored contextualized data associated with the new event from the nonvolatile computer-readable storage medium operably coupled to the Intelligent PLC. Then, the Intelligent PLC may write the new event and the stored contextualized data to an event table. In some embodiments, the Intelligent PLC is configured to receive and respond to queries for data. For example, in one embodiment, the Intelligent PLC receives a request for contextualized data stored in the non-volatile computer-readable storage medium, formulates a query based on the request and the semantic context model, and retrieves response data from the non-volatile computer-readable storage medium based on the query.

[0009] The aforementioned method may also be applied to articles of manufacture. For example, in some embodiments of the present invention, an article of manufacture for contextualizing automation system data in an Intelligent PLC, includes a non-transitory, tangible computer-readable medium holding computer-executable instructions for performing the aforementioned method, with/or without the additional features set out above.

[0010] In some embodiments, an Intelligent PLC may be configured with components for contextualizing automation system data. For example, in one embodiment, an Intelligent PLC includes a processor configured to execute according to a scan cycle, a volatile computer- readable storage medium comprising a process image area, a non-volatile computer-readable storage medium; and controller components executed by the processor according to the scan cycle. The controller components include a data transfer component, a contextualization component, and a historian component. The data transfer component is configured to update the process image area during each scan cycle with contents comprising automation system data. The contextualization component is configured to create a structured representation of the automation system data, select a semantic context model from available semantic context models based on relevance to the structured representation of the automation system data, and create semantically contextualized data using the semantic context model and the structured representation of the automation system data. The historian component is configured to store the semantically contextualized data on the non-volatile computer-readable storage medium. These components may be configured with additional features, similar to those discussed above with respect to the aforementioned method of contextualizing data.

[0011] Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The foregoing and other aspects of the present invention are best understood from the following detailed description when read in connection with the accompanying drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments that are presently preferred, it being understood, however, that the invention is not limited to the specific instrumentalities disclosed. Included in the drawings are the following Figures: [0013] FIG. 1 provides a system view of an Intelligent PLCs integrated into an automation system, according to some embodiments of the present invention;

[0014] FIG. 2 provides an illustration of the system components included in an Intelligent PLC, according to some embodiments of the present invention;

[0015] FIG. 3 provides a process in which contextualized data is generated, stored, and utilized by an Intelligent PLC, according to some embodiments of the present invention;

[0016] FIG. 4A provides a view of a graphical user interface (GUI) referred to herein as a "Smart Data Browser" which provides ontological information used in the contextualization of automation data, according to some embodiments of the present invention;

[0017] FIG. 4B provides an alternate view of the Smart Data Browser where fault data is presented, according to some embodiments of the present invention; and

[0018] FIG. 5 provides an example of a product ontology file in RDF/XML syntax as may be utilized according to some embodiments of the present invention.

DETAILED DESCRIPTION

[0019] Systems, methods, and apparatuses are described herein which relate generally to the use of standardized, formal modeling languages (e.g., Semantic Web standards such as RDF(S), OWL) within automation devices such as programmable logic controllers to annotate and contextualize automation system data. In various embodiments of the present invention techniques are described for defining and representing contextual information that may be used to perform on-line analytics of control specific time series data, and reason about the state and condition of context elements. This contextual information may be used, for example, to enhance control execution with on-line analytics and reasoning. Semantic contextualization on the automation level enables adding additional context information which is not available on higher levels such as, for example, control context. Additionally, in some embodiments, standardized interfaces (e.g., SPARQL) may be used to access contextualized information generated and/or stored on the automation devices. [0020] Various embodiments of the present invention are described in the context of a PLC which includes various components configured to provide an assortment of enhanced functions in control applications. This PLC, referred to herein as an "Intelligent PLC" is described in greater detail in U.S. Application No. 14/467,125 entitled "Intelligent Programmable Logic Controller," the entirety of which is incorporated herein by reference. Briefly, the Intelligent PLC offers several technical features which may be present in various combinations and used in different embodiments of the present invention. The Intelligent PLC provides efficient data storage on control layer devices. More specifically, functionality of the control layer may be extended by an efficient storage mechanism for time series data (i.e., a "historian" function) which allows short-/mid-term archiving of high resolution time-stamped data. With high fidelity data, no events are lost. Efficient compression algorithms (e.g. a variation of swinging door) may be used to reduce storage and communication demands. The Intelligent PLC may also offer an intelligent on-device data generation method in some embodiments. Methods for data filtering may be applied directly where data is generated to ensure that additional data is only stored if it provides additional information content. These methods may also actively analyze incoming data and configure data acquisition according to the current needs, for example, by adjusting the sample rate or by storing data only if certain events have been detected. The Intelligent PLC may also enable rich and semantic contextualization, and perform control layer semantic analytics. Additionally, in some embodiments, the Intelligent PLC also provides distributed analytics across automation systems.

[0021] FIG. 1 provides a system view of an Intelligent PLCs integrated into an automation system 100, according to some embodiments of the present invention. This example conceptually partitions the industrial environment into a Production Layer 105, a Control Layer 1 10, and an IT Layer 1 15. In conventional systems, most data handling functions are performed at the IT Layer 1 15. Using the Intelligent PLCs 1 10E and 1 10F, the system 100 illustrated in FIG. 1 pushes many of these data handling functions down to the Control Layer 1 10. For example, in some embodiments, historian capabilities such as efficient data compression for time-series data and intelligent filtering of data may be implemented directly on the Intelligent PLCs 1 10E and 1 1 OF. This allows the Control Layer 1 15 to utilize high-fidelity data with less storage/communication effort such that few, if any, events go undetected. In some embodiments, the Intelligent PLCs 1 10E and 1 1 OF also provide rich contextualization functionality. By adding control level knowledge to data, it may not be necessary to re-discover knowledge on Business Analytics 1 15C at the IT Layer 1 15. Additionally, in some embodiments, the Intelligent PLCs 1 10E and 1 1 OF provide data analytics functionality directly on their respective device, thus increasing machine and process efficiency.

[0022] Continuing with reference to FIG. 1 , at the Production Layer 105, one or more production units (e.g., Unit 105A) operate. Each production unit sends and receives data through one or more field devices (e.g., Field Device 1 10A) at the Control Layer 1 10. At the Control Layer 1 10, each field device may be connected to an Intelligent PLC (e.g., Intelligent PLC 1 10E). Data received from the production units is transferred (either directly by the field devices or via an Intelligent PLC) to the IT Layer 1 15. The IT Layer 1 15 includes systems which perform various post-processing and storage tasks. The example of FIG. 1 includes a Supervisory Control and Data Acquisition (SCAD A) Server (or Gateway) Component 1 15A. This Component 1 15A allows an operator to remotely monitor and control the devices at the Control Layer 1 10 and Production Layer 105. Additionally, the SCADA Server Component 1 15A collects data from the lower layers 105, 1 10 and processes the information to make it available to the Unified Plant Knowledge Warehouse 1 15B. The Unified Plant Knowledge Warehouse 1 15B provides further processing and storage of the data received from the lower layers 105, 1 10. Various functionality may be provided by the Unified Plant Knowledge Warehouse 1 15B. For example, in some embodiments, the Unified Plant Knowledge Warehouse 1 15B includes functionality for generating analytics based on the data generated by the lower layers 105, 1 10.

[0023] Each Intelligent PLC 1 10E and 1 10F includes three basic portions: one or more processors, a non-transitory, non-volatile memory system, and a data connector providing input/output functionality. The non-volatile memory system may take many forms including, for example, a removable memory card or flash drive. The non-volatile memory system, along with any volatile memory available on the PLC is used to make data accessible to the processor(s) as applications are executed. This data may include, for example, time-series data (i.e., history data), event data, and context model data. Applications that may execute within the Intelligent PLCs 1 10E and 1 10F are described in greater detail below with reference to FIG. 2. [0024] The data connector of Intelligent PLC 1 10E is connected (wired or wirelessly) to Field Devices 1 10A and HOB. Similarly, the data connector of Intelligent PLC 1 10F is connected to Field Devices HOC and HOD. Any field devices known in the art may be used with the Intelligent PLC described herein. Example field devices that may be used with the Intelligent PLC include, without limitation, pressure switches, sensors, push buttons, flow switches, and level switches. Note that the Intelligent PLCs 1 10E and 1 1 OF may be integrated into the production environment piecemeal. For example, in FIG. 1 , Production Units 105B and 105C are connected through their respective field devices to Intelligent PLCs 1 10E and 1 1 OF, while Production Units 105 A and 105D communicate directly through their respective Field Devices 1 10G, 1 10H, 1 101, 1 10J to the Unified Plant Knowledge Warehouse 1 15B.

[0025] In some embodiments, the Intelligent PLC 1 10E and 1 1 OF may gather, store, and process contextual knowledge associated with the automation data being generated by the system 100. As described in greater detail below with respect to FIG. 2, this context knowledge may include, for example, control knowledge, environmental conditions, and service incidences. Context information can be assigned statically as well as dynamically to data (e.g., contextualization via events detected in an incoming data stream or situations observed in the system environment). In some embodiments, this context information is specified using semantic models expressed in standardized, formal, domain-independent languages. For example, in one embodiment, knowledge representation Semantic Web standards are used. These standards provide a formal language to introduce classes and relations whose semantics are defined using logical axioms. One example of such a knowledge representation formalism is an "ontology" formalized with OWL or RDF(S). In contrast to traditional database systems, the Semantic Web technologies require no static schema. Therefore, models can be dynamically changed and data from different sources (e.g., automation devices) can be easily combined and semantically integrated. Interfaces for accessing and manipulating contextualized data within each respective Intelligent PLC may be defined based on well-established standards (e.g., W3C consortium, IEEE). Because contextualization is done where data is generated, insights can be made from data analytics with higher confidence and quality. For example, in some embodiments, the system 100 may provide model-based semantic analytics of automation data at the Control Layer 1 10 which incorporate contextual knowledge of the system 100. [0026] FIG. 2 provides an illustration of the system components 200 included in an Intelligent PLC, according to some embodiments of the present invention. Process Image Component 225 is a memory area in a controller's CPU volatile system memory which is updated in each processing/scan cycle based on data associated with the production devices (e.g., the inputs and outputs of connected I/Os). The Process Image Component 225 may include various information related to the system. For example, the various sensors and actuators provide time series data such as measurements from physical processes. The Process Image Component 225 may include "soft sensors" data, which are calculated time series from other underlying virtual or physical sensors, control program variables, or auxiliary variables to describe the state of the control program. Soft-sensor data is described in greater detail in PCT Application No. PCT/US 14/63105 entitled "Using Soft-Sensors in a Programmable Logic Controller" the entirety of which is incorporated herein by reference. Multiple Processors may be used to gather data from I/O interfaces (and potentially also from external servers), execute the control and, additionally, execute data and knowledge processing and reasoning. As described in greater detail below, the processors connect the context models with the data received via I/O interfaces.

[0027] Continuing with reference to FIG. 2, in each processing step, the Control Application 230 reads the Process Image Component 225, executes deployed application logic, and writes results back into the Process Image Component 225. The process image of each cycle is read and permanently stored on a non-volatile physical storage medium by the Historian Component 220. In some embodiments, this Historian Component 220 is configured to deploy data compression algorithms to reduce data volume. It thereby can provide applications with access to past process images. Data may be stored either for a fixed time window or online algorithms are used to realize dynamic caching heuristics. As part of the Historian Component 220, intelligent data generation algorithms may continuously analyze the process image and context to adjust data generation parameters (e.g., sampling rate) of connected I/Os. For example, for fast changing sensor signals, a high sampling rate may be selected while for slowly changing sensor signals a lower sampling rate is sufficient.

[0028] The Data Analytics Component 205 comprises a set of data analysis algorithms that process the current or past process images (queried from the historian). Various data analysis algorithms may be included in the Data Analytics Component 205. For example, in some embodiments, these algorithms include one or more of clustering, classification, logic-based reasoning, and statistical analysis algorithms. Moreover, algorithms may be specified via a model which can be deployed during runtime on the device. The Data Analytics Component 205 may also include various analytical models and dedicated algorithms to interpret these models. The results generated by the Data Analytics Component 205 may be stored in the Historian Component 220, written back to the Process Image Component 225 and/or provided to external components via the Data Connector Component 210. Thus, the Intelligent PLC may be viewed as a device for providing distributed analytics to the other devices in the automation system.

[0029] A Contextualization Component 215 annotates incoming data with context information to facilitate its later interpretation. Context information, as used herein, may include any information that describes the meaning of data. For example, context of data in automation systems may include information about the device that generated the data (e.g., a sensor), about the structure of the automation system (e.g., topology of a plant), about the working mode of the system (e.g., downtime event), about the automation software and its status while the data was generated, and/or about the product/batch that was produced while the data was generated. The Contextualization Component is configured to provide data to any of the other components for more specific processing needs. The context information generated by the Contextualization Component 215 may not be restricted to the asset structure but may also include control knowledge, product-specific information, process information, event information, and potentially other aspects such as external events like weather information. Some context information may be imported from engineering tools and/or other external resources (e.g. Siemens Totally Integrated Automation tools, service reports, etc.). Additionally, in some embodiments, the Contextualization Component 215 provides semantic contextualization. The context may be represented by a standard modeling language (e.g. Web Ontology Language, Resource Description Framework) where the meaning of the language constructs is formally defined. Contextualization of data with these semantic modeling standards enables business analytics applications to automatically understand and interpret the data provided from the automation system without manual configuration effort. [0030] In some embodiments, the Contextualization Component 215 includes one or more context models defining an ontology for storing context knowledge. Each context model may include, for example, information about controlled processes, control procedures, connected devices (sensors/actuators), etc. Different context models (i.e., ontologies) from different domains or covering different aspects (e.g. product, asset, process, and sensor) may be combined and linked to each other to define the overall automation system context. The modular structure of ontology languages enables to dynamically add/remove context dimensions to automation system data, for example, depending on the application or recipient of data more or less context information can be added to the raw data by the automation devices. Context models are not restricted to hierarchically organized models and may consist of a network (i.e. not only trees), which subsumes various types of relations. In some embodiments, the Contextualization Component 215 specifies each context model declaratively in syntax file which allows model changes during runtime without compilation or stopping the automation device. One example of an ontological data file for specifying context models is shown below with respect to FIG. 5.

[0031] Any data captured or generated by the components of system 200 may be provided to external components via a Data Connector Component 210. In some embodiments, the Data Connector Component 210 delivers data via a push methodology (i.e., actively sending to external component). In other embodiments, a pull methodology may be used where data is queried by external component. Additionally, push and pull methodologies may be combined in some embodiments such that the Intelligent PLC is configured to handle both forms of data transfer.

[0032] FIG. 3 provides a process 300 in which contextualized data is generated, stored, and utilized by an Intelligent PLC, according to some embodiments of the present invention. At, 305 incoming data is collected from automation devices (e.g., sensors) and other external systems. This data may include, for example, time series data, control events, alarms and other structured (e.g., relational data) and unstructured data (e.g., messages, texts). At 310, the data is analyzed to be determined whether it is automatically processable (e.g., it is structured or semi-structured. If it can be automatically processed, the process continues at steps 315 and 320 (described below). However, in case the data is not automatically processable (e.g., not structured or semi- structured) it is analyzed at 310 and transformed to structured data. For example, a controller alarm message containing a natural language text containing information on error type and parameters may be transformed to a structured representation.

[0033] Continuing with reference to FIG. 3, at 320, the data is annotated with and processed according to relevant context models available as ontologies in a standard ontology language (e.g., RDF, OWL as standardized by W3C). In some embodiments, the processing performed at 320 is done by explicitly generating semantic data as instances of the ontology. In some embodiments, this is done by using RDF triples. As is well understood in the art, the underlying structure of an expression in RDF is a collection of triples comprising a subject, a predicate and an object. Each predicate represents a statement of a relationship between the things denoted by the subjects and objects that it links. Each portion of a triple has a universal resource indicator (URI) associated with it. Thus, a URI may be generated at 320 based on the context model. One or more triples may then be created which encode the relationship between this data item and other data in the automation system environment. Alternatively, in other embodiments, the processing at 320 is performed by linking an identifier of the sensor generating the incoming data to the corresponding concept (e.g., class) in the ontology which is then resolved by the query processor (see step 340 below). At 325, the semantically contextualized data is stored. In some embodiments, this storage is performed in a historian (e.g., with annotation via mapping of IDs), while, in other embodiments, data may be stored in a database constructed specially for the storage and retrieval of triples (i.e., a triplestore) with direct annotation of data.

[0034] At 315, incoming data is used to update the active window of in event engine which continuously analyzes the data in its active window in order to generate new events. Generation of events may be done by specification, for example, using defined rules or patterns. Once a new event is detected, at 330 context information required for the event (as defined in the context model) is collected from the (non- volatile or volatile) storage. New events may also be stored in the storage during step 330.

[0035] At 340, data in the storage is made available via a semantic query processor. This processor may execute a query formulated against the semantic context model (e.g. SPARQL query) and retrieve the relevant data. In some embodiments, data is directly stored as semantic data (e.g. as RDF in a triplestore) and the query may be natively executed. In other embodiments, the data is stored in a plain historian and the query is translated (SPARQL -> Historian queries) based on the context models.

[0036] Note that FIG. 3 illustrates two distinct processing paths: contextualization of data occurs at steps 320 and 325, while event processing is performed at steps 315 and 330. These two processing paths may be executed in parallel or sequentially. In some embodiments, the Intelligent PLC is configured to allow processing based on the available resources on the Intelligent PLC. For example, for a multi-processor controller, one processor may be dedicated to contextualization, while another processor handles event processing. Conversely, for a single- processor environment, the two processing paths may be executed sequentially.

[0037] FIG. 4A provides a view 400 of a graphical user interface (GUI) referred to herein as a "Smart Data Browser" which provides ontological information used in the contextualization of automation data, according to some embodiments of the present invention. This tool enables a user to connect to an Intelligent PLC via a graphical interface (e.g., web browser) to retrieve and display live data being gathered by the PLC. In the Smart Data Browser, data is displayed along with context information, allowing a user to quickly understand and diagnosis issues associated with the automation system. The Smart Data Brower includes a Chart View Section 405 which provides charts related to live sensor and event data. In the example of FIG. 4A, data associated with a skid barcode sensor is shown. A dropdown selector 405A allows a user to select other available sensor data for display. A Table View Section 410 includes measurement values for various sensors in tabular form. In FIG. 4A, data is organized displayed with four fields: a unique identifier, an indication of the sensor providing the sample, the sampled value, and a timestamp when the sample was acquired. In other embodiments, additional fields may be displayed in the Table View Section 410.

[0038] Continuing with reference to FIG. 4A, the Smart Data Browser includes an Ontology View Section 415 which allows the user to browse and navigate the ontological models associated with the sensor and event data. Thus, for example, the Ontology View Section 415 may include various control models, event models, asset models, process models, and product/material models associated with the data displayed in the Chart View Section 405. In the example of FIG. 4A, graphical indicator 415A corresponds to the skid barcode sensor providing the data displayed in the Chart View Section 405. The relationships between skid barcode sensor and various ontological models ("Sensor", "ControlProgram," "Device," "Asset," "Event," and "Process") is illustrated by additional graphical indicators connected by arrows with the skid barcode sensor's graphical indicator 415A. A user can browse through the various models through interaction with the various graphical indictors. For example, in some embodiments, double-clicking on the control program graphical indicator 415B causes the Ontology View Section 415 to be adjusted to focus on the relations associated with the control program.

[0039] FIG. 4B provides an alternate view 420 of the Smart Data Browser where fault data is presented, according to some embodiments of the present invention. In this view, the Smart Data Browser uses control knowledge to provide complete fault tree explaining quality problems. Similar to FIG. 4A, the example of FIG. 4B includes a Chart View Section 425 and a Table View Section 430 where data associated with quality problems is illustrated. The Chart View Section 425 provides a chart of particular variables (loop count) according to time, along with an indication of an expected threshold. In the example of FIG. 4B, a line 425A is used to indicate the threshold. In other embodiments, depending on the representation of the data in the Chart View Section 425, other indications of the threshold may be utilized. The Table View Section 430 includes a table with event information. Contextual information is provided with each event such as, for example, when the event occurs at (e.g., position in the system), when the event occurs (e.g., during which process), what physical items cause the quality error (e.g., a particular car door being processed), the type of event (e.g., a position fault), time information, and one or more causal events (i.e., events linked to the fault). An Ontology View Section 435 provides a graphical view of the fault event, with contextual information indicating causal links between various portions of the ontology.

[0040] FIG. 5 provides an example of a product ontology file 500 in RDF/XML syntax, as may be utilized according to some embodiments of the present invention. In short, as is understood in the art, RDF/XML is a language for expressing ontologies in human and machine readable form. Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C) specifications which were originally designed as a metadata data model. RDF/XML is a syntax defined by the WW3C, to express RDF model data as an Extensible Markup Language (XML) document. In the example of FIG. 5, a product data model is shown providing a list of properties associated with a particular product. These properties include an object property 505 specifying how the product integrates with other products and a data type property 510 specifying a product ID. Additionally, the product ontology file 500 includes a pair of attributes 520 and 525 which indicate this ontology corresponds to a car body product, specifically a car door. One of the benefits of using a RDF/XML syntax as shown in FIG 5 is that semantic models may be modularized with particular uniform resource identifiers (URIs) and namespaces. Thus, context models can be customized based on particular automation applications. It should also be noted that the use of RDF/XML is only one example of how the product ontology can be represented and stored. It other embodiments different syntaxes and/or file formats may be utilized

[0041] The contextualization methods, systems, and apparatuses, described herein offer many advantages over contextual automation systems. For example, as contextualization is done by the automation device/controller itself, the device (or its owner) can decide which context information should be provided to a certain external system and which context information should not (and may be kept internally available only for its own data analysis functions). Adding explicit formal semantics to data using standard languages enables third party systems to understand and interpret the data without dedicated manual configuration (i.e., enabling sophisticated automated configuration of MES, SCADA systems and reducing system management efforts). Explicit formal semantics enables reuse of commodity analytics libraries for data interpretation (e.g., detect complex event frames) and model management. Explicit formal semantics allows to dynamically integrate data from different sources (e.g., automation devices) enabling plug-n-play concepts and reducing configuration effort. Moreover, the use of standardized context languages and interfaces enables interoperability and "open" application/model ecosystem with external partners. For example, third party control/analytics/historian applications or third party hardware modules running control/analytics/historian functions can be connected.

[0042] In some embodiments, the Intelligent PLC provides an ecosystem on top of which applications may be constructed which utilize context data. For example, in one embodiment, the software of the Intelligent PLC includes an application programming interface (API) specifying how external software components can interact with the software operating on the Intelligent PLC. This API may include functions such as contextualizing new data or querying existing contextualized data. The API may also be used to network individual Intelligent PLCs together, thereby creating a network of controllers which can enhance their processing of data by sharing context data associated with their respective control programs.

[0043] The processors described herein as used by control layer devices may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art. More generally, a processor as used herein is a device for executing machine- readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may be coupled (electrically and/or as comprising executable components) with any other processor enabling interaction and/or communication there -between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

[0044] Various devices described herein including, without limitation, the control layer devices and related computing infrastructure, may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the invention and for containing data structures, tables, records, or other data described herein. The term "computer readable medium" as used herein refers to any medium that participates in providing instructions to one or more processors for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks. Non-limiting examples of volatile media include dynamic memory. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up a system bus. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0045] An executable application, as used herein, comprises code or machine readable instructions for conditioning the processor to implement predetermined functions, such as those of an operating system, a context data acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters.

[0046] A graphical user interface (GUI), as used herein, comprises one or more display images, generated by a display processor and enabling user interaction with a processor or other device and associated data acquisition and processing functions. The GUI also includes an executable procedure or executable application. The executable procedure or executable application conditions the display processor to generate signals representing the GUI display images. These signals are supplied to a display device which displays the image for viewing by the user. The processor, under control of an executable procedure or executable application, manipulates the GUI display images in response to signals received from the input devices. In this way, the user may interact with the display image using the input devices, enabling user interaction with the processor or other device.

[0047] The functions and process steps herein may be performed automatically, wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to one or more executable instructions or device operation without user direct initiation of the activity.

[0048] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the invention to accomplish the same objectives. Although this invention has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the invention. As described herein, the various systems, subsystems, agents, managers and processes can be implemented using hardware components, software components, and/or combinations thereof. No claim element herein is to be construed under the provisions of 35 U.S.C. 112, sixth paragraph, unless the element is expressly recited using the phrase "means for."