Method for querying and processing process information, and automation assembly
Patent Information
- Application Number
- PCT/EP2026/054503
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-03-21
- Filing Date
- 2026-02-19
- Publication Date
- 2026-09-24
Smart Images
Figure EP2026054503_24092026_PF_FP_ABST
Abstract
Description
[0001] Description
[0002] Methods for querying and processing process information and automation arrangement
[0003] In modern industrial process networks, the efficient querying and processing of process information plays a central role. These networks comprise a multitude of devices and systems that continuously generate and exchange data. These devices include sensors, actuators, programmable logic controllers (PLCs), human-machine interfaces (HMIs), and various other automation components.
[0004] The current state of the art in industrial process networks is primarily based on proprietary communication protocols and specific data models. These approaches lead to several challenges in querying and processing process information:
[0005] Different devices and systems often use different data formats, which complicates data integration and processing. Querying specific process information often requires detailed knowledge of the underlying data structures and communication protocols.
[0006] Existing systems are often rigid and do not allow for dynamic adaptation to changing requirements or the integration of new data sources. Current query methods often result in over- or under-querying of data, leading to inefficient network utilization and increased processing time. The use of proprietary protocols and data models hinders seamless communication between devices from different manufacturers. With the increasing number of devices and the growing volume of data in industrial networks, traditional query and processing methods are reaching their limits. Existing systems often lack the ability to link process information with additional context or metadata, complicating data interpretation and analysis.
[0007] Karhula's work, "Internet of Things: a gateway-centric solution for providing IoT connectivity," reveals a rigid implementation for an IoT gateway that enables internet connectivity for various end devices using IoT protocols. The paper addresses existing IoT architectures, protocol stacks, IoT gateway functionalities, and management. These issues and challenges highlight the need for a flexible, efficient, and standardized approach to querying and processing process information in industrial process networks.
[0008] The purpose of the invention is to enable simple and efficient querying and to improve interoperability.
[0009] The present invention provides a method and an automation arrangement for the efficient querying and processing of process information in an industrial process network. The invention addresses the challenges described in the background through a flexible, standardized approach.
[0010] A key element of the invention is the implementation of a type scheme that defines the structure of the process information and its attributes. This scheme enables a uniform representation of the data across different devices and systems.
[0011] A special query language is introduced for retrieving process information. This language allows precise and efficient queries to be formulated without requiring detailed knowledge of the underlying data structures.
[0012] Accordingly, the task is solved by providing a method for querying and processing process information in an industrial process network, where the process information comprises a data set of at least one data point, including the following steps:
[0013] Implementing a type schema to define a structure of the data set of data points and their attributes;
[0014] Providing a query language that allows querying the process information; assigning a resource identifier to each data point within the process network for unique identification;
[0015] Operating a query client on a consumer and a query server on a producer to process specifically requested queries of process information or to provide the specifically requested process information;
[0016] Operating an index register on the producer to manage and index resource identifiers;
[0017] Providing resource identifiers through a protocol adapter for communication across different network interfaces;
[0018] This involves running an application on the consumer, which queries process information using the query client. The type schema defines the structure and attributes of data types within a system. It describes how data is organized and what kind of information it contains. A type schema serves as a contract between different system components to ensure that all involved parties understand and process the data in the same way.
[0019] An application, or app for short, can be a program that visualizes and monitors process information in real time. The following examples are conceivable: An app that analyzes machine data to predict potential failures and provide maintenance recommendations. An application that analyzes production data and suggests ways to increase efficiency. An app for monitoring and optimizing energy consumption in the plant. An application for monitoring and analyzing quality parameters in real time. An app that centralizes and prioritizes alarms and warnings from different parts of the plant. An application for analyzing and optimizing process parameters.
[0020] These apps would use the query client to query and process the required process information via the query language (FQL).
[0021] An automation setup that utilizes this method comprises several automation components, at least one of which is configured as a consumer and another as a producer of process information. A query client runs on the consumer, while a query server runs on the producer. These components enable structured communication between the devices.
[0022] Both the consumer and the producer have implemented software environments that include the type schema and query language. This ensures consistent interpretation of the data and queries on both sides.
[0023] An important component of the invention is the index register on the producer. This register manages and indexes resource identifiers assigned to individual data points in the network. This enables efficient identification and localization of the requested information.
[0024] To support various communication protocols, the consumer has a protocol adapter. This adapter enables the use of resource identifiers across different network interfaces, thus increasing the system's flexibility and interoperability. The invention solves the problems described in the background by providing a standardized, flexible, and efficient method for querying and processing process information. The uniform data structure and query language reduce the complexity of integrating different devices and systems. The query language enables data access that is, in principle, independent of the infrastructure and storage location for the user. The use of resource identifiers and an index register optimizes data transmission and improves scalability. The protocol adapter achieves improved interoperability between different network protocols.
[0025] Overall, the invention offers a comprehensive solution to the challenges of modern industrial process networks and enables more efficient, flexible and scalable processing of process information.
[0026] The type scheme and query language are central components of the presented method for the efficient querying and processing of process information in industrial process networks.
[0027] The type schema defines the structure of the data set, including data points and their attributes. It is implemented in a standardized format such as YAML or XML. This enables a consistent and machine-readable description of the data structures across different devices and systems. An example of a type schema in YAML format might look like this:
[0028] yaml
[0029] Measurement:
[0030] value: timestamp-latest
[0031] min: static
[0032] max: static
[0033] unit: static
[0034] Diagnosis:
[0035] value: timestamp-latest
[0036] Parameter:
[0037] measurementMode: static
[0038] This example describes three types in YAML format. The `Measurement` type has three time-invariant attributes: minimum and maximum measurement range, and unit, whereas the `value` attribute is time-varying and only provides the most recent value. Each type has specific attributes with defined data types. Using such a schema ensures a consistent data structure and facilitates the interpretation of process information.
[0039] The query language (FQL) is specifically designed to efficiently query process information. It contains keywords that allow you to query and filter specific attributes of the process information. An example of an FQL query might look like this:
[0040] SELECT value, timestamp
[0041] FROM Sensor
[0042] WHERE id = "temp_sensor_01"
[0043] AND timestamp > "2023-01-01T00:00:00"
[0044] LIMIT 100
[0045] This query would retrieve the values and timestamps of the last 100 measurements from a specific temperature sensor since January 1, 2023.
[0046] The query language also includes functions for aggregating and statistically analyzing process information. Examples of such functions could be:
[0047] SELECT AVG(value) AS average_temperature,
[0048] MAX(value) AS max_temperature,
[0049] MIN(value) AS min_temperature
[0050] FROM Sensor
[0051] WHERE type = "temperature"
[0052] AND timestamp BETWEEN "2023-01-01T00:00:00" AND "2023-12-31T23:59:59"
[0053] GROUP BY DATEPART (month, timestamp)
[0054] This query would calculate the average, maximum, and minimum temperature for each month of the year 2023.
[0055] The combination of the type schema and the query language creates a flexible and efficient method for querying process information.
[0056] The type schema ensures that the data structures are uniform and clearly defined, while the query language enables precise and efficient querying of this data. This significantly reduces the effort required for data integration and processing, and allows for more efficient use of process information in industrial networks.
[0057] In the presented method for querying and processing process information in an industrial process network, the assignment and use of resource identifiers plays a central role. These resource identifiers serve to uniquely identify data points within the network.
[0058] Each data point in the process network is assigned a unique resource identifier. This identifier follows a standardized format that allows the data point to be precisely located and retrieved. An example of such a resource identifier could look like this:
[0059] nw: / / device / sensor01 / temperature
[0060] In this example, the resource identifier identifies a temperature sensor named "sensorOT". 1 on a specific device on the network.
[0061] The use of resource identifiers offers several advantages: Each data point in the network can be uniquely identified, regardless of its physical location or the device on which it is located.
[0062] The resource identifier structure enables a hierarchical organization of the data points, which facilitates navigation and querying.
[0063] The resource identifiers can be used across different communication protocols, which increases the flexibility of the system.
[0064] The query client sends a request in the form of a resource identifier to the query server. The query server interprets this resource identifier and sends back the corresponding process information.
[0065] A typical process might look like this:
[0066] 1. The query client formulates a request using the query language and the corresponding resource identifier.
[0067] 2. The request is sent to the query server. 3. The query server interprets the resource identifier and locates the corresponding data point in the producer. Since the server runs on the device and only interprets and serves the URI, it will not interact with the network.
[0068] 4. The query server retrieves the requested process information using manufacturer-internal data interfaces.
[0069] 5. The process information is sent back to the query client.
[0070] This mechanism enables efficient and precise querying of process information without requiring the query client to have detailed knowledge of the network's internal structure or the specific implementation of data storage.
[0071] The use of resource identifiers in conjunction with the query client and query server thus forms a flexible and powerful basis for querying and processing process information in industrial process networks.
[0072] The query client and the query server are central components of the presented method for querying and processing process information in industrial process networks. These components work together to enable efficient and flexible communication between consumers and producers of process information.
[0073] The query client runs on a consumer device and is responsible for formulating and transmitting queries. A key component of the query client is a query language interpreter. This interpreter receives queries for process information formulated in the specific query language. Based on these queries, the interpreter generates corresponding resource IDs. These resource IDs serve as unique identifiers for the requested process information within the network.
[0074] Another important component of the query client is the forwarder. The forwarder processes the resource identifiers generated by the query language interpreter. Its task is to forward the queries to the appropriate protocol adapters. This enables flexible communication across various network protocols, with the possibility of pre-filtering. For example, "timestamp values" are queried directly from PROFINET, while historical values are retrieved via HTTP. On the producer side, a query server is operated. The query server is responsible for processing incoming queries and providing the requested process information. A central component of the query server is the resource identifier interpreter. This interpreter receives the resource identifiers transmitted by the query client and translates them into system-specific addresses or identifiers.
[0075] The query server also includes a schema type resolver. This component checks whether the requested system-specific addresses conform to the defined type schema. This ensures that only valid and consistent data is returned.
[0076] A key feature of the query server is its ability to apply aggregation and statistical analysis functions to the queried data before sending the results back to the query client. This enables efficient processing and preparation of the data directly at its source, which can reduce network traffic and shorten processing time for the user.
[0077] The process of a typical query is as follows:
[0078] 1. An application on the consumer formulates a query using the defined query language.
[0079] 2. The query language interpreter of the query client receives this query and generates one or more resource identifiers from it.
[0080] 3. The query client's forwarder processes these resource identifiers and forwards the query to the appropriate protocol adapters.
[0081] 4. The query is transmitted via the network to the producer's query server.
[0082] 5. The resource identifier interpreter of the query server receives the query and translates the resource identifiers into system-specific addresses.
[0083] 6. The schema type resolver checks the validity of the query against the defined type schema.
[0084] 7. The query server retrieves the requested process information and applies aggregation or analysis functions as needed. 8. The processed process information is sent back to the query client via the network.
[0085] 9. The query client receives the data and makes it available to the requesting application.
[0086] This architecture and functionality enable the query client and query server to flexibly, efficiently, and standardizedly query and process process information in industrial process networks. The use of resource identifiers and the ability to prepare data directly at the producer contribute to optimized network utilization and improved scalability.
[0087] The index register and the protocol adapter are essential components of the presented method for efficiently querying and processing process information in industrial process networks. The index register is operated on the producer and serves to manage and index resource identifiers (URIs). A key function of the index register is to create and maintain a mapping table. In this table, the resource identifiers are assigned to the corresponding data points. This enables efficient localization and querying of process information within the network.
[0088] The structure of the mapping table could look like this, for example:
[0089] Resource Identifier (URI) Data Point Type Address
[0090] nw: / / device1 / sensor1 / temperature float 0x1234
[0091] Temperature Sensor 1
[0092] nw: / / device1 / actuator1 / valve valve actuator 1 boolean 0x5678
[0093] This table allows for a quick mapping of URIs to the corresponding data points and their specific properties.
[0094] A protocol adapter is a component that enables the use of resource identifiers for communication across different network interfaces. The adapter supports various protocols such as Profinet (PN), HTTP, and MQTT. For each of these protocols, the protocol adapter uses specific communication methods.
[0095] For Profinet, the protocol adapter could, for example, convert the resource identifier into a corresponding Profinet address and retrieve the data via the Profinet protocol. For HTTP, the adapter could convert the URI into an HTTP GET request, while for MQTT, the URI could be used as a topic for publish / subscribe communication.
[0096] An example of how the protocol adapter works:
[0097] 1. The protocol adapter receives a request with the URI "nw: / / device1 / sensor1 / temperature".
[0098] 2. The adapter recognizes, based on the network configuration, that "devicel" is reachable via Profinet.
[0099] 3. The adapter converts the URI into a Profinet-specific address.
[0100] 4. The request is sent to the target device via the Profinet protocol.
[0101] 5. The received data is converted by the adapter into a standardized format and returned to the requesting party.
[0102] This flexibility allows the protocol adapter to enable seamless communication across different network protocols without the requester needing to know the specific details of the different protocols.
[0103] The combination of index register and protocol adapter offers several advantages:
[0104] The index register enables a quick mapping of URIs to data points.
[0105] The protocol adapter abstracts the complexity of different network protocols.
[0106] New devices and protocols can be easily integrated into the system.
[0107] The use of URIs enables uniform addressing across different networks and protocols.
[0108] In summary, the index register and the protocol adapter form a powerful infrastructure for the efficient management and querying of process information in heterogeneous industrial networks.
[0109] The invention offers numerous possibilities for variations and extensions, enabling the system to be adapted to different industrial environments and requirements. One possible extension of the query server is the implementation of a cache. This cache can temporarily store frequently queried process information to reduce response time for repeated queries. This is particularly useful in environments where certain process information is frequently queried but does not change constantly. The cache can be configured to store data for a specific period or to update it when the underlying information changes.
[0110] Another possible extension is the ability to export IDs and their types to a file format for third-party applications. This enables easy integration with external systems and applications that may not be able to communicate directly with the query client. The export could be in standardized formats such as JSON or XML, ensuring interoperability with a wide range of systems. This also increases the testability of the target application, as the data interface is hardware-independent.
[0111] A schema type resolver can be run on the query server, preferably on the producer. This component is responsible for presenting the process information in a defined target format. This allows for flexible adaptation of the data output to the requirements of different consumers. For example, the schema type resolver can convert data types, convert units, or transform complex data structures into simpler formats.
[0112] Using engineering software, such as TIA Portal, to configure the manufacturer offers a user-friendly way to adapt the system to specific industrial environments. This software can be used to configure devices, define network topologies, and assign resource identifiers. Integration with such engineering software enables seamless integration of the invention into existing automation environments.
[0113] The system can also be extended to implement various security mechanisms. This could include encrypting communication between the query client and query server, implementing access controls for specific resource identifiers, or integrating with existing authentication systems.
[0114] Another possible extension is the implementation of mechanisms for the dynamic discovery of resources on the network. This would allow the system to automatically detect new devices or data points and add them to the index register without requiring manual configuration. The query language could be extended to enable more complex queries, such as the aggregation of data across multiple data points or the application of filter functions directly within the query. This would further increase the system's flexibility and performance.
[0115] Finally, the system could be extended to include data visualization and analysis functions. This could involve the integration of dashboards or reporting tools that transform the queried process information into easily understandable visual formats.
[0116] These variations and extensions demonstrate the flexibility and adaptability of the invention to different industrial environments and requirements. They enable continuous development and optimization of the system to meet the changing needs of industrial automation.
[0117] The flexibility and adaptability of the invention enable its use in various industrial environments, from temperature monitoring in chemical plants to quality control in food production. The integration of AI modules for analysis and prediction based on historical data points opens up new possibilities for process optimization and preventive maintenance.
[0118] The following are concrete examples and use cases for the use of the invention in various industrial scenarios:
[0119] Temperature monitoring in a chemical plant:
[0120] In a chemical plant, multiple temperature sensors are used to monitor critical processes. An application on a consumer device simultaneously queries the resource IDs of several temperature sensors using a query client. The query client aggregates the responses into a single, comprehensive overview of the temperature distribution within the plant. This enables efficient monitoring and rapid response to temperature changes.
[0121] Predicting maintenance needs in a production plant:
[0122] In a production plant, a computer simulation module (CSMA) is used to predict machine maintenance needs. The CSMA analyzes historical data points, such as vibrations, temperature, and energy consumption, which are recorded by various sensors. Based on this data, the CSMA generates predictions for future temperature values and other relevant parameters. These predictions are used to plan preventive maintenance and reduce unplanned downtime. Energy management in a data center:
[0123] A data center uses an application on a consumer device to query process information about the energy consumption of various server racks. The application uses the query client to retrieve data from power meters, temperature sensors, and cooling systems. By aggregating this data, the data center can optimize its energy consumption and improve cooling efficiency.
[0124] Quality control in food production:
[0125] A food factory uses a computer-aided design (CA) module to monitor and predict the quality of its products. The CA module analyzes process information such as temperature, humidity, and processing times. Based on historical data points, the CA module generates predictions for expected product quality. These predictions allow for proactive adjustments to process parameters, ensuring consistently high product quality.
[0126] Logistics optimization in a distribution center:
[0127] A distribution center uses an application on a consumer device to query process information about the status of conveyor belts, sorting systems, and inventory levels. The application's query client simultaneously queries multiple resource IDs to obtain a comprehensive overview of the material flow. This real-time information is used to identify bottlenecks and optimize logistics processes.
[0128] These examples demonstrate how the invention can be used in various industrial environments to monitor, optimize, and predict processes. The query client's ability to query multiple resource identifiers simultaneously and aggregate the responses enables efficient data acquisition. Using AI modules for analysis and prediction based on historical data points provides valuable insights for process optimization and predictive maintenance.
[0129] The presented invention offers several advantages and technical effects compared to the prior art:
[0130] Increased efficiency: The use of the type schema and query language enables precise and efficient querying of process information. This reduces the overhead of data transmission and processing. The ability to query multiple resource identifiers simultaneously and aggregate the responses further contributes to increased efficiency. Improved flexibility: The use of resource identifiers (URIs) to identify data points enables flexible addressing across various network protocols. The protocol adapter supports different communication protocols, which facilitates integration into existing systems.
[0131] Increased scalability: The index register on the producer enables efficient management and indexing of resource identifiers. This contributes to the system's scalability, as new devices and data points can be easily added.
[0132] Dynamic resource discovery: The forwarder uses a broadcast request when a URI path is unknown. This enables dynamic discovery of resources on the network without requiring manual configuration.
[0133] Optimized PROFINET communication: For PROFINET communication, Device Access AR is used, as a write record is executed first, followed by a read record (CLRPC, PG connection), for asynchronous communication with a defined record index in the address range 0x0 to 0x7FFF. This enables efficient and standardized communication in PROFINET environments.
[0134] Improved interoperability: By using standardized formats for the type schema and query language, interoperability between different devices and systems is improved.
[0135] Reduced configuration effort: Dynamic resource discovery and the use of URIs reduce the manual configuration effort when integrating new devices or data points into the network.
[0136] Optimized data processing: The ability to execute aggregation and analysis functions directly on the producer reduces network traffic and relieves consumers of data processing burdens.
[0137] Improved real-time capability: The efficient querying and processing of process information improves the real-time capability of the system, which is particularly advantageous in time-critical industrial applications.
[0138] These advantages and technical effects contribute to making the presented invention a powerful and future-proof solution for querying and processing process information in industrial process networks. The drawing shows an embodiment of the invention. It shows:
[0139] FIG 1 an automation arrangement,
[0140] FIG 2 shows a block diagram from consumer to producer,
[0141] FIG 3 shows a block diagram of a setup for a consumer device,
[0142] FIG 4 shows a block diagram for the setup in a production device,
[0143] FIG 5 a communication chain for a consumer and
[0144] FIG 6 shows a communication chain for a producer.
[0145] Figure 1 shows an automation arrangement 101 comprising a programmable logic controller (PLC) 10, an input unit 11 with a temperature sensor 12, a control module 13, a configuration tool 14, an edge application 15, and a database 16. All these automation components are interconnected via a process network, preferably Industrial Ethernet. The following act as consumers of process information from the input unit 11, for example, a decentralized ET 200 device:
[0146] The database 16, the edge application 15, the AI module 13, and the programmable logic controller (PLC) 10, where the PLC 10 can also actively write process data. For example, the AI module 13 cannot currently query the process information Pi from the temperature sensor 12 in degrees Celsius without immense effort for data processing, interpretation, and aggregation. Communication with the input unit 11 involves either a subquery or a cross-query.
[0147] The automation arrangement 101 according to FIG 1 subdivides its automation components AK into a consumer group KonG and a producer group ProG.
[0148] The problem illustrated in FIG. 1 can be solved by implementing a consumer (Kon) and a producer (Pro). FIG. 2 shows a block diagram of a consumer (Kon) and a producer (Pro). A query client (QC) is implemented on the consumer (Kon) within a software environment (KS). Within the software environment (KS), a type schema (TS) is defined for the structure of the data set (Dj) and their attributes. Additionally, a query language (FQL) is defined within the query client (QC). The producer (Pro) also has a software environment (PS). Within this software environment (PS), the type schema (TS) is defined for the structure of the data set (Dj). The query language (FQL) is also implemented within the software environment (PS) of the producer (Pro).The consumer Kon has an application App and is configured to run the application App, which in turn is configured to query the process information Pi from the producer Pro using the query client QC. The consumer Kon and the producer Pro are each connected to each other via a Profinet stack PNS over the process network NW. The consumer Kon uses a Profinet stack PNS of the controller or supervisor type. The Profinet stack PNS on the producer Pro is a Profinet device stack.
[0149] FIG 2 essentially implements a software-based communication mechanism for query-based communication between OT and IT devices / applications. The components shown in the block diagram enable a method for querying and processing process information Pi within the industrial process network NW.
[0150] Figure 3 illustrates how a query client QC must be implemented in a consumer device Kon. The query client QC provides an interface for an FQL client to a query language interpreter FQL-I. This interpreter can then access the corresponding stacks—namely, the PROFINET stack PNS, the HTTP stack, or the MQTT stack—via a forwarder FW and a protocol adapter PA. The PROFINET adapter PNA, the HTTP stack, or the MQTT stack can be either an HTTP adapter or an HTTP adapter.
[0151] The query language interpreter FQL-I interprets an FQL query in the query language FQL based on the query language keywords and forms a path for a resource identifier URI.
[0152] The forwarder FW manages all resource identifiers (URIs). When the forwarder FW receives a new resource identifier (URI), it searches for a matching complete resource identifier (URI) and submits a request via the protocol adapter PA.
[0153] The protocol adapter PA receives a complete resource identifier (URI) and forwards it to the corresponding client. Each protocol adapter PA processes the information according to its type definition. For example, if the protocol adapter PA is used for a PROFINET adapter PNA, the `DeviceAccess-AR read` method (CLRPC.PG connection) can be used for asynchronous communication with a defined record index in the address range 0X0 to 0X7ff. The `DeviceAccess-AR` method can be used because the FQL client first executes a `writeRecord` and then a `readRecord`.
[0154] The protocol adapter PA receives a request with the resource identifier URI "profinet: / / de-vice1 / sensor1 / temperature".
[0155] The PA protocol adapter recognizes, based on the network configuration, that "devicel" is reachable via Profi-net.
[0156] The PA protocol adapter converts the resource identifier URI into a Profinet-specific address and writes a request with the corresponding resource identifier URI to the target device (write record).
[0157] The request is sent to the target device via the Profinet protocol. The target device checks the request for feasibility and acknowledges it.
[0158] The result of the acknowledgment is forwarded to the forwarder FW and stored there for the resource identifier URI.
[0159] If the request was successful, the protocol adapter reads the requested information from the corresponding Profinet address.
[0160] The received data is converted into a standardized format by the protocol adapter PA and returned to the requester.
[0161] Figure 4 shows a similar block diagram for a Producer Pro with a Query Server QS of the Producer Pro. The Producer Pro, or rather the Query Server QS, has an FQL server that essentially serves to answer resource ID URI queries. If an FQL record is written via PROFINET with a resource ID URI, this resource ID URI is passed to the FQL server. For this purpose, the Query Server QS has a resource ID interpreter URI-I. The resource ID interpreter URI-I only requires the resource ID URI as a path and interprets this string based on the type schema TS definition. An index register IR manages and configures all unique assignments, especially IDs, according to the type definition under the available data points on a device.A schema type resolver STR is used to query an ID and a type and converts the return values into a defined target format for a consumer application. The conversion is performed using parameters that are transmitted during configuration. This allows, for example, the conversion of bit values to FLT values or to a string, etc. The schema type resolver STR, in turn, accesses a schema type adapter STA. This, in turn, can access a process value adapter PWA or a diagnostic adapter DA. Finally, the data values are retrieved via a PROFINET stack PNS using readRecord().
[0162] Figure 5 illustrates a communication chain in a consumer device (Kon). The signal flow diagram in Figure 5 depicts the communication between the components of a consumer device. For example, an application (App), specifically a dashboard application, sends an FQL query string via the FQL client interface, thereby calling the interpreter, namely the query language interpreter FQL-I. The query language interpreter FQL-I constructs the resource identifier URI as a URI path and forwards it to the forwarder FW. If this URI path, i.e., the resource identifier URI, is unknown to the forwarder FW, the forwarder FW sends a broadcast request to all available participants. Otherwise, the forwarder FW creates a request to the relevant participants. This communication is then transmitted via the PROFINET adapter PNA.The resource identifier URI is sent via the PROFINET stack PNS according to the specifications of the PROFINET interfaces, and a response is received. The forwarder FW collects all responses from the communication participants and messages them into a standardized format. This is ultimately returned to the query language interpreter FQL-I, and finally, the process value Pi or the data point Dj is passed on to the application App.
[0163] FIG 6 describes the communication chain within a Producer Pro. For example, an ET200 IM is configured as a distributed I / O, a Producer Pro, and therefore includes a query server QS. This means that this automation component of the distributed I / O receives an FQL server in addition to the firmware. In this functionality, the server receives a resource identifier URI query in response to a read record request from a consumer Kon.
[0164] Further definitions and explanations:
[0165] The TS type schema in this context is a structured framework that defines the data types and attributes for the process information (Pi) in the industrial automation network. It specifies data types for various types of process information (e.g., integer, float, boolean, string, etc.). Attributes for each type of process information (Pj, e.g., unit, value range, timestamp, precision) are defined. A hierarchical data structure is established to represent relationships between different information types.
[0166] A specification of metadata for each data instance, e.g., device name, sensor type, location, is introduced. Unique identifiers (IDs) for data instances within the network are defined.
[0167] The TS type scheme forms the basis for the uniform representation and processing of data throughout the entire system and enables a consistent interpretation of the process information Pi across different components and applications.
[0168] The indexer, or index register IR, performs the following functions:
[0169] Managing Resource Identifiers (URIs) on Producer Devices: The Index Register (IR) is responsible for organizing and managing the resource identifiers (URIs), also known as Uniform Resource Identifiers, on the devices that produce the data or process information (Pi). The Index Register (IR) receives internal addresses and parameters from the resource identifier interpreter (URI-I) and processes this information. After processing, the Index Register (IR) forwards the relevant information to the Schema Type Resolver (STR). The Index Register (IR) can cache data to enable faster access to frequently queried information.
[0170] Through efficient indexing, the index register IR can improve the speed of data access and queries within the system. The index register IR helps determine the physical or logical location of data on the network.
[0171] The schema type Resolver STR fulfills the following functions:
[0172] The schema type resolver STR interprets the data types used in the queries and data structures.
[0173] It resolves the specific type information required for data processing. The schema type resolver STR acts as an intermediary, receiving information from the index register IR and forwarding it to the schema type adapter STA. It verifies whether the requested or transmitted data conforms to the defined type schema.
[0174] If necessary, the Schema-Type Resolver can convert STR data types to ensure compatibility between different system components.
[0175] The query language interpreter FQL-I fulfills the following functions:
[0176] The FQL query language interpreter receives and processes queries formulated in the Field Device Query Language (FQL). It analyzes the syntax of incoming FQL queries to ensure they are correctly formulated. The FQL interpreter verifies the meaning and logic of the queries to guarantee their validity within the system context. Based on the FQL query, the interpreter generates URI paths used to locate the requested data.
[0177] The query language interpreter FQL-I understands and processes various query operations such as SELECT, WHERE, JOIN, etc. It forms the interface between the user application (e.g., dashboard or any application app) and the internal query system.
[0178] The resource identifier interpreter URI-I fulfills the following functions:
[0179] Resource identifier interpreter URI-I receives resource identifier URI queries. It parses and analyzes the structure of the received URIs. It checks the ID, type, and attributes contained in the URI.
[0180] Other ideas for procedures include the following:
[0181] A method in which information about a process value with different time values can be addressed to different producers (the interplay of type schema and URI). The time value is part of the index and ensures that values of a process input can be addressed to different devices while remaining unique. This mechanism is already achievable with MQTT.
[0182] The interaction with FQL also means that no producer needs to interpret the query string, but only a URI. This requires less overall performance, since no FQL interpreter is built and the URI string is shorter.
Claims
Patent claims 1. A method for querying and processing process information (Pi) in an industrial process network (NW), wherein the process information (Pi) comprises a data set of at least one data point (Dj), comprising the following steps: Implementing a type schema (TS) to define a structure of the data set of data points (Dj) and their attributes, wherein the type schema (TS) serves as a contract between system components, is implemented on both the consumer (Kon) and the producer (Pro), and enables a uniform representation of the process information across different devices and systems; providing a query language (FQL) that enables querying the process information (Pi), wherein the query language (FQL) is based on classes, types, and keywords of the type schema (TS). Assigning a resource identifier (URI) to each data point (Dj) within the process network (NW) for unique identification, wherein a data point is both directly accessible via the resource identifier (URI) and queried via the query language (FQL), the query language (FQL) additionally providing filtering, aggregation and statistical analysis functions. Operating a query client (QC) on a consumer (Kon) and a query server (QS) on a producer (Pro) for processing specifically requested queries of the process information (Pi) or for providing the specifically requested process information (Pi), Operating an index register (IR) on the producer (Pro) to manage and index the resource identifiers (URI), Providing resource identifiers (URIs) through a protocol adapter (PA) for communication across various network interfaces (PN, http, mqtt); where an application (App) is run on the consumer (Con), which queries process information (Pi) using the query client (QC).
2. The method of claim 1, wherein the type scheme (TS) defines for each data point type which attributes are time-varying and which are static.
3. A method according to one of claim 2, wherein a timestamp is part of the resource identifier (URI) to uniquely address time-varying process data.
4. A method according to claims 1 to 3, wherein the type schema (TS) is defined in a standardized format, such as YAML or XML.
5. A method according to any of the preceding claims, wherein the query client (QC) sends a request in the form of the resource identifier (URI) to the query server (QS), which interprets the resource identifier (URI) and returns the corresponding process information (Pi).
6. Method according to one of the preceding claims, wherein the protocol adapter (PA) uses specific methods for communication with different protocols, such as Profinet (PN), http (http) and MQTT (mqtt).
7. Method according to one of the preceding claims, wherein a mapping table is created in the index register (IR) and the resource identifiers (URI) are assigned to the corresponding data points (Dj).
8. Method according to one of the preceding claims, wherein a schema type resolver (STR) is operated in the query server (QS), preferably on the producer (Pro), which represents the process information (Pi) in a defined target format.
9. Method according to any of the preceding claims, wherein the query client (QC) queries multiple resource identifiers (URIs) simultaneously and aggregates the responses into a single overall response.
10. Method according to any of the preceding claims, wherein the process information (Pi) is analyzed by a Kl module (Kl) to generate predictions based on historical data points (Dj).
11. Automation arrangement (101) comprising a process network (NW), a plurality of automation components (AK), wherein at least one automation component (AK) is designed as a consumer (Kon) and another automation component (AK) as a producer (Pro) of process information (Pi), which has a data set of at least one data point (Dj), a query client (QC) on the consumer (Con), a query server (QS) on the producer (Pro), a software environment (CS) on the consumer (Con) in which a type schema (TS) for defining a structure of the data set of data points (Dj) and their attributes and a query language (FQL) are defined; a software environment (PS) on the producer (Pro) in which the type schema (TS) for defining the structure of the data set of data points (Dj) and their attributes and the query language (FQL) are also defined; wherein the query language (FQL) is designed to enable querying the process information (Pi), further showing, an index register (IR) on the producer (Pro) designed to manage and index resource identifiers (URIs), wherein the resource identifiers (URIs) are assigned to the data points (Dj) within the process network (NW), a protocol adapter (PA) on the consumer (Kon) designed to provide the resource identifiers (URIs) for communication via various network interfaces (PN,http,mqtt); wherein the consumer (Con) has an application (App) and is designed to run the application (App), wherein the application in turn is designed to query the process information (Pi) from the producer (Pro) using the query client (QC).
12. Automation arrangement (101) according to claim 11, wherein the query client (QC) comprises a query language interpreter (FQL-I) and a forwarder (FW), the query language interpreter (FQL-I) is configured to receive the query of the process information (Pi) with the query language (FQL) and to generate the resource identifiers (URI) based on the query, the forwarder (FW) is configured to process the resource identifiers (URI) and to forward the query to the corresponding protocol adapters (PA).
13. Automation arrangement (101) according to claim 10 or 11, wherein the query server (QS) comprises a resource identifier interpreter (URI-I) and a schema type resolver (STR), the resource identifier interpreter (URI-I) is configured to translate the resource identifiers (URI) into system-specific addresses, and the schema type resolver (STR) is configured to check whether the requested system-specific addresses correspond to the defined type schema (TS).
14. Automation arrangement (101) according to claim 13, wherein the query server (QS) has an index register (IR) for managing and indexing the resource identifiers (URI).