METHOD FOR GENERATING ITEMS OF CONTEXT-DEPENDENT INFORMATION

Abstract

The invention relates to a method for generating items of context-dependent information for informing a user about a status of a technical system, wherein the items of context-dependent information of the technical system are provided by various data sources. In order to obtain items of information about a new context of the technical system without real data sources, it is proposed that estimated context-dependent items of information of a new context are generated by correlating the data elements of the various data sources and without knowledge of real values of the new context, but based on known and experience-related values, and provided to the user.

Claims

1. A method for generating items of context-dependent information for informing a user about a status of a technical system, wherein the items of context-dependent information of the technical system are provided by various data sources, wherein estimated context-dependent items of information of a new context are generated by correlating the data elements of the various data sources and without knowledge of real values of the new context, but based on known and experience-related values, and provided to the user.

2. The method as claimed in claim 1, wherein the items of context-dependent information are provided as information models in the form of device-specific data, e.g., device data, diagnostic data, and/or measurement data, by first data sources in the form of devices of automation technology, such as OPC UA servers (= Open Platform Communications Unified Architecture servers).

3. The method as claimed in claim 1, wherein the context-based items of information are provided as information models in the form of semantic data by second data sources in the form of ontologies, such as device ontology, location ontology, diagnostic ontology, by an ontology/inference machine.

4. The method as claimed in claim 2, wherein the items of context-based information are represented as data elements in the information models, wherein a context ID is assigned directly or indirectly to each data element so that a specific concept, a specific property, or a specific device is actually represented identically in the various data sources.

5. The method as claimed in claim 4, wherein the assignment of the context ID to the data element takes place in an OPC UA information model by way of a namespace or a node ID, wherein an assignment table is used to convert the namespace or the node ID into the context ID.

6. The method as claimed in claim 4, wherein the assignment of the context ID to the data element in an ontology is modeled for each instance.

7. The method as claimed in claim 1, wherein a database, in particular a TimeSeries database, is used as the data source for current and past values.

8. The method as claimed in claim 4, wherein the correlation of the items of context-based information from the various data sources comprises the following steps: establishing a connection between a data binder unit and the data sources, assigning between items of context-dependent information by contextualizing OPC UA data, in that context IDs of OPC UA nodes are received with equivalent IDs in the information models of the ontologies, and dynamically creating a database based on incoming items of information, wherein the context IDs are compared to classes of the ontologies and a new relationship is generated in the database upon correspondence.

9. The method as claimed in claim 1, wherein generating the new context and associated data elements comprises the following steps: a) triggering an event, for example changing a diagnostic value or status query of the user b) retrieving current device data or reading them from the TimeSeries database c) possibly updating the data correlation d) triggering a query at a semantic rule engine to obtain inferences about known contexts or known items of information e) creating the new context of items of estimated context-dependent information based on context rules and based on the result of the semantic rules in step d) f) assigning the first query to the known and estimated items of information and formulating a result.

10. The method as claimed in claim 9, wherein the provision of the new context of estimated items of context-dependent information comprises the presentation of semantic information by a user interface.

11. The method as claimed in claim 9, wherein items of context-dependent diagnostic information are generated based on the items of reliable or known context-dependent information and the items of estimated context-dependent information.

12. A method for acquiring data for diagnosing devices in an automation system, comprising: modeling and providing first items of context information in the form of device-specific data such as device data, diagnostic data, and/or measurement data by first data sources in the form of the devices, modeling and providing second items of context information in the form of semantic data of the devices by second data sources in the form of ontologies such as device ontology, location ontology, diagnostic ontology, and/or in the form of information models such as OPC UA topology, defining requests, events, and instructions which are assigned to the items of context information, defining context-related rules, establishing a connection to the various first and second data sources (contexts), correlating the various data sources (contexts) with one another, wherein unique context IDs are used for identical concepts in various data sources, acquiring an event, such as triggering a registered event, for example a setpoint value exceeding a diagnostic value, searching for a context (for example diagnosis) associated with the event, carrying out a semantic query for the acquired context in order to obtain all instructions linked to the context, checking the instructions based on context-related rules, and generating a new item of estimated context-based information (diagnostic information) and a corresponding data element (virtual sensor value) when one of the context-related rules is followed.

Description

[0079] Other details, advantages, and features of the invention result not only from the claims, the features to be inferred therefrom as such and/or in combination, but also from the following description of a preferred exemplary embodiment to be inferred from the drawings.

[0080] In the figures:

[0081] FIG. 1 shows a schematic representation of an automation system having a knowledge-based system,

[0082] FIG. 2 shows a schematic representation of the method according to the invention,

[0083] FIG. 3 shows a schematic representation of an ontology scheme for describing a data element,

[0084] FIG. 4 shows a schematic representation of an ontology scheme for describing a location of a device,

[0085] FIG. 5 shows a schematic representation of the “binding” of different information contexts,

[0086] FIG. 6 shows a schematic representation of method steps for generating a new information context, and

[0087] FIG. 7 shows a schematic representation of method steps for applying context-dependent rules.

[0088] FIG. 1 schematically shows an automation system AS having devices AG1, AG2, AG3 of automation technology in the form of, for example, drive, speed controller, programmable logic controller, sensor, such as temperature sensors, current sensors, voltage sensors, etc., each representing data sources as such. The devices AG1, AG2, AG3 are, for example, arranged together in a manufacturing cell FZ and are connected via a field bus FB, such as Modbus, to a server S, preferably an OPC UA server. The server S is connected to a knowledge-based system WBS via a client CL, preferably an OPC UA client.

[0089] The knowledge-based system WBS includes an ontology/inference engine OIM, which processes rule knowledge and factual knowledge. The rule knowledge is provided in the form of semantic rules SR. The factual knowledge is provided by data sources in the form of the server S, the device data GD of the devices via the client CL, and in the form of ontologies OS1, OS2, OS3 and associated ontology instances OI1, OI2, OI3, which are stored in databases DB. An operator can send queries to the ontology/inference engine OI M and receive instructions therefrom via an operating unit BE. In addition, the ontology/inference engine OIM can be coupled to an external data source CL, such as a cloud, via a software agent SAG.

[0090] The server S is a data source that provides information models IM of the device data GD of the connected devices AG1, AG2, AG3. The information models IM provide build and runtime data in the form of device parameters and their relationships to one another (topology). Current data of the devices AG1, AG2, AG3 are provided via the client CL.

[0091] In order to avoid a continuous pool of data from the server S, the data can optionally be temporarily stored in a database, for example a TimeSeries database TSD, which can then be used as another data source for current and historical data values.

[0092] Additional models can be defined with the aid of the ontologies OS1, OS2, OS3. The ontologies OS1, OS2, OS3 are used to describe data models of certain information domains. An information domain is, for example, a diagnosis, a location, or a device. The ontologies OS1, OS2, OS3 represent data sources. Depending on the application, examples of ontologies are a diagnosis ontology OS1, a location ontology OS2, and a device ontology OS3. Items of information are supplemented with semantic descriptions by the ontologies OS1, OS2, OS3, so that these items of information can be interpreted by the ontology/inference engine OIM. The device ontology OS3 contains, for example, known data about devices, such as device descriptions, IP addresses, communication parameters, etc.

[0093] FIG. 2 shows, solely schematically, method steps of the method according to the invention.

[0094] In a step S1, different context-based or context-dependent items of information are modeled. The devices AG1, AG2, AG3 provide device-specific data GD, such as device data, diagnostic data, and/or measurement data, via the OPC UA server S.

[0095] Furthermore, semantic data of the devices and/or the system are modeled. The semantic data extend the information about the devices and/or the system. The semantic data are provided via an information model IM, such as OPC UA topology, or the ontologies OS1, OS2, OS3, such as location topology.

[0096] The modeling of the different context-dependent items of information depends strongly on which devices AG1, AG2, AG3 or server S are used as the data source and which context-dependent items of information are required. For OPC UA, each server S provides an information model IM that primarily represents build and runtime data of the devices, for example parameters, and their relationship to one another in the form of a topology.

[0097] Additional models are defined using the ontologies OS1, OS2, OS3 and are made available by the ontology/inference engine. The ontology/inference engine is also configured to carry out queries.

[0098] In a step S2, a connection is established to the data sources in the form of the devices AG1, AG2, AG3, the server S, and/or the ontologies OS1, OS2, OS3.

[0099] In a step S3, the various data sources are “linked”, i.e., the data are contextualized, which is explained in detail hereinafter.

[0100] In a step S4, new contexts are generated and associated data elements are generated as a response to queries or events.

[0101] In a step S5, a user is informed or advised on the basis of the new contexts and associated data elements.

[0102] The basic requirement for the method according to the invention is that a direct or indirect context ID is assigned to each data element in the information models and the ontologies.

[0103] In OPC UA models, the namespace and the node ID, which uniquely identify a data element, can be used for this purpose. An assignment table can be used to convert a namespace or node ID into a context ID.

[0104] In the ontologies OS1, OS2, OS3, the assignment has to be modeled in each ontology instance OI1, OI2, OI3, for example by using the relationship “hascontext-ID” or “hasID” as shown in FIG. 3.

[0105] FIG. 3 shows an ontology scheme OS of the term temperature T. The temperature T is defined as a data element DE via the relation “isA”. Furthermore, an identifier ID1, ID2, ID3 is assigned to the term temperature T via the relations “hasId”. The identifications ID1, ID2, ID3 are defined via the relations “isA” as context ID, time series ID, and semantic ID. The context ID, time series ID, and the semantic ID are also assigned to the data element DE via the “hasId” relations.

[0106] In this way, each data element in the information model is assigned a direct or indirect context ID.

[0107] Once the information models and/or ontologies are provided by the different data sources as described in step S1, a connection to the different data sources has to be established. This is done by means of a data binder. Device data are retrieved, for example, directly from the OPC UA server S or indirectly from the TimeSeries database TSD. Items of location information can be obtained, for example, by querying the ontology/inference engine.

[0108] Querying of data or items of information and merging of data or items of information are only carried out when there are events for generating or updating the context-dependent items of information. For example, the generation of new contexts is to be updated every time the value of a function status object changes.

[0109] Once the connection to the individual data sources is established, the different data sources have to be connected to one another. This means that a specific term, property, or device is actually the same in the different data sources. This is carried out with the aid of the preferably identical context IDs assigned to the terms, properties, and devices according to FIG. 3.

[0110] FIG. 4 shows an OPC UA topology of a device having the serial number 4002200HL64787000N and context-dependent items of information of the device with the same serial number in the form of a location ontology. For example, a device exists in an OPC UA address space, for example speed controller ATV630XXX, having a specific context ID. The same context ID is also used in the location ontology shown. This means that both terms or devices are actually the same, but are described differently depending on the data source; because the OPC UA information model provides items of topology and diagnostic information of the device and the location topology provides items of location information for the same device.

[0111] FIG. 4 furthermore shows that the same value for the context ID is used in the OPC UA topology and in the location topology. In the location ontology, this value is assigned to the term “context ID” via the “isA” relation. Furthermore, the term “Röntgen” is assigned to the value via the “isLocatedIn” relation. The term “Röntgen” is assigned to the term “Room” via the relation “isA”. Furthermore, the term “Zenith” is assigned to the term “Röntgen” via the relation “isLocatedInSite”. The term “Zenith” is assigned to the term “Site” via the relation “isA”.

[0112] The data binder is designed to maintain the association between items of context-dependent information from different data sources. A context update of data provided via OPC UA, for example, can be achieved by incorporating context IDs in relevant OPC UA nodes with equivalent identifications in the ontology models. This makes it possible to connect or link a topology context, as provided by OPC UA, with other contexts modulated by ontologies. The same can also be applied to the storage of TimeSeries data.

[0113] Such a database having context-updated data is created dynamically based on the incoming items of information, wherein the context IDs are compared to the ontology classes. If they correspond, a new relationship is generated in the database. If an instance already exists, a new value is updated, for example in the TimeSeries database. The comparison of incoming data with classes in the ontology can be done via REGEX expressions, for example.

[0114] FIG. 5 shows an example of the generation of items of information based on interconnected contexts. Device data DD are provided by the device AG1, for example a drive, for example “Device = Drive 123”, “Temp = 35” and “Timestamp = 23:40”. It is known from the device ontology that the device “Drive 123” is a drive. The drive is a device. The drive also has a sub-aspect “Diagnostics” with the function “Device temperature” having the parameter “temp”.

[0115] The device “Drive 123” has a parameter “P” which represents a temperature. A context ID is then assigned. A check is made using a data element that corresponds to the parameter “temp”. This is carried out using a data element ontology, wherein the term “temperature”, which is a data element, is assigned the parameter “P” as a context ID via the relation “hasContextId”. Furthermore, a time series ID and a semantic ID are assigned to the term “temperature”.

[0116] Once the context ID has been retrieved, semantic items of information have to be retrieved in order to know how to correctly interpret the data. A semantic ontology is used for this. A unit “celsius”, a value type “integer”, and a time stamp format “string” are assigned to this term via the semantic ID of the term “temperature”.

[0117] The data are then stored in the TimeSeries database using the TimeSeries ID and the data provided by the device in the correct format and correct semantics.

[0118] FIG. 6 shows in detail method steps for generating new contexts and associated data elements as a reaction to an event (step S4). The generation comprises the following steps:

[0119] S4a) An event is triggered. An event can be the change of a diagnostic condition value exceeding a setpoint value or the query of a user requesting status.

[0120] S4b) Current device data are retrieved or read from the time series database TSD.

[0121] S4c) If necessary update the data binding according to step S3.

[0122] S4d) Trigger a query to the ontology/inference engine (semantic rule engine) in order to draw conclusions about specific contexts or information. After this step, all necessary contexts of safe or actual information are available.

[0123] S4e) Generate new contexts based on context-dependent rules and based on the result of the semantic rules in step 4d).

[0124] S4f) Assign the original request to the secure and estimated items of information and formulate a final result.

[0125] FIG. 7 shows, solely schematically, method step S4e of generating new contexts based on the results of a semantic query S4e1 and applying context rules R according to step S4e2.

[0126] The semantic query according to step S4e1 provides, for example, the location of the device, relationships between devices, and the functional status of objects of the device.

[0127] In method step S4e2, context-related rules R are defined in order to generate new contexts. One rule reads, for example, “if (result_semantic_query MATCHES {aspect1, aspect2, aspect_n}) Then generate new context (“ContextX”) AND new Statement (“StatementX”) with probability(X) and Advice information (“string”)″.

[0128] In step S4e3 it is checked whether the result of the semantic queries corresponds to one or more rules R of the context-related rules R. If “no”, nothing is done in step S4e4. If “yes”, in step S4e5 a new context with data element is generated from the context-related rules or instructions of already existing contexts are updated.

[0129] A possible scenario is, for example, if two or more devices are in the same room (aspect) and devices have a thermal diagnostic object with status > 0 (aspect); then generate new context (“environment”) and instruction “health” = 1 with probability of 50%. Advice information = “Please check room environment first”.

[0130] Method step S4 is to be explained in more detail hereinafter in an example:

[0131] 1. Define a set of events: E = {E.sub.1, E.sub.2...E.sub.n}.

[0132] An event can be a change of a diagnostic value from 0 (okay) to 4 (outside specification), or a query by a user, etc.

[0133] Every event e E E has one or more assigned contexts Ce = {C.sub.1, C.sub.2...Cn}. For example, the thermal diagnosis of a device is in the context “Diagnosis”.

[0134] Every event e E E has one or more assigned values A.sub.e = {a.sub.1, a.sub.2...a.sub.N}. For simplicity, the values assigned to an event are all other values in the same context as e. For example, if the context of e is “Diagnosis”, all other diagnostic values are considered assigned values, as well as their first-order relationship, which is the cause value linked to each diagnostic object. For example, there is a cause for a thermal diagnostic object, which is the operating temperature.

[0135] 2. If one or more events e E E change, acquire their current value and the current value of all assigned values A of all e E E that have changed. If necessary, these values have to be updated in the TimeSeries database TSD.

[0136] If the value for the thermal diagnosis has changed, for example, from 0 to 4, the new value (4) has to be retrieved and the value of all other diagnostic objects in all devices has to be updated in the TimeSeries database.

[0137] 3. Create a semantic query for all contexts C.sub.e assigned to e, wherein e is the event that has changed. A possible query is: “search C”.

[0138] In the example with diagnosis, a combined context “diagnosis” is used, which “connects” the location ontology and the OPC UA topology in a single context.

[0139] The query “search C” will return a series of instructions S = {S.sub.1, S.sub.2...S.sub.N} for this context C. An instruction is a direct or indirect (derived) relationship of type “diagnosis”. First-order relationships return all objects that are of the type “diagnosis”, such as “Thermal” “isA” “diagnostics”, “ATV360xxx” “contains” “Thermal”, “Thermal” “contains” “HealthStatus”, “HealthStatus” “hasA” “Value”, “Value” “is” “4”, “ATV630xxx” “isLocated” “FactoryCell2”, “ATV 630xxx” “isA” “Device”.

[0140] 4. Check whether the previous statements s E S of the query correspond to one or more context-based rules R = {R.sub.1, R.sub.2...R.sub.N}. A rule is an algorithm that takes as input the set of statements from the query result S and returns true or false if S corresponds to the rules expressed by the algorithm.

EXAMPLE

[0141] Rule r(S) => “IF two or more devices are in the same room (same X in “islocated” X) AND devices have a thermal diagnostic object (“Thermal” “isA” “Diagnostics”, X “contains” “Thermal ”) with HealthStatus value > 0; THEN RETURN TRUE”.

[0142] 5. If one or more rules r in R are TRUE, then carry out the associated actions with the matching rules. A typical action would be to generate a new context with one or more properties and an associated probability.

EXAMPLE

[0143] Generate new context (“environment”) AND instruction “health” = 1 with probability of 50%. Items of advice information = “Please check room environment first”.

[0144] Step S5 of the method relates to user advice.

[0145] The advice of the user depends strongly on the user interface. Basically, the items of information of the existing and new contexts are formatted in such a way that the user can understand them. An adviser information string can be used here as an item of information for the user. A “user” can also be an additional computing system that can understand the result of the query semantically.

[0146] The method according to the invention allows new contexts of items of estimated information for industrial automation devices to be generated, even if no data or sensors are available for these contexts. The new contexts are derived from existing contexts such as diagnostic data, topology data, or location data of the devices. Then the independent items of context-dependent information are connected to one another. An operator is then assisted with various possible solutions to a given problem by instructions.

[0147] The various items of context-dependent information and their assignment provide another value level for data, i.e., the generation of estimated items of information based on assumptions, in particular when querying and analyzing data for conclusions and expertise.

[0148] In this context, the functional status (health status) of a thermal object of an automation device, such as a speed controller, should also be considered, which is arranged in a production cell in which another automation device is also arranged that has the same status. Both automation devices are connected to a SCADA (Supervisory Control and Data Acquisition) system via OPC UA and are used in a process controller to control several motors. It would be very helpful for a user to receive the items of information about the status of the thermal objects of the automation devices as soon as there is a functional problem.

[0149] The application of the method according to the invention in relation to an environmental context is to be described with reference to FIG. 1 using an example. The automation devices AG1, AG2, AG3 are located together in the manufacturing cell FZ. An environmental context does not exist since no real sensor or other real value is available that provides information about the status of the manufacturing cell FZ. There is no possibility to acquire the status, for example the temperature, in the manufacturing cell FZ.

[0150] However, the location of the devices AG1, AG2, AG3 is known and there is the possibility of acquiring the operating temperature of the devices AG1, AG2, AG3 via device sensors S1, S2, S3.

[0151] This raises the question of whether, on the basis of the measured temperatures, assumptions can be made about the condition or the environment of the manufacturing cell FZ based on the existing values, here temperature values of the devices.

[0152] This is where the invention comes in.

[0153] 1. In a first step, a connection is established to the data sources (contexts) OPC UA server S and the location ontology. The OPC UA server provides items of OPC UA information that supply the temperature values of the device. The location ontologies provide items of location information of the devices AG1, AG2, AG3.

[0154] 2. The different contexts are correlated or bound to one another, wherein unique context IDs are used for the same terms in different data sources.

[0155] New estimated contexts and associated data items are then generated as a response to queries or events.

[0156] 3.1 Search for registered events that are triggered, for example at least one increased temperature value.

[0157] 3.2 Query the assigned context, for example diagnosis, of the event and carry out a semantic query for this context. All statements assigned to this context are returned. For example: “Thermal” “isA” “diagnostics”, “ATV360xxx” “contains” “Thermal”, “Thermal” “contains” “HealthStatus”, “HealthStatus” “hasA” “Value”, “Value” “is” “4”, “ATV630xxx” “isLocated” “FactoryCell2”, “ATV 630xxx” “isA” “Device”.

[0158] 3.3 Check statements based on context rules. If a rule corresponds, generate estimated context and a virtual sensor value or other action assigned to this rule. The context rules are based on previous experience and assumptions. For example, one rule is:

[0159] IF two or more devices are in the same room (same X in “isLocated” X) AND the devices have a diagnostic object temperature (“Temperature” “isA” “diagnostics”, X “contains” “Temperature”) with value ! = OK ; THEN generate new context (“Environment”) AND instruction “Temp” = NOK with certainty of 50%. Items of advice information = “Please check room environment first”.