DESC:EARLIEST PRIORITY DATE:
This Application claims priority from a Provisional patent application filed in India having Patent Application No. 202441030609, filed on April 16, 2024, and titled “PETROLEUM RETAIL OUTLET MANAGEMENT, MONITORING AND UPGRADING METHODS USING IOT DEVICES WITH PROTOCOLINDEPENDENT ADAPTER”.
FIELD OF INVENTION
[001] Embodiments of the present disclosure relate to the field of industrial automation and Internet of Things (IoT) systems, and more particularly to systems and methods for enabling dynamic configuration of an IoT device to communicate with a variety of field devices using different communication protocols, thereby facilitating data collection, processing, and transmission in heterogeneous operational environments.
[002] Industrial environments such as fuel stations, manufacturing plants, and utility grids rely heavily on a range of field devices such as, but are not limited to, fuel dispensing units, tank gauges, temperature sensors, pressure monitors, air quality sensors, and tyre inflation modules to collect and transmit operational data. These field devices typically use varied communication protocols, including but not limited to RS-232, RS-485, CAN bus, Modbus, and TCP/IP, depending on the device manufacturer and intended application.
[003] In conventional systems, the integration of Internet of Things (IoT) devices with such heterogeneous field devices presents significant challenges. Most IoT deployments require extensive manual configuration to establish communication with each field device. For instance, every time a new field device is added to a fuel station, technical personnel must manually configure protocol parameters, adjust firmware, and often update the communication stack of the IoT device. This setup process not only introduces delays and increases deployment costs but also demands specialized knowledge of each field device's communication behavior.
[004] Furthermore, legacy field devices may not readily support modern networking standards, and their data formats, timing intervals, and control commands vary widely. In such environments, IoT devices must be able to not only communicate using different protocols but also understand diverse data structures and apply specific data transformation logic to normalize the received information.
[005] The situation becomes even more complex when a field device presents ambiguous identifiers or overlapping protocol signatures. In such cases, existing IoT systems are often unable to autonomously determine the correct protocol, resulting in failed integrations or requiring cloud-based interventions, such as remote support or firmware updates, to resolve.
[006] There is also the operational burden of maintaining compatibility when field devices are replaced or firmware is updated on either the IoT device or the field device. These changes may render previous configurations invalid, necessitating a new round of manual intervention and testing. Given these limitations, current solutions lack scalability, flexibility, and autonomy in managing protocol interoperability across a wide range of industrial devices. These issues can hinder digital transformation efforts in industrial automation and data acquisition.
[007] For example, in a typical fuel station, multiple field devices from different vendors may be installed, each supporting a different protocol and data structure. Deploying an IoT-based monitoring system in such an environment requires highly customized firmware and hardware configurations, along with skilled labor for commissioning and updates.
[008] Thus, there is a need for a system and method that enables IoT devices to autonomously interface with diverse field devices by automatically identifying communication protocols and configuring appropriate communication stacks, thereby minimizing manual intervention, enhancing deployment efficiency, and ensuring seamless data collection across heterogeneous industrial environments.
BRIEF DESCRIPTION
[009] In accordance with an embodiment of the present disclosure, an Internet of Things (IoT) device is provided. The IoT device comprises one or more processors and a memory having computer-readable instructions stored thereon that, when executed by the one or more processors, cause the IoT device to receive a respective identification information from one or more field devices communicatively coupled to the IoT device using a a handshake process, active probing, or protocol discovery; retrieve a respective communication protocol stack from a local database based on the respective identification information for each of the one or more field devices; and receive and process respective data from the one or more field devices based on the respective communication protocol stack, thereby obtaining a respective processed data, wherein upon encountering multiple candidate communication protocol stacks based on the respective identification information, the IoT device queries a cloud-based database to retrieve communication protocol identification rules, heuristics, or pattern-matching instructions for determining the respective communication protocol stack among the multiple candidate communication protocol stacks.
[0010] In accordance with another embodiment of the present disclosure, a cloud-based computing system is provided. The cloud-based computing system comprises a cloud-based database adapted to store a plurality of communication protocol stacks corresponding to one or more field devices, wherein a respective communication protocol stack from the plurality of communication protocol stacks is for execution by a respective Internet of Things (IoT) device communicatively coupled via a first network interface with the cloud-based computing system while communicating with the one or more field devices for data acquisition.
[0011] In accordance with yet another embodiment of the present disclosure, a system is provided. The system comprises one or more field devices; a cloud-based computing system, wherein a cloud-based database is adapted to store a plurality of communication protocol stacks corresponding to the one or more field devices; and a plurality of Internet of Things (IoT) devices, wherein the plurality of Internet of Things (IoT) devices are communicatively coupled with the cloud-based computing system via a first network interface and communicatively coupled with respective field devices of the one or more field devices via a second network interface. Each IoT device comprises one or more processors and a memory having computer-readable instructions stored thereon that, when executed by the one or more processors, cause the IoT device to: receive a respective identification information from the respective field devices communicatively coupled with the IoT device using a handshake process, active probing, or protocol discovery; retrieve a respective communication protocol stack from a local database based on the respective identification information for each of the respective field devices; and receive and process respective data from the respective field devices based on the respective communication protocol stack, thereby obtaining a respective processed data.
[0012] In accordance with yet another embodiment a method is provided. The method is implemented by an Internet of Things (IoT) device and comprises receiving, by one or more processors of the IoT device, a respective identification information from one or more field devices communicatively coupled to the IoT device using a handshake process, active probing, or protocol discovery; retrieving, by the one or more processors, a respective communication protocol stack from a local database based on the respective identification information for each of the one or more field devices; and receiving and processing, by the one or more processors, respective data from the one or more field devices based on the respective communication protocol stack, thereby obtaining a respective processed data.
[0013] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will follow by reference to specific embodiments thereof, which are illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the disclosure and are therefore not to be considered limiting in scope. The disclosure will be described and explained with additional specificity and detail with the appended figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:
[0015] FIG. 1 illustrates a block diagram representation of network architecture or an exemplary system having a cloud-based computing system in communication with a plurality of internet of things (IoT) devices and each field device of the one or more field devices in communication with a respective IoT device of the plurality of IoT devices in accordance with an embodiment of the present disclosure;
[0016] FIG. 2 illustrates a block diagram representation of internet of things (IoT) device in accordance with another embodiment of the present disclosure;
[0017] FIG. 3 depicts a flow chart representing the steps involved in a method implemented by an internet of things (IoT) device in accordance with yet another embodiment of the present disclosure;
[0018] Further, those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.
DETAILED DESCRIPTION
[0019] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.
[0020] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or subsystems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.
[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.
[0022] In the following specification and the claims, reference will be made to a number of terms, which shall be defined to have the following meanings. The singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise.
[0023] FIG. 1 illustrates a block diagram representation of network architecture or an exemplary system 10 having a cloud-based computing system 12 in communication with a plurality of internet of things (IoT) devices 20A-20N and each field device of one or more field devices 21-26 (exemplary number of field devices are shown) in communication with a respective IoT device of the plurality of IoT devices 20A-20N in accordance with an embodiment of the present disclosure;
[0024] Each IoT device of the plurality of internet of things (IoT) devices 20A-20N may be an edge device or a gateway device. As shown therein, the cloud-based computing system 12 may include a single computer, several computer, or servers, at least some of which may be local to the field automation system 10. The cloud-based computing system 12 may include a cloud-based database 11. The cloud-based database 11 may include one or more protocol communication stacks, protocol identification rules, heuristics, or pattern-matching instructions pre-stored thereon which may be stored, fetched and executed by the cloud-based computing system 12.
[0025] In accordance with an embodiment of the present disclosure, an Internet of Things (IoT) device is provided. The IoT device comprises one or more processors and a memory having computer-readable instructions stored thereon that, when executed by the one or more processors, cause the IoT device to receive a respective identification information from one or more field devices communicatively coupled to the IoT device using a handshake process, active probing, or protocol discovery; retrieve a respective communication protocol stack from a local database based on the respective identification information for each of the one or more field devices; and receive and process respective data from the one or more field devices based on the respective communication protocol stack, thereby obtaining a respective processed data, wherein upon encountering multiple candidate communication protocol stacks based on the respective identification information, the IoT device queries a cloud-based database to retrieve communication protocol identification rules, heuristics, or pattern-matching instructions for determining the respective communication protocol stack among the multiple candidate communication protocol stacks.
[0026] FIG. 2 illustrates a block diagram representation of internet of things (IoT) device in accordance with another embodiment of the present disclosure. Referring to FIGS. 1 and 2, Each IoT device 20A-20N, 200 may include one or more processor(s) 202, a memory 204 with one or more computer-readable instructions stored thereon communicatively coupled with and operably coupled to the one or more processor(s) 202. The one or more processors 202 may be implemented as a dedicated processor(s), a shared processor, or a plurality of individual processor(s), some of which may be shared. Examples of the one or more processors 202 may include, but are not limited to, microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, Artificial Intelligence (AI) based processors, machine learning-based processors, deep learning-based processors, system-on-chip (SOC), processing circuitries including one or more modules or engines, and/or any other devices that manipulate signals and data based on computer-readable instructions, and/or any other devices.
[0027] Among other capabilities, the one or more processors 202 may fetch and execute instructions stored in the memory 204. The memory 204 may be a read-only memory (read-only memory, ROM) or another type of static storage device that can store static information and instructions, or may be a random access memory (random access memory, RAM) or another type of dynamic storage device that can store information and instructions, or may be an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a compact disc read-only memory (compact disc read-only memory, CD-ROM) or another optical disk storage, an optical disc storage (including a compact disc, a laser disc, an optical disc, a digital versatile disc, a Blu-ray disc, and the like), or a disk storage medium or another magnetic storage device, or any other medium capable of carrying or storing desired program code in a form of instructions or a data structure and capable of being accessed by a computer. This application not limited thereto.
[0028] Each IoT device of the plurality of IoT devices 20A-20N may further include a first network interface 208 and a second network interface 210. The first network interface 208 may be utilized to communicatively couple the each IoT device of the plurality of IoT devices 20A-20N with the cloud-based computing system 12. This coupling may be through a wired (e.g., Local Area Network, i.e., LAN) connection or a wireless connection (e.g., Bluetooth®, Wi-Fi). The first network interface 208 may also enable intercommunication between different logical as well as hardware components of the each IoT device of the plurality of IoT devices 20A-20N.
[0029] In some embodiments, access to cloud-based computing system 12 for pushing updates to IoT devices 20A-20N is secured using a combination of authentication, encryption, and access control mechanisms. Typically, digital signatures are employed wherein firmware or software updates are signed by a trusted authority, and the IoT device verifies these signatures prior to installation to ensure authenticity and integrity. Additionally, role-based access control (RBAC) is enforced at the cloud level to ensure that only users or systems with specific permissions, such as administrators or certified maintenance tools, are authorized to initiate updates. Communication between the cloud-based computing system 12 and the IoT devices 20A-20N is commonly encrypted using protocols such as Transport Layer Security (TLS), with some systems implementing mutual TLS (mTLS) to require both client and server authentication using digital certificates. Furthermore, token-based authentication mechanisms, such as OAuth2, may be used to restrict update privileges to authorized sessions only. Devices may also implement whitelisting or access control lists (ACLs) to allow updates only from known entities or IP ranges. In advanced systems, secure boot mechanisms and trusted execution environments (TEEs) ensure that only verified firmware runs on the device, thereby preventing unauthorized modifications even at the hardware level. These techniques collectively enhance the security of over-the-air (OTA) updates and protect IoT infrastructure from malicious or unauthorized interventions.
[0030] The second network interface 210 may be utilized to communicatively couple the each IoT device of the plurality of IoT devices 20A-20N with the one or more field devices 21-26. The one or more field devices comprise devices of a field automation system 10. This coupling may be through a variety of physical and logical interfaces depending on the communication protocols supported by the respective field devices. Such interfaces may include serial communication ports such as RS-232, RS-485, or TTL-level UART for legacy or industrial devices; Controller Area Network (CAN) interfaces for automotive and embedded applications; Ethernet interfaces supporting protocols like Modbus TCP/IP or OPC UA for high-speed industrial communication; and wireless interfaces including Wi-Fi, Bluetooth, ZigBee, LoRa, or cellular networks for remote or distributed sensors. In certain implementations, the IoT device may also support USB or SPI/I2C interfaces for close-range or embedded device integration. In some examples, the IoT device 200 may support Power over Ethernet (PoE), which enables both power and data transmission over a single ethernet connection. This capability simplifies the installation of field devices by eliminating the need for separate power sources, particularly in industrial environments with constrained wiring infrastructure. Each of these field devices 21-26 may operate using a respective communication protocol, which may be the same or different from one another. For example, field device 21 may communicate over Modbus RTU, field device 22 over CAN bus, and field device 23 using a proprietary serial protocol. This arrangement illustrates the establishment of a heterogeneous communication network at the IoT device 20A, wherein multiple field devices with varying communication standards coexist and interface with a single IoT node.
[0031] Further, the IoT device 20A-20N, 200 logically divide the IoT device 20A-20N, 200 into device identification module 206-1, protocol identification module 206-2, data processing module 206-3 and other modules 206-4. It may be noted here that modules disclosed herein may be established as executable instructions execution of which cause the one or more processors of the IoT device 200 to implement the respective functionality corresponding to the modules of the IoT device 200. The modules may be stored in a memory 204 of the IoT device 200. Further, the IoT device 200 may facilitate interactive communication between the modules 206-1 to 206-4. The other modules 206-4 may include all those modules which may be configured to implement the extended or other capabilities of the IoT device 200, for example, one such module may be a bootloader module configured to execute upon device startup. The bootloader module may be configured to be responsible for establishing initial operating conditions by setting up system memory, configuring clock sources, and initializing essential communication interfaces. By executing predefined boot code, the bootloader module ensures that the device transitions to a stable and operational state before loading the main firmware or protocol-specific packages. This modular boot process facilitates reliable startup, supports firmware verification, and may also enable secure or conditional firmware updates.
[0032] Furthermore, the IoT device 200 may include a local database 212 configured to store various types of data essential for IoT device 200 operation. The local database 212 may include one or more communication protocol stacks corresponding to the field devices communicatively coupled with the IoT device 200. These communication protocol stacks may have been initially retrieved from a cloud-based database 11 maintained by the cloud-based computing system 12. The cloud-based database stores a comprehensive library of protocol stacks, each tailored for specific types or models of field devices, and is accessible to authorized IoT devices over the first network interface 208. Upon identifying a field device during a handshake process, active probing, or protocol discovery, and based on the received identification information, the IoT device 200 may retrieve the appropriate communication protocol stack either from its local database 212 or, if not available, from the cloud-based database 11. Once retrieved from the cloud-based database 11, the communication protocol stack is stored locally in the database 212 to support efficient and repeated use without needing to re-download it.
[0033] To optimize memory usage and reduce redundancy, the IoT device may mimic the behavior of having full access to the cloud-stored communication protocol stacks while selectively storing only essential communication protocol stacks locally relevant to the connected field devices. This mimicking capability allows the IoT device to function as though the entire communication protocol stack is present locally while maintaining minimal local storage overhead, ensuring scalability and performance in constrained environments. Additionally, the local database 212 may also include raw data received from the field devices, processed or transformed data, and other operational metadata required to ensure seamless device operation in a heterogeneous communication environment.
[0034] Each communication protocol stack, as used herein, refers to a structured set of data and rules that enables an Internet of Things (IoT) device to effectively communicate with a specific type of field device. Each communication protocol stack is tailored to the requirements of a particular communication protocol and the corresponding field device specifications. Such a stack generally comprises a set of operational parameters and logic necessary for successful data exchange and interpretation. These parameters may include one or more memory locations or register addresses associated with data operations, wherein the data operation comprises read, write, or control commands, timing configurations including polling intervals, response wait-thresholds, and retry conditions, one or more communication parameters including baud rate, communication protocol type, and command templates, parsing rules defining data frame structures, including byte positions, delimiters, field types, and checksums and data transformation rules defining scaling factors, unit conversions, and value mappings to normalize raw values into a standardized format.
[0035] For example, a field device like a fuel level sensor may store the current tank level in register address 30010, and the IoT device 200 must reference this address to read the data. The stack also includes timing parameters, such as how often the IoT device 200 should request data (e.g., every 15 seconds), how long it should wait for a response (e.g., 1.5 seconds), and how many retries should be attempted if the field device does not respond (e.g., up to 2 retries). Communication parameters such as baud rate (e.g., 19200), parity bits, stop bits, and protocol type (e.g., Modbus, CANbus, or OPC UA) are defined. A command template is also part of the stack, which is a pre-defined message format that the IoT device 200 uses to request specific data. For instance, to read from register 30010 in a Modbus device, the command might be structured as: 01 03 75 32 00 01 CRC, where 01 is the device ID, 03 indicates a read command, 75 32 is the address in hexadecimal, 00 01 means to read one register, and CRC is a checksum appended at the end for error detection. Parsing rules that define how the IoT device should interpret the response are also defined. For example, the response might start with a delimiter byte like “:”, “\” or “*”, followed by a fixed number of bytes representing data, and end with a checksum byte that must match a calculated value to confirm integrity. If the response is :01030400FA CRC, the parser knows to extract 00FA as the data and validate CRC. Additionally, transformation rules are provided to convert raw numerical values into human-readable or normalized formats. For instance, a field device such as pressure sensor might return a raw value of 2500, which, when divided by a scaling factor of 100, translates to 25.00 psi. By using such a detailed and pre-configured communication protocol stack, the IoT device 200 can autonomously interpret field device-specific signals, adapt to multiple types of field devices, and operate reliably in a heterogeneous environment without requiring manual protocol configurations for each connected field device.
Processing of raw data streams from the one or more field devices 21-26 by the IoT device 200:
[0036] The IoT device 200 is configured to receive raw, uninterpreted data directly from the field devices. Rather than relying on field devices to parse or format the data prior to transmission, the actual processing and interpretation of the data occurs at the IoT device 200. This architecture enables greater flexibility and scalability in heterogeneous network environments. Particularly, to parse raw data received from a field device, the IoT device 200 utilizes a byte decoding algorithm guided by parsing rules embedded within the communication protocol stack. For example, consider a Modbus-based fuel dispenser as a field device. The IoT device receives a frame like: 0x01 0x03 0x04 0x00 0x64 0x00 0xC8 0xF1 0x2B. Here: 0x01 is the device ID, 0x03 is the function code for reading registers, 0x04 indicates the number of bytes of data to follow, 0x00 0x64 and 0x00 0xC8 represent two 16-bit values (e.g., volume and temperature), and 0xF1 0x2B is the checksum.
[0037] The byte decoding process begins with frame segmentation, where the IoT device 200 reads incoming bytes until it hits a complete frame based on the expected length or a termination byte. Next, it performs delimiter and header analysis to validate that the frame starts with the right device ID and function code. Then, in the field extraction phase, the parser identifies which bytes represent what data. For instance, it interprets 0x00 0x64 as 100 (volume in liters) and 0x00 0xC8 as 200 (temperature in tenths of a degree Celsius). The algorithm then performs bitwise operations and byte alignment to convert these hex values to integers. Once the raw fields are extracted, checksum verification is performed by recalculating the checksum (in this case, using CRC16) and comparing it with the received 0xF1 0x2B. If there's a mismatch, the packet is discarded or flagged. After successful validation, the IoT device 200 applies data transformation rules. For example, it may convert the raw temperature value 200 to 20.0°C using a scaling factor of 0.1. If configured, it can also apply unit conversion e.g., converting liters to gallons using a conversion factor.
[0038] If a frame is incomplete, the algorithm queues the data until the full frame is received, and in case the data structure deviates from the expected format, the IoT device 200 initiates an error-handling process to revalidate the protocol settings or trigger a fallback logic. This intelligent, rule-based decoding mechanism enables the IoT device 200 to adapt to a wide range of communication protocols and field device formats without manual reprogramming. By interpreting raw bytes in a structured and protocol-aware manner, the system ensures accurate, real-time data integration from heterogeneous sources, enhancing both the scalability and reliability of industrial IoT deployments.
Identification of the one or more field device 21-26 by the IoT device 200:
[0039] In operation, the device identification module 206-1 may be configured to receive a respective identification information from one or more field devices communicatively coupled to the IoT device using a handshake process, active probing, or protocol discovery. In this process, the device identification module 206-1 may be configured to establish physical and logical connectivity with one or more field devices. Physical connectivity ensures that electrical signaling is compatible, while logical connectivity enables data exchange over a defined protocol layer. Once connected, the device identification module 206-1 may be configured to engage in a device identification routine to determine the communication protocol and device type associated with each field device. The device identification process may be performed using one or more mechanisms, including: (i) handshake, where the field device transmits basic identification information over a known or default channel without requiring explicit discovery commands; (ii) active probing, where the device identification module 206-1 may be configured to transmit a set of protocol-specific discovery messages or queries to elicit a structured response from the field device; and (iii) protocol discovery based on signature pattern analysis, where the device identification module 206-1 may be configured to inspect the structure and content of initial data frames for recognizable byte sequences, headers, delimiters, or field alignment patterns that uniquely identify the communication protocol.
[0040] The identification information may include a field device identifier such as a model number, serial code, firmware version, or manufacturer ID, which may be transmitted by the field device in response to a handshake or probe message.
Identification of respective communication protocol stacks corresponding to the one or more field devices 21-26 by the IoT device 200:
[0041] Upon receiving the identification information from a respective field device, the protocol identification module 206-2 may be configured to determine the appropriate communication protocol stack required to interface with the respective field device. To this end, the identification information is compared against records stored locally in the IoT device’s local database 212. Each record in the database may map a field device identifier, or a signature pattern to a corresponding communication protocol stack. If a match is found, the protocol identification module 206-2 may be configured to immediately initiate data collection and processing using the matched communication protocol stack. In the event of match not found i.e., if the local database 212 lacks a corresponding communication protocol stack, the protocol identification module 206-2 is further configured to automatically query the cloud-based database 11 using the retrieved identification information. Once identified, the appropriate communication protocol stack is transmitted back to the IoT device 200. The protocol identification module 206-2 may be further configured to store the retrieved protocol stack in the local database 212 and initiate data collection and processing using the retrieved communication protocol stack.
Resolving conflict when multiple candidate communication protocol stacks are identified:
[0042] In instances where the identification information matches multiple candidate protocol stacks such as in the case of shared identifiers across similar device models the protocol identification module 206-2 may be configured to initiate a cloud query to retrieve additional disambiguation logic. This may include communication protocol identification rules, heuristics, or pattern-matching instructions stored in the cloud-based database to differentiate among the candidate stacks. These rules enable the IoT device to accurately identify and select the correct protocol stack to ensure reliable communication with the field device, even in ambiguous or uncertain scenarios. This hierarchical resolution mechanism improves robustness and allows dynamic adaptation to evolving device libraries and protocol updates.
[0043] For instance, protocol identification rules may include field-specific matching patterns, such as expecting a particular byte sequence at a fixed offset in the response frame e.g., the third byte consistently being 0x04 in a known Modbus implementation. Heuristics may include protocol timing behavior, such as observing whether the device responds within a fixed polling window or retries within a specific timeout duration, which can hint at whether the device follows a half-duplex RS-485-based protocol versus a full-duplex Ethernet-based protocol. Pattern-matching instructions may also involve validating specific field structures within a received frame, such as matching a known checksum formula or frame length typical of a proprietary protocol used by certain tank gauges or dispensing units. In some embodiments, the cloud-based computing system may provide prioritized disambiguation logic e.g., "if device ID is shared across protocols, prioritize the stack where polling interval aligns with 500ms," or "select the stack that expects a 16-bit CRC checksum over the one using XOR-based checksum." These rules help narrow down and confirm the most appropriate communication protocol stack when direct mapping from the identifier alone is inconclusive.
Generation of unified data representation by the IoT device 200:
[0044] Upon determining the appropriate communication protocol stack, the processing module 206-3 may be configured to receive and process respective data or raw data from the one or more field devices based on the respective communication protocol stack, thereby obtaining a respective processed data. The processing module 206-3 may be configured to process the respective processed data to generate a unified data representation, wherein the unified data representation comprises a structured format including key-value pairs, JSON objects, or any other standardized schema suitable for consistent downstream interpretation, storage, or transmission. For example, if a fuel dispenser field device transmits raw bytes representing volume and temperature readings such as 0x00 0x64 (volume = 100 liters) and 0x00 0xC8 (temperature = 200, representing 20.0°C after applying a scaling factor of 0.1) the processing module 206-3 may convert this into a JSON object:
[0045] {
“device_id”: “FD-001”,
“volume_liters”: 100,
“temperature_celsius”: 20.0,
“timestamp”: “2025-04-01T14:32: IST”
}
[0046] Such a standardized format facilitates integration with cloud platforms, dashboards, or analytics engines without requiring manual mapping for each type of field device.
Detection of anomalies locally by the IoT device 200:
[0047] Upon obtaining the respective processed data, the processing module 206-3 may be further configured to locally analyze the data to detect anomalies or violations of predefined thresholds, such as abrupt fluctuations in sensor values, out-of-range measurements, or signal loss. Based on this local analysis, the processing module 206-3 may be configured to trigger an alert or initiate a predefined response, for example, activating a local visual or audio indicator, sending a notification to a supervisory system, or executing a safety shutoff procedure even before transmitting the data to the cloud-based computing system 12 for further analysis. This local decision-making capability enables real-time responsiveness, reduces reliance on remote systems for critical operations, and supports enhanced safety and autonomy within the deployed environment.
Data transmission policy employed by the IoT device 200:
[0048] The processing module 206-3 may be further configured to transmit the respective processed data to the cloud-based computing system 12 based on a configurable data transmission policy. In one embodiment, the respective processed data may be transmitted continuously at predefined intervals to ensure real-time monitoring. In another embodiment, the transmission may be event-driven, wherein the respective processed data is transmitted only upon detection of one or more predefined conditions such as abnormal data patterns, threshold violations, or operational faults. By supporting both continuous and event-driven transmission modes, the IoT device 200 enables adaptable data communication strategies tailored to the specific requirements of different industrial environments. The event-driven model, in particular, offers advantages in bandwidth optimization, reduced cloud load, and efficient power consumption.
Cloud-enabled Visualization Interface and Protocol Stack Management Framework:
[0049] The processed data generated by the IoT device 200 may be transmitted to a cloud-based computing system 12 via IoT-optimized communication protocols such as MQTT, HTTPS, or any other supported data transmission protocols. The cloud-based computing system 12 may be configured to store the received data in a time-series database, thereby enabling long-term archival and retrieval of historical data. Furthermore, the cloud-based computing system 12 may support a user-facing interface, such as a web-based dashboard or HMI (Human-Machine Interface) 14, through which authorized users can visualize real-time metrics and historical trends. Such metrics may include, for example, cumulative flow, daily usage, operational health, or status of the connected field devices. In addition, the cloud-based computing system 12 may facilitate centralized management by pushing configuration updates, modified rules, or new communication protocol modules to the IoT device 200 in response to the addition of new field devices or protocol evolution, thereby ensuring that the IoT device remains synchronized with current operational and communication requirements in a scalable manner. In addition to the deployment of protocol-specific packages, the core firmware of the IoT device 200 may also be remotely updated via the cloud-based computing system 12. Such firmware updates may include security patches, performance enhancements, or functional improvements, thereby ensuring that the IoT device 200 remains secure, robust, and adaptable to evolving operational requirements.
Support for Offline Operation and Deferred Cloud Sync:
[0050] In some embodiments, the IoT device 200 may support offline operation to ensure data continuity in environments with intermittent or unreliable network connectivity. Specifically, when the connection to the cloud-based computing system 12 is temporarily unavailable, the processing module 206-3 may be configured to locally cache the processed data within an onboard persistent storage medium or memory 202, such as non-volatile memory. This cached data is retained until the connectivity is restored. Upon re-establishment of the network connection, the processing module 206-3 may be configured to automatically synchronize the locally stored data with the cloud-based computing system 12, thereby ensuring that no data is lost and that the historical record remains complete. This offline operation capability enhances the reliability and robustness of the system, particularly in industrial or remote field deployments where uninterrupted connectivity cannot always be guaranteed.
Management of new field devices added to the field automation system:
[0051] Upon detecting a newly connected field device and identifying the same using the mechanisms described previously (e.g., default channel communication, handshake-based recognition, or probing techniques by the device identification module 206-1), the protocol identification module 206-1 may be configured to determine whether a corresponding communication protocol stack is available in the local database 212. If the protocol stack is not found locally, the protocol identification module 206-1 may be configured to query a cloud-based database 11 using the obtained device identification information to retrieve the appropriate communication protocol stack associated with the newly added field device. Upon successful retrieval, the communication protocol stack is stored in the local database 212 for future use. By enabling automatic identification and retrieval of communication protocol stacks, the IoT device 200 significantly reduces the time and expertise required to integrate new field devices, enhances scalability, and supports plug-and-play operation across heterogeneous industrial environments.
[0052] In accordance with yet another embodiment a method is provided. The method is implemented by an Internet of Things (IoT) device and comprises receiving, by one or more processors of the IoT device, a respective identification information from one or more field devices communicatively coupled to the IoT device using a handshake process, active probing, or protocol discovery; retrieving, by the one or more processors, a respective communication protocol stack from a local database based on the respective identification information for each of the one or more field devices; and receiving and processing, by the one or more processors, respective data from the one or more field devices based on the respective communication protocol stack, thereby obtaining a respective processed data.
[0053] FIG. 3 depicts a flow chart representing the steps involved in a method implemented by an internet of things (IoT) device in accordance with yet another embodiment of the present disclosure. Although the method 300 may be implemented in a variety of devices, but for ease of explanation, the description of method 300 is provided in reference to the above-described system 200. The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method 300, or an alternative method. It may be understood that blocks of the method 300 may be performed in the IoT device 200. The blocks of the method 300 may be executed based on instructions stored in a non-transitory computer-readable medium, as will be readily understood. The non-transitory computer-readable medium may comprise, for example, digital memories, magnetic storage media, such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
[0054] At block 302, a respective identification information from one or more field devices communicatively coupled to the IoT device using a handshake process, active probing, or protocol discovery may be received.
[0055] At block 304, a respective protocol stack from a local database based on the respective identification information for each of the one or more field devices may be retrieved.
[0056] At block 306, a respective data from the one or more field devices based on the respective protocol stack, thereby obtaining a respective processed data may be received and processed.
[0057] Thus, the integration of the IoT device with heterogeneous field devices as disclosed herein achieves several technical advantages. First, it significantly reduces the need for manual configuration by enabling the IoT device to autonomously identify communication protocols and dynamically load the corresponding protocol stacks. Second, it enhances deployment efficiency by minimizing delays and reducing the requirement for skilled technical personnel during installation or maintenance. Third, it ensures greater scalability and flexibility by supporting plug-and-play connectivity with a broad range of field devices, including legacy systems with non-standard communication characteristics. Additionally, by supporting cloud-based distribution of protocol modules and firmware updates including security patches and performance enhancements the system ensures long-term maintainability and robustness. Offline operation capability further contributes to system reliability by safeguarding data continuity during network disruptions. Collectively, these improvements facilitate seamless, scalable, and future-proof integration of IoT infrastructure within complex industrial environments, such as fuel stations, manufacturing plants, and process automation systems.
[0058] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.
[0059] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person skilled in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.
[0060] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, the order of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts need to be necessarily performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples.
,CLAIMS:1. An internet of things (IoT) device (200, 20A, 20B, …, 20N) comprising:
one or more processors (202); and
a memory (212) having computer-readable instructions stored thereon that, when executed by the one or more processors (202), cause the IoT device (200, 20A, 20B, …, 20N) to:
receive a respective identification information from one or more field devices (21, 22, 23, 24, 25, 26) communicatively coupled to the IoT device (200, 20A, 20B, …, 20N) using a handshake process, active probing, or protocol discovery;
retrieve a respective communication protocol stack from a local database (212) based on the respective identification information for each of the one or more field devices (21, 22, 23, 24, 25, 26); and
receive and process respective data from the one or more field devices (21, 22, 23, 24, 25, 26) based on the respective communication protocol stack, thereby obtaining a respective processed data,
wherein upon encountering multiple candidate communication protocol stacks based on the respective identification information, query a cloud-based database (11) to retrieve communication protocol identification rules, heuristics, or pattern-matching instructions for determining the respective communication protocol stack among the multiple candidate communication protocol stacks.
2. The device as claimed in claim 1, wherein the identification information comprises a respective field device identifier or a respective communication protocol signature.
3. The device as claimed in claim 1, wherein the respective communication protocol stack comprises a set of operational parameters comprising:
one or more memory locations or register addresses associated with data operations, wherein the data operation comprises read, write, or control commands;
timing configurations including polling intervals, response wait-thresholds, and retry conditions;
one or more communication parameters including baud rate, communication protocol type, and command templates;
parsing rules defining data frame structures, including byte positions, delimiters, field types, and checksums; and
data transformation rules defining scaling factors, unit conversions, and value mappings to normalize raw values into a standardized format.
4. The device as claimed in claim 1, wherein the respective processed data is further processed to generate a unified data representation, wherein the unified data representation comprises a structured format including key-value pairs, JSON objects, or any other standardized schema suitable for consistent downstream interpretation, storage, or transmission.
5. The device as claimed in claim 1, further configured to:
detect anomalies or predefined threshold violations based on the respective processed data; and
trigger an alert or predefined response based on the detection.
6. The device as claimed in claim 1, further configured to:
transmit the respective processed data to a cloud-based computing system (12) at predefined intervals, thereby achieving real-time monitoring; or
transmit the respective processed data to a cloud-based computing system (12) upon detection of one or more predefined conditions, wherein the one or more predefined conditions comprises abnormal data patterns, threshold violations, or operational faults, thereby achieving event-driven transmission.
7. The device as claimed in claim 1, further configured to upon detecting a newly connected field device and determining that a respective communication protocol stack associated with the newly connected field device is not available in the local database (212), retrieve a communication protocol stack corresponding to the newly connected device from the cloud-based database (11) and store the retrieved communication protocol stack in the local database for subsequent use in communicating with the newly connected field device and processing data received therefrom.
8. The device as claimed in claim 1, wherein the one or more field devices (21, 22, 23, 24, 25, 26) comprise devices of a field automation system, and wherein the IoT device (200, 20A, 20B, …, 20N) is an IoT edge device or gateway device.
9. A cloud-based computing system (12) comprising:
a cloud-based database (11) adapted to store a plurality of communication protocol stacks corresponding to one or more field devices (21, 22, 23, 24, 25, 26), wherein a respective communication protocol stack from the plurality of communication protocol stacks is for execution by a respective internet of things (IoT) device (200, 20A, 20B, …, 20N) communicatively coupled via a first network interface (208) with the cloud-based computing system (12) while communicating with the one or more field devices (21, 22, 23, 24, 25, 26) for data acquisition.
10. A system (10) comprising:
one or more field devices (21, 22, 23, 24, 25, 26);
a cloud-based computing system (12),
wherein a cloud-based database (11) adapted to store a plurality of communication protocol stacks corresponding to the one or more field devices (21, 22, 23, 24, 25, 26);
a plurality of internet of things (IoT) devices (200, 20A, 20B, …, 20N), wherein the plurality of internet of things (IoT) devices (200, 20A, 20B, …, 20N) are communicatively coupled with the cloud-based computing system (12) via a first network interface (208) and communicatively coupled with respective field devices of the one or more field devices (21, 22, 23, 24, 25, 26) via a second network interface (210),
wherein each IoT device (200, 20A, 20B, …, 20N) comprises:
one or more processors (202); and
a memory (204) having computer-readable instructions stored thereon that, when executed by the one or more processors (202), cause the IoT device (200, 20A, 20B, …, 20N) to:
receive a respective identification information from the respective field devices communicatively coupled with the IoT device using a handshake process, active probing, or protocol discovery;
retrieve a respective communication protocol stack from a local database (212) based on the respective identification information for each of the respective field devices; and
receive and process respective data from the respective field devices based on the respective communication protocol stack, thereby obtaining a respective processed data,
wherein upon encountering multiple candidate communication protocol stacks based on the respective identification information, query a cloud-based database (11) to retrieve communication protocol identification rules, heuristics, or pattern-matching instructions for determining the respective communication protocol stack among the multiple candidate communication protocol stacks.
11. A method (300), implemented by an internet of things (IoT) device (200, 20A, 20B, …, 20N), comprising:
receiving (302), by one or more processors (202) of the IoT device (200, 20A, 20B, …, 20N), a respective identification information from one or more field devices (21, 22, 23, 24, 25, 26) communicatively coupled to the IoT device (200, 20A, 20B, …, 20N) using a handshake process, active probing, or protocol discovery;
retrieving (304), by the one or more processors (202), a respective communication protocol stack from a local database (212) based on the respective identification information for each of the one or more field devices (21, 22, 23, 24, 25, 26); and
receiving and processing (306), by the one or more processors (202), respective data from the one or more field devices (21, 22, 23, 24, 25, 26) based on the respective communication protocol stack, thereby obtaining a respective processed data,
wherein upon encountering multiple candidate communication protocol stacks based on the respective identification information, query a cloud-based database (11) to retrieve communication protocol identification rules, heuristics, or pattern-matching instructions for determining the respective communication protocol stack among the multiple candidate communication protocol stacks.

Dated this 15th Day of April 2025

Signature

Prakriti Bhattacharya
Patent Agent (IN/PA-5178)
Agent for applicant