Implementing industrial automation assets with web of things description for industrial connections

Abstract

Systems and methods for managing interoperability of industrial process assets. An artificial intelligence / machine learning (AI / ML) engine receives a protocol-specific device description associated with each of the assets, maps the protocol-specific device description associated with each of the assets to a corresponding World-of-Things (WoT) transaction description, and generating code that enables industrial Internet of Things (IIOT) connectivity of the asset to the control system and / or other assets of the industrial process via the network.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to Indian Patent Application No. 202411059578, filed on 7 August 2024, the entire disclosure of which is expressly incorporated herein by reference, including the contents and teachings of any references contained herein. Background Technology

[0003] Equipment manufacturers share device description files to allow end users to control their hardware. Industrial equipment is typically described using device description files in formats such as Device Description Language (DDL), Electronic Device Description Language (EDDL), Generic Description Language (GDL), and Field Device Tool Device Type Manager (FDT DTM).

[0004] For example, some DDLs use XML-encoded markup languages ​​to define sensors, actuators, transmitters, I / O converters, valves, network drivers, and more complex devices. It provides an "electronic datasheet" for devices that are readable by both humans and machines. It bridges the physical and digital worlds in the ubiquitous space of programmability and enables automated device integration. DDLs enable a unified schema to describe sensors and devices.

[0005] Similarly, EDDL is a standard device description language used in the software core of various intelligent device protocols such as Modbus, HART, FOUNDATION fieldbus, and PROFIBUS. EDDL serves as a single common language, enabling users to integrate information from different kinds of devices using different protocols. EDDL can be compared to HTML (Hypertext Markup Language), the underlying technology that makes information from various sources easily accessible on the Internet using any kind of computer. Likewise, EDDL is based on Standard Generalized Markup Language (SGML), which was developed to make information easily accessible from various buses using various digital tools.

[0006] Equipment manufacturers create EDDL (Emergency Description Document) files, for example, to describe various characteristics of the equipment. This description also outlines information available from that specific device and how that information can be obtained through communication commands. These commands need to be issued to obtain information about specific parameters of the device. This facilitates equipment management and the addition of new field equipment. Furthermore, the device's characteristics can be updated by updating the equipment description file.

[0007] While device description languages ​​are useful for managing devices, the devices themselves typically communicate according to proprietary protocols, which limits interoperability, accessibility, and security. For example, EDDLs are vendor-dependent, and each vendor describes its own proprietary device format. Vendors conforming to EDDL formats can interoperate with each other but not with vendors conforming to DDL, GDL, FDT, DTM, etc. In some cases, custom DDLs are required when device descriptions are not available from the manufacturer. There is a need in industry for a way to make various device description formats compatible with each other and compatible with the broader Internet as a whole. Summary of the Invention

[0008] Various aspects of this disclosure allow devices to be directly addressed and discovered over a network, thereby promoting interoperability and reducing reliance on proprietary protocols. Utilizing Web of Things (WoT) Thing Descriptions (TDs) to describe Industrial Internet of Things (IIoT) assets creates a more decentralized and standardized approach, and enables direct communication and interaction between IIoT devices, applications, and services using web technologies and protocols such as HTTP, RESTful APIs, and JSON. Allowing IIoT assets to communicate, share data, and control locally / remotely (whether on-premises or in the cloud) promotes autonomous operation / intelligence.

[0009] In one aspect, an interoperability system manages industrial process assets, including a control system coupled to the assets and configured to generate control signals for controlling the assets. The assets perform operations of the industrial process in response to the control signals. The interoperability system includes a device description processor communicatively coupled to the control system and a memory communicatively coupled to the device description processor. The memory stores computer-executable instructions that, when executed, configure the device description processor to execute an AI / ML engine. The AI / ML engine receives a protocol-specific device description associated with each asset, maps the protocol-specific device description associated with each asset to a corresponding WoT (World of Things) description, and generates code. When executed, the code implements IIoT (Internet of Things) connectivity between the assets and the control system and / or other assets in the industrial process via a network.

[0010] In another approach, one method includes receiving a protocol-specific device description associated with each of a plurality of assets in an industrial process. The industrial process includes a control system coupled to the assets and configured to generate control signals for controlling the assets. The assets perform operations of the industrial process in response to the control signals. The method also includes executing an AI learning model to map the protocol-specific device description associated with each asset to a corresponding WoT (Web of Things) description and generate code. When executed, the code implements IIoT connectivity between the assets and the control system and / or other assets in the industrial process via a network.

[0011] Other aspects, advantages and features of this disclosure will be apparent in part and are indicated in part herein. Attached Figure Description

[0012] Figure 1 A process control system according to one embodiment is shown.

[0013] Figure 2A and Figure 2B An AI / ML-based system for automatically generating WoT (World of Things) descriptions and using WoT descriptions to establish IIoT connectivity is illustrated according to one embodiment.

[0014] Figure 3 This is a flowchart illustrating an example process for training an AI engine according to one embodiment.

[0015] Figure 4A This illustrates a WoT (WoT) transaction description workflow based on an embodiment using an AI / ML engine.

[0016] Figure 4B This illustrates a WoT transaction description workflow based on an embodiment using an agent engine.

[0017] Figure 5 An example process for mapping a 4-20mA closed-loop device to a WoT transaction description is shown according to one embodiment.

[0018] Throughout the accompanying drawings, corresponding reference numerals denote corresponding parts. Detailed Implementation

[0019] The features and other details of the concepts, systems, and techniques sought to be protected herein will now be described in more detail. It should be understood that any specific embodiments described herein are shown by way of illustration and are not intended to limit the scope of this disclosure and the concepts described herein. Features of the subject matter described herein may be employed in various embodiments without departing from the scope of the sought-protected concepts.

[0020] In traditional IIoT paradigms, devices connect to the internet and communicate with centralized cloud-based services. This presents problems such as a lack of interoperability and increased latency due to reliance on cloud services for data processing.

[0021] The World Wide Web (WoT) describes a set of standards from the World Wide Web Consortium (W3C) for interoperability across different Internet of Things (IoT) platforms and application domains. WoT aims to preserve and complement existing IoT standards and solutions to improve interoperability, accessibility, scalability, and security. Key components of WoT are: Thing Descriptions, WoT Application Programming Interfaces (APIs), and WoT Gateways. When combined with Artificial Intelligence (AI) and / or Machine Learning (ML), WoT opens up new possibilities for intelligent and dynamic interaction between devices and systems.

[0022] Figure 1 The basic structure of an example process control system 100 is shown. In one embodiment, at least one process 102 is communicatively connected to a controller 104 and a sensor 106. The controller 104 may include a programmable logic controller (PLC), supervisory control and data acquisition (SCADA), human-machine interface (HMI) data acquisition system (DAS), etc. Process 102 has inputs 108 and 110, which include inputs necessary for the process to create output 112. In one embodiment, input 108 includes energy for operating process 102, and input 110 includes physical or chemical raw materials for process 102. Output 112 includes physical or chemical products from process 102 or energy production in the form of electricity, etc.

[0023] Sensor 106 may include an IED (Intelligent Electronic Device). As used herein, an IED is a computing electronic device optimized to perform a specific function or set of functions. Examples of IEDs include smart utility meters, smart sensors, power quality meters, and other metering devices.

[0024] Controller 104 sends data to at least one process 102 to guide its operation according to the objectives of controller 104. The data sent includes commands for operating various types of process elements or assets 114 (such as pumps, motors, valves, actuators, electrostatic precipitators, etc.) of process 102. Asset 114 can be any mechanical, chemical, electrical, biological, or combined mechanism or collection of mechanisms for converting energy and materials into value-added products or production. Furthermore, asset 114 can include electrical or electronic equipment, such as machinery associated with industrial process 102 (e.g., manufacturing or natural resource extraction operations). Asset 114 can also include controls and / or auxiliary equipment associated with industrial process 100, such as field devices (e.g., RTUs, PLCs, actuators, sensors, HMIs) for performing, analyzing, and / or controlling process variable measurements. It should be understood that sensor 106 can also be considered an asset.

[0025] In one or more embodiments, asset 114 is installed or located in one or more facilities (i.e., buildings) or other physical locations (i.e., sites) associated with industrial process 102. Facilities may correspond to, for example, industrial buildings or plants. Furthermore, physical locations may correspond to, for example, geographical areas or locations.

[0026] Sensor 106 monitors process 102 at various points and collects data from these points. Sensor 106 then sends the collected data to controller 104. Based on the collected data, controller 104 can send additional commands to process 102. In this way, system 100 forms a control feedback loop, in which controller 104 reacts to changes in process 102 observed by sensor 106. Different actions performed by process 102 according to commands from controller 104 can alter the data collected by sensor 106, thereby causing controller 104 to make further adjustments in response to those changes. By implementing this control feedback loop, at least one process 102 can be effectively controlled by controller 104.

[0027] To ensure safe operation, controller 104 includes one or more condition or asset monitoring systems 116 responsive to sensor 106 for performing vibration analysis, motor current characteristic analysis, ultrasonic analysis, thermal analysis, etc., on critical assets 114. In the illustrated embodiment, system 100 includes a history recorder 118 configured to capture and store industrial data, including one or more process, alarm, and event history data. System 100 also includes one or more servers, referred to as data analysis servers 120, for analyzing the stored industrial data.

[0028] Various aspects of this disclosure allow devices such as Asset 114 to be directly addressable and discoverable on the network, thereby promoting interoperability and reducing reliance on proprietary protocols. For clarity: any vendor-specific asset will communicate using vendor-defined protocols such as Modbus, PROFIBUS, HART, Fieldbus, OPC, etc. By utilizing the protocol details available through WoT (Wo of Things) descriptions, various aspects of this disclosure allow connection to these assets and control of the network via protocol commands. Otherwise, vendor asset communication and control would be limited to developing their own HMIs to monitor and control the assets. This dependency is eliminated through WoT descriptions on the network.

[0029] Using WoT (Things of Things) descriptions to describe IIoT assets creates a more decentralized and standardized approach, and enables direct communication and interaction between IIoT devices, applications, and services using network technologies and protocols such as HTTP, RESTful APIs, and JSON.

[0030] Allowing IIoT assets to communicate, share data, and be controlled locally or remotely (whether internally or in the cloud) facilitates autonomous operation / intelligence. In one embodiment, an AI / ML engine, such as an AI Generative Pre-Trained Transformer (AI-GPT) model, provides IoT web generation and onboarding for the assets. In another embodiment, an agent engine provides IoT web generation and onboarding for the assets. The agent engine is an autonomous AI system that can independently plan, reason, and execute multi-step workflows.

[0031] Now for reference Figure 2A The system 200, embodying various aspects of this disclosure, provides AI / ML-based generation of WoT transaction descriptions and enabling / loading of asset 114. In one embodiment, the AI / ML engine 202 receives input of a device description 204 of asset 114 in its raw format (e.g., DDL / EDDL, custom DDL, GDL, FDT DTM, datasheet / specification, Redfish specification / WoT transaction description, etc.). In one embodiment, the AI / ML engine 202 includes a device description processor that executes computer-executable instructions for one or more of Large Language Modeling (LLM), Optical Character Recognition (OCR), prompting engineering, Small Language Modeling (SLM), etc., to generate a WoT transaction description of asset 114.

[0032] According to one embodiment, SLM is also used to model / train the AI / ML engine 202, which enables it to run on CPUs, smartphones, etc., thereby eliminating the need for dedicated GPU servers to train the LLM. With the development of reliable SLM models (Phi-3) (e.g., Llama, Mistral, etc.), this automatic generation of WoT (World of Things) descriptions and network-enabled implementation can be achieved through small-scale devices such as mobile devices.

[0033] Furthermore, the AI / ML engine 202 performs validation of the generated object descriptions according to the WoT JSON schema. For example... Figure 2A As shown, at 206, system 200 enables IIoT connectivity for asset 114 at 208 by providing one or more of the following: device and IO connectivity (health status), protocol binding, security, communication, discovery, and loading. Assets connect to IIoT 208 via APIs (e.g., MQTT, CoAP, HTTP / RESTful, OPC UA, etc.) using the asset's WoT transaction description. According to one embodiment, the operation at 206 includes automatically generating a corresponding WoT transaction description for each asset by an AI learning model. Once asset 114 is connected to IIoT 208, one or more local computers 210 and / or one or more remote computers 212 can access and manage asset 114 via network dashboards, analytics, and services.

[0034] In one embodiment, the AI / ML engine 202 utilizes the device description of asset 114 to generate a WoT thing description for integration with WoT. As mentioned above, device manufacturers provide device descriptions in various formats, such as Device Description Language (DDL), Electronic Device Description Language (EDDL), Generic Description Language (GDL), Field Device Tool Device Type Manager (FDT DTM), etc. However, in some cases, a custom DDL is necessary. For example, a custom DDL is necessary for devices employing 4-20mA current loops. The 4-20mA standard is a widely used analog current loop in industrial automation, where process variables are represented by proportional current signals ranging from 4mA (minimum) to 20mA (maximum). This standard is a common communication method for analog measurements from devices and sensors 106 to controller 104. While the 4-20mA signal is an analog representation of a physical value, the Device Description Language (DDL) typically focuses on digital devices and values. To create a custom DDL for these devices, the 4-20mA analog measurement is converted into a digital representation.

[0035] Figure 5An example process for mapping a 4-20mA closed-loop device to a WoT (World of Things) description is illustrated according to one embodiment. In one embodiment, a sensor (e.g., temperature sensor 502) provides an analog signal representing a measured process variable (e.g., temperature). A transmitter 504 converts the output temperature signal from sensor 502 into a current signal. As is known in the art, a 4mA current value represents a 0% scale, a 20mA current value represents a 100% scale, and any current value between 4mA and 20mA represents a proportional percentage between 0% and 100%. A 2-wire loop routes the 4-20mA signal from transmitter 504 to receiver 506 and back again. Receiver 506 receives and interprets the analog 4-20mA current signal. An analog-to-digital converter (ADC) 508 (e.g., ADS1115, built-in PLC ADC, IoT gateway, etc.) first converts the 4-20mA to a voltage (1-5V) using a resistor (e.g., 250 Ω), which generates the ADC value. In one embodiment, the ADC value is converted to a process unit using the following scaling formula:

[0036]

[0037] For example, for a temperature sensor with a range of 0-100°C, the conversion from ADC value to process units is:

[0038]

[0039] Once converted, the process unit is written to register 510, such as a Modbus holding register (e.g., 40001, 40002, etc.), for mapping to a specific communication protocol. Any number of communication protocols can be used, such as Modbus, HART, MQTT, FOUNDATION fieldbus, and PROFIBUS. The converted value of the process unit can then be used to generate a custom DDL 512. Once the custom DDL 512 is generated, it can be used in the same way as any device description.

[0040] Figure 2BThis is a flowchart illustrating an example process for AI / ML-based asset-IoT connectivity with WoT. The process begins with asset 114 and its device description, which serves as input to AI / ML engine 202. AI / ML engine 202 includes a device description processor for generating WoT thing descriptions. The WoT thing description establishes a connection to network 222 via API 220. This approach to AI / ML-based asset-IoT connectivity with WoT offers several advantages. It enables IoT connectivity for existing or legacy assets in all device description formats. This is particularly important in industrial environments where a large number of valuable devices often predate modern IoT standards. By creating WoT thing descriptions for these assets, they can be integrated into connected IIoT systems without requiring a full overhaul or costly updates and replacements.

[0041] This process facilitates online monitoring and continuous training of updated device description data and associated repositories or databases. This dynamic feature allows the AI / ML engine 202 to adapt to and learn the evolving characteristics and operational data of connected assets. Industrial environments frequently undergo changes, such as the integration of new equipment or modifications to existing equipment characteristics. These changes necessitate updated device descriptions to ensure continued safety and operational integrity. The AI / ML engine 202 maintains the accuracy and relevance of its digital representation by periodically updating the current device description.

[0042] The core feature of WoT's AI / ML-based generation of device descriptions is the use of technologies such as large language models (LLM), optical character recognition (OCR), and sophisticated prompting engineering techniques. This intelligent generation process automates and streamlines the creation of device descriptions.

[0043] The process is also highly scalable and can be deployed across various infrastructure layers. For example, it can be deployed locally on devices or on edge devices via gateways. It can be deployed via local or remote servers, internal infrastructure, or cloud environments. This flexibility allows industrial organizations to tailor solutions to their specific architectural needs and constraints.

[0044] The generated WoT transaction descriptions serve as the foundation for "communication connectivity" API modeling and associated contextual analysis and services. WoT transaction descriptions not only define assets but also build upon them to enable the creation of standardized APIs for interacting with assets and deriving meaningful insights from their data.

[0045] AI / ML-based asset-IoT connectivity with WOT can provide recommendations for appropriate protocol communication based on the thing description. Recommendations can consider protocols supported by the asset itself, such as suggested Modbus versus OPC-Modbus. This intelligent protocol binding approach simplifies asset integration and loading.

[0046] Furthermore, considering combinations of REST and publish / subscribe, as well as HTTP, CoAP, REST, MQTT, etc., this approach includes recommendations for network protocols such as HTTP, CoAP, and MQTT. The recommended protocol will depend in part on resources, such as the asset's memory and power requirements. For example, for assets with limited resources (such as low memory and power requirements), the CoAP network protocol is superior to HTML or REST. These assets with limited resources are typically embedded hardware. This ensures robust and efficient data exchange between the asset and network-based applications. It also allows for the delivery of real-time data for real-time monitoring and analysis.

[0047] Figure 3 This is a flowchart illustrating an example AI-GPT process applicable to the historicalization and training of AI / ML engine 202 (or AI / ML model). The process begins with a device description 204 from one of assets 114 in its original format (e.g., DDL / EDDL, custom DDL, GDL, FDT DTM, datasheet / specification, Redfish specification / WoT TD, etc.). The device description is provided as input from online-offline injection 302. In one embodiment, online injection transmits the device description directly via an API or a network system utilizing network protocols in real-time or near real-time. In another embodiment, offline injection is used when the data source of the device description is not actively connected to the network. The offline injection method temporarily stores the data. Once the network connection is re-established, the stored data is transmitted to AI / ML engine 202.

[0048] The AI / ML engine 202 in this embodiment is implemented using the exemplary PrivateGPT 308. However, it should be understood that the AI / ML engine 202 can be developed by modifying, adapting, or creating AI / ML engines or models that operate based on the principles of agent AI, generative AI, AI / ML models, large language models, small language models, etc., wherein, as discussed herein, the AI / ML engine 202 is developed and customized to help provide IoT World Wide Web generation and asset enablement / loading. The AI / ML engine 202 does not need to be restricted to a private engine.

[0049] PrivateGPT 308 responds to a user query 306 by using a device description processor to perform document ingestion 320 and subsequent retrieval 322. In some embodiments, the user may correspond to any entity operatively communicating with a computing device, such as another computing system. Document ingestion is how the model processes device description data 204. PrivateGPT 308 extracts text 310 from device description 204. The extracted text is segmented into smaller, manageable chunks 312. Segmenting the text into smaller chunks allows the AI / ML engine to process large device descriptions. Each text chunk is transformed into a vector representation or embedding 314.

[0050] These embeddings 314 capture the semantic meaning of the extracted text 310. Therefore, texts with similar meanings will have vector representations that are close to each other. Representing data in this way allows the AI / ML engine 202 to understand the underlying concepts and relationships within the text. Using vector representations, PrivateGPT is not limited to keyword matching when performing queries. The AI / ML engine 202 (PrivateGPT 308 in the illustrated embodiment) creates a semantic index 316. The semantic index 316 is a data structure built based on the generated embeddings / vector representations 314. The semantic index 316 allows PrivateGPT to quickly find relevant text blocks based on semantic similarity to the input query. The embeddings 314 and the semantic index 316 are stored in a vector database 318. The vector database 318 is a dedicated database for storing and querying vector representations of data.

[0051] As for Figure 3 The retrieval process 322 begins with user 304 inputting a query 306. The query is embedded 324, a process similar to embedding generation 314 during document ingestion 320. The query is converted into a vector representation, allowing the AI / ML engine 202 to understand the meaning of the query rather than relying on matching keywords. PrivateGPT 308 performs a semantic search 326 using the vector database 328 to generate results 330. The semantic search 326 utilizes the semantic index 316 created during document ingestion 320 and stored in the vector database 318 to find the stored device description 204 whose embedding is most similar to the embedding of the user query.

[0052] A validation step occurs at 332 to determine if the generated result 330 is accurate. If the result is deemed correct, PrivateGPT 308 is ready to process another user query 306. If the result is determined to be incorrect, a feedback mechanism is engaged. PrivateGPT 308 is fed relevant answers 334. This relevant answer 334 again triggers the document ingestion process 320, but this time incorporating relevant information. This feedback loop is a key aspect of how the AI / ML engine 202 is historically processed and automatically trained 336. By learning from its errors and incorporating relevant answers through the ingestion process, the AI / ML engine continuously refines its understanding and improves the accuracy of its responses over time.

[0053] exist Figure 3 In this embodiment, document ingestion 320 and retrieval process 322 are shown in a linear fashion, where one device description 204 or query 306 is processed at a time via Private GPT 308. Private GPT 308 or any AI / ML engine 202 used can process several device descriptions 204 and queries 306 at a time. For example, the batch size of the engine can be adjusted to increase the amount of data being processed at one time.

[0054] Figure 4A This illustration shows a WoT transaction description workflow for migrating legacy asset descriptions (e.g., DDL, GDL, EDDL) and creating a WoT transaction description for asset 114, according to embodiments of this disclosure. In one embodiment, at 402, AI / ML engine 202 learns to analyze the device description 204 of asset 114 in its original format (e.g., DDL / EDDL, GDL, FDT DTM, datasheet / specification, etc.). At 404, AI / ML engine 202 uses, for example, JSON to map and prepare the WoT transaction description. At 406, AI / ML engine 202 predicts and recommends suitable protocol bindings for each specific asset 114 based on its device description, and then verifies each WoT transaction description at 408. To allow connectivity, AI / ML engine 202 generates code (e.g., HTTP, RESTful API, etc.) to integrate the verified WoT transaction descriptions into the network for improved interoperability, accessibility, scalability, and security.

[0055] Figure 4BThis illustration shows a WoT transaction description workflow for migrating legacy asset descriptions (e.g., DDL, GDL, EDDL) and creating a WoT transaction description for asset 114, according to embodiments of this disclosure. In one embodiment, at 402, agent engine 412 learns to analyze device description 204 of asset 114 in its original format (e.g., DDL / EDDL, GDL, FDT DTM, datasheet / specification, etc.). At 404, agent engine 412 uses, for example, JSON to map and prepare the WoT transaction description. At 406, agent engine 412 predicts and recommends suitable protocol bindings for each specific asset 114 based on its device description, and then verifies each WoT transaction description at 408. To allow connectivity, agent engine 412 generates code (e.g., HTTP, RESTful API, etc.) to integrate the verified WoT transaction descriptions into the network for improved interoperability, accessibility, scalability, and security.

[0056] Although from Figure 4A The AI / ML engine 202 generates device descriptions or protocol mappings when prompted, but Figure 4B The agent engine 412 is capable of autonomously discovering devices, analyzing their capabilities, determining optimal integration strategies, executing complete loading workflows, verifying results, and handling anomalies. Agent engine 412 is more autonomous because it can focus on creating WoT (Wo-Telematics) descriptions of assets and integrating them into the network without requiring the same level of human intervention as the AI / ML engine 202. Aspects of this disclosure are applicable to smart home applications, mashups of IoT apps via a unified WoT API, and edge unified architecture (UA) converters (e.g., Modbus to OPC UA). Furthermore, aspects of this disclosure are applicable to natural language interfaces. By integrating WoT and LLM, natural language commands can be used to control and monitor industrial automation systems. Additionally, aspects of this disclosure are applicable to intelligent decision support. By analyzing real-time data, historical records, and contextual information, LLM helps operators make informed decisions.

[0057] The World Wide Web of Things (WoT) is an extension of the Internet of Things (IoT) that focuses on enabling seamless interoperability and integration of IoT devices and services through network standards. The inventors recognized the importance of interoperability and connectivity in providing comprehensive solutions to industrial automation customers. WoT provides a standardized framework that allows different IoT devices, platforms, and services to communicate with each other, regardless of their underlying technologies or protocols.

[0058] The adoption of WoT offers numerous benefits, including improved interoperability, accessibility, scalability, and security. By adhering to network standards, WoT enhances the ability of different IoT systems to work together. This improved interoperability allows for seamless data exchange and coordinated action between previously isolated devices. This is particularly real and important in industrial environments where numerous assets with different communication protocols must be integrated for efficient operation. Utilizing the inherent flexibility of the WoT architecture and applying it to IIoT allows for scalability, where industrial systems can seamlessly grow and integrate more assets / devices. Connecting these assets / devices to WoT improves security and safety, as devices can be monitored, analyzed, and configured remotely and in real time.

[0059] Another benefit of adopting WoT is a unified user experience, including application mashup, an intuitive web-based interface, easy device discovery, and seamless integration. Application mashup development becomes simpler, allowing combinations of functionality from different devices and services to be integrated into applications. The intuitive web-based interface provides familiar and accessible tools for monitoring and controlling industrial assets. Easy device discovery through WoT simplifies the process of identifying new devices and connecting them to industrial systems. Seamless integration abstracts away the underlying complexities of different technologies. This provides a unified and intuitive way to interact with devices / assets in a connected industrial environment.

[0060] Connecting industrial assets and equipment to the World of Technology (WoT) enables data-driven decision-making, optimized operations, and improved energy efficiency. Industrial organizations can leverage WoT connectivity to make smarter, data-driven decisions. Real-time data sharing and analytics enable process optimization. Workflows become smoother and can lead to reduced system downtime. This also allows for more precise resource management, and thus improved energy efficiency.

[0061] There are reductions in time and costs associated with managing the lifecycle of assets. Automating these assets and their equipment through WoT simplifies the process of managing them. Equipment, even non-smart equipment, can be automatically deployed into industrial systems. From there, the equipment can be monitored, configured, and analyzed locally or remotely. WoT also simplifies the decommissioning process when equipment reaches the end of its lifespan or is no longer needed within the industrial system. Just as deployment can be automated, the removal and logical disconnection of equipment from the network can also be managed through the WoT framework.

[0062] By enforcing network standards for communication and data exchange, WoT ensures standardized interaction across different devices. This standardization leads to greater consistency and uniformity in how devices are managed, regardless of the underlying technology or lack thereof.

[0063] WoT integration offers enhanced scalability and flexibility to accommodate increasing numbers of devices, users, and data. This results in the ability to handle increased workloads and adapt to changing requirements. This scalability and flexibility is particularly valuable in industrial environments where production needs can change rapidly.

[0064] Another notable benefit of WoT integration is the reduced development and delivery time. Industrial devices now connected to WoT allow developers to apply existing network development tools to them. This eliminates the need to learn and implement the appropriate industrial protocols for each device. Leveraging the WoT framework, every device has the potential to become a smart device.

[0065] This disclosure also includes the automatic generation of WoT (World of Things) descriptions for assets participating in industrial control systems. For example, in a factory, a DDL (Data Definition Language) description can be used to describe equipment from a manufacturer. When such equipment is encountered, whether the asset is identified by physical scanning or by using a machine learning model for image recognition, the AI / ML engine 202 is configured in one embodiment to automatically create a WoT description format for the device (reusing DDL details), and then link the device to the IIoT / IoT world by selecting an appropriate / matching protocol binding.

[0066] Embodiments of this disclosure may include a dedicated computer, which includes various computer hardware as described in more detail herein.

[0067] For illustrative purposes, programs and other executable program components may be shown as discrete blocks. However, it should be recognized that such programs and components reside in different storage components of the computing device at different times, and are executed by one or more data processors of the device.

[0068] Although described in conjunction with an example computing system environment, the embodiments within this disclosure may operate with other dedicated computing system environments or configurations. The computing system environment is not intended to impose any limitation on the scope or functionality of any aspect of this disclosure. Furthermore, the computing system environment should not be construed as having any dependency or requirement relating to any one or combination of the components shown in the example operating environment. Examples of computing systems, environments, and / or configurations that may be suitable for use with aspects of this disclosure include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, mobile phones, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the foregoing systems or devices, etc.

[0069] Embodiments of aspects of this disclosure can be described in the general context of data and / or processor-executable instructions (such as program modules) stored in one or more tangible, non-transitory storage media and executed by one or more processors or other devices. Typically, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform a particular task or implement a particular abstract data type. Aspects of this disclosure can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside in both local storage media and remote storage media, including memory storage devices.

[0070] In operation, the processor, computer, and / or server can execute processor-executable instructions (e.g., software, firmware, and / or hardware), such as those shown herein, to implement aspects of this disclosure.

[0071] The embodiments can be implemented using processor-executable instructions. These processor-executable instructions can be organized into one or more processor-executable components or modules on a tangible processor-readable storage medium. Furthermore, the embodiments can be implemented using any number and organization of such components or modules. For example, aspects of this disclosure are not limited to the specific processor-executable instructions or specific components or modules shown in the accompanying drawings and described herein. Other embodiments may include different processor-executable instructions or components having more or fewer functions than those shown and described herein.

[0072] Unless otherwise stated, the order of execution or performance of the operations shown and described herein according to various aspects of this disclosure is not essential. That is, unless otherwise stated, operations may be performed in any order, and embodiments may include more or fewer operations than those disclosed herein. For example, a particular operation is contemplated to be performed or executed before, simultaneously with, or after another operation within the scope of this disclosure.

[0073] When describing elements of this disclosure or embodiments thereof, the articles “a,” “an,” “the,” and “the” are intended to indicate the presence of one or more elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements may be present in addition to those listed.

[0074] Not all components shown or described are essential. Furthermore, some implementations and embodiments may include additional components. Variations in the arrangement and type of components may be made without departing from the spirit or scope of the claims set forth herein. Additional, different, or fewer components may be provided, and components may be combined. Alternatively or additionally, a component may be implemented from several components.

[0075] The above description illustrates embodiments by way of example and not limitation. This description enables those skilled in the art to make and use aspects of this disclosure, and describes various embodiments, adaptations, variations, alternatives, and uses of aspects of this disclosure, including those currently considered best modes for carrying out the embodiments. Furthermore, it should be understood that aspects of this disclosure are not limited in their application to the details of the construction and arrangement of components set forth in the following description or shown in the accompanying drawings. Aspects of this disclosure can have other embodiments and can be practiced or performed in various ways. Moreover, it should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered limiting.

[0076] It is obvious that modifications and variations are possible without departing from the scope of this disclosure as defined in the appended claims. Since various changes can be made to the above-described constructions and methods without departing from the scope of this disclosure, all that is contained in the above description and shown in the drawings is intended to be illustrative rather than restrictive.

[0077] In view of the foregoing, it will be seen that at least some embodiments help to solve at least some of the problems discussed herein, and at least some embodiments help to achieve one or more advantageous results.

[0078] The abstract and summary are provided to help the reader quickly determine the nature of the technical disclosure. They are provided so that they will not be used to interpret or limit the scope or meaning of the claims. The summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed embodiments. The summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to help identify the claimed subject matter.

Claims

1. An interoperability system for managing assets in an industrial process, the industrial process including a control system coupled to the asset and configured to generate control signals for controlling the asset, the asset performing operations of the industrial process in response to the control signals, the interoperability system comprising: The device describes a processor that is communicatively connected to the control system. and A memory communicatively connected to the device description processor stores computer-executable instructions that, when executed, configure the device description processor to execute an artificial intelligence / machine learning engine (AI / ML), wherein the AI / ML engine: Receive a protocol-specific device description associated with each of the assets; Map the protocol-specific device description associated with each of the assets to the corresponding Internet of Things (WoT) thing description; and Generate code that, when executed, enables Industrial Internet of Things (IIoT) connectivity for each of the assets via the network to the control system and / or to other assets in the industrial process.

2. The interoperability system of claim 1, wherein the computer-executable instructions, when executed, also configure the device description processor to train the AI / ML engine using a plurality of protocol-specific device descriptions.

3. The interoperability system according to any one of claims 1-2, wherein the protocol-specific device description is selected from the group consisting of: DDL, GDL, EDDL, DTM, Device Description Language (DDL), General Description Language (GDL), Electronic Device Description Language (EDDL), Field Device Tool Device Type Manager (FDT DTM), data tables, and specifications.

4. The interoperability system according to any one of claims 1-3, wherein the protocol-specific device description is a custom DDL, and wherein the custom DDL is mapped from 4-20mA signals.

5. The interoperability system according to any one of claims 1-4, wherein the AI / ML engine performs one or more of the following: classifier, clustering process, regression process, large language model (LLM), optical character recognition (OCR), cue engineering, or decision tree process.

6. The interoperability system according to any one of claims 1 to 5, wherein the AI / ML engine predicts a protocol binding suitable for each of the assets based on the WoT transaction description.

7. The interoperability system according to any one of claims 1 to 6, wherein the AI / ML engine validates the WoT thing description according to the WoT JavaScript Object Notation (JSON) schema.

8. The interoperability system according to any one of claims 1-7, wherein the AI / ML engine uses JSON to map the protocol-specific device description associated with each of the assets to a corresponding WoT transaction description.

9. The interoperability system according to any one of claims 1 to 8, wherein the AI / ML engine automatically generates a corresponding WoT transaction description for each of the assets by reusing the protocol-specific device description and by selecting a suitable protocol binding based on the WoT transaction description to link each of the assets to IIoT.

10. A method comprising: Receive a protocol-specific device description associated with each of a plurality of assets in an industrial process, the industrial process including a control system coupled to the asset and configured to generate control signals for controlling the asset, the asset performing operations of the industrial process in response to the control signals; Execute an artificial intelligence (AI) learning model to map the protocol-specific device description associated with each of the assets to the corresponding Internet of Things (WoT) thing description; and Generate code that, when executed, enables Industrial Internet of Things (IIoT) connectivity for each of the assets via the network to the control system and / or to other assets in the industrial process.

11. The method of claim 10, further comprising training the AI ​​learning model using a plurality of protocol-specific device descriptions.

12. The method according to any one of claims 10 to 11, wherein the protocol-specific device description is selected from the group consisting of: DDL, custom DDL, GDL, EDDL, DTM, device description language (DDL), general description language (GDL), electronic device description language (EDDL), field device tool device type manager (FDT DTM), datasheet or specification.

13. The method of any one of claims 10 to 12, wherein the protocol-specific device description is a custom DDL, and the method further comprises mapping the custom DDL from a 4-20mA signal.

14. The method according to any one of claims 10 to 13, wherein the AI ​​learning model comprises one or more of the following: a classifier, a clustering process, a regression process, a large language model (LLM), optical character recognition (OCR), a cueing engineering process, or a decision tree process.

15. The method according to any one of claims 10 to 14, further comprising: The AI ​​learning model predicts the appropriate protocol binding for the asset based on the WoT (World of Things) description.

16. The method according to any one of claims 10 to 15, further comprising verifying the WoT thing description by the AI ​​learning model according to the WoT JavaScript Object Notation (JSON) schema.

17. The method of any one of claims 10 to 16, wherein the AI / ML engine uses JSON to map the protocol-specific device description associated with each of the assets to a corresponding WoT thing description.

18. The method according to any one of claims 10 to 17, further comprising automatically generating a corresponding WoT transaction description for each of the assets by the AI ​​learning model.

19. The method of claim 18, wherein automatically generating the corresponding WoT transaction description includes reusing the protocol-specific device description and linking each of the assets to IIoT by selecting a suitable protocol binding based on the WoT transaction description.

20. The method according to any one of claims 18 to 19, wherein automatically generating the corresponding WoT transaction description comprises: Based on one or more resource constraints of the asset, recommend one or more of the HTTP, CoAP, REST, or MQTT protocols to support real-time data communication.

Images