Edge module and communication method

Abstract

The invention relates to an edge module and a communication method. A method includes receiving, by an edge module connected to a device, a Modbus packet from a management system. The packet includes a block write command to a command buffer and a block read command to a response buffer, wherein the buffers are associated with a contiguous register set of the edge module. The edge module interprets the request based on the command buffer data and determines an association register of the device to perform the action. The edge module generates and sends a second Modbus packet that includes a command to the determined register for the device to perform the action. The edge module writes the data into the response buffer based on the device performance for the management system to read.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 716,621, filed November 5, 2024, under 35 USC § 119, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Thermal tracking solutions utilize electrically heated elements (such as electrically heated tracking cables) to apply heat to external surfaces. Such solutions can be used to maintain the operability of critical processes, protect pipes and equipment from freezing, maintain flow in delivery lines, and provide safe and comfortable heating in buildings and homes during winter. Example thermal tracking applications may include, but are not limited to: temperature maintenance (e.g., ensuring a dedicated hot water supply to maintain fluids and liquids at desired temperature levels and / or protect critical safety lines); industrial tank insulation systems (e.g., to maintain stored liquids at a constant temperature); snow melting on industrial, commercial, and residential surfaces; de-icing of roofs and gutters; fire-resistant wiring (e.g., to protect critical circuits during fires or other emergencies); process temperature maintenance (e.g., using industrial process heating equipment to ensure fluid temperature maintenance); pipe freeze protection; marine and ocean anti-icing and de-icing; industrial, commercial, and residential flow maintenance (e.g., maintaining the temperature of fluids in pipes to ensure continuous flow); long pipeline heating; rail heating; and frost heave protection.

[0004] Referring to a specific example, piping systems are typically used to transport liquid and / or gaseous products (such as petroleum products) over long distances, such as from extraction points to processing facilities. If the extraction location and / or processing facility is located in a cold weather environment, it may be necessary to provide thermal tracing cables to maintain the piping at the desired temperature to prevent the fluid products from freezing, or, in temperature-sensitive operations, to maintain the temperature that allows the fluid products to flow effectively.

[0005] One or more electrically heated tracking cables and any associated components can be referred to as an electrically heated tracking (EHT) circuit. Furthermore, each EHT circuit is monitored and controlled by a thermal tracking controller. The thermal tracking controller can have multiple functions, and typically, some applications include multiple EHT circuits and multiple corresponding EHT controllers. These EHT controllers are typically connected to a supervisor or management system via an RS-485 serial line using the Modbus data communication protocol. Summary of the Invention

[0006] In some embodiments, a communication method for devices within a control system is provided, the control system including multiple devices communicating with a management system. The method includes: receiving a first Modbus packet from the management system via a communication line by an edge module connected to the device, the first Modbus packet being transmitted via the communication line. The first Modbus packet includes a block write command to a first contiguous register array (commonly designated as a command buffer) of the edge module, wherein the block write command corresponds to a request for the device to perform an action, and a block read command to a second contiguous register array (commonly designated as a response buffer) of the edge module. The edge module interprets the request based on data in the command buffer, including determining the registers of the device associated with the request. The edge module generates and transmits a second Modbus packet, the second Modbus packet including commands to the determined registers of the connected device for the device to perform an action. The edge module writes data into the response buffer based on the device performing the action, for reading by the management system.

[0007] In some embodiments, an edge module is provided configured to connect devices between a management system and an industrial system. In this embodiment, the edge module includes an upstream serial port, a downstream serial port, and a microcontroller including a memory storing program instructions and a processor for executing the program instructions. The processor receives a first Modbus packet comprising a multi-register write command to a first contiguous Modbus register array (designated as a command buffer), the multi-register write command being transmitted across a communication link from the management system to the upstream serial port. The processor translates the multi-register write command by mapping the Modbus registers of the device associated with the multi-register write command. The processor generates and transmits a second Modbus packet comprising a command via the downstream serial port to the mapped registers of the device.

[0008] In some embodiments, a method for an edge module to overlay a host device in an industrial control system is provided. In this embodiment, the method includes: identifying the type of the host device by probing it via a downstream port of the edge module to determine device information; mapping the resources of the host device, wherein the mapping includes determining a register address for each resource; putting the host device in a passive state by disabling an automatic control mode; and overlaying the execution control of the host device by directly accessing and manipulating its resources in response to action commands from a management system. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the detailed description, serve to explain the principles of the embodiments of the invention.

[0010] Figure 1 This is a schematic diagram of an electrothermal tracking (EHT) control system according to some embodiments.

[0011] Figure 2 This is a schematic diagram of an industrial control system according to some embodiments.

[0012] Figure 3 This is a schematic diagram of an industrial control system including an edge module according to some embodiments.

[0013] Figure 4 This is a schematic diagram of an edge module according to some embodiments.

[0014] Figure 5 According to some embodiments Figure 4 A flowchart illustrating example operations of the edge module.

[0015] Figure 6 This is a schematic representation of a Modbus register array of a device according to some embodiments.

[0016] Figure 7 This is a schematic representation of Modbus grouping according to some embodiments.

[0017] Figure 8 This is a flowchart of an example command / response communication protocol according to some embodiments.

[0018] Figure 9 This is a flowchart of an example asynchronous command / response communication protocol based on some embodiments.

[0019] Figure 10 This is a flowchart of the overlay operation process according to some embodiments.

[0020] Figure 11 This is a cross-sectional view of an edge module according to some embodiments.

[0021] Figure 12 It is an isometric view of another edge module according to some embodiments.

[0022] Figure 13 According to some embodiments Figure 12 A cross-sectional view of the edge module.

[0023] Figure 14 This is an isometric view of another edge module according to some embodiments.

[0024] Figure 15 According to some embodiments Figure 14 A section view of the edge module.

[0025] Figure 16 This is a schematic diagram of a redundant edge module configuration according to some embodiments. Detailed Implementation

[0026] Before explaining any embodiments of the invention in detail, it should be understood that the invention, in its application, is not limited to the details of the construction and the arrangement of components set forth in the following detailed description or illustrated in the following drawings. The invention can have other embodiments and can be practiced or performed in various ways. It should also be understood that the wording and terminology used herein are for descriptive purposes and should not be considered limiting.

[0027] The discussion herein is presented to enable those skilled in the art to make and use embodiments of the invention. Various modifications to the illustrated embodiments will be apparent to those skilled in the art, and the general principles herein can be applied to other embodiments and applications without departing from the embodiments of the invention. Therefore, embodiments of the invention are not intended to be limited to those shown, but should be given the broadest scope consistent with the principles and features disclosed herein. The following detailed description should be read with reference to the accompanying drawings, in which similar elements in different drawings have similar reference numerals. The drawings are not necessarily drawn to scale, but depict selected embodiments and are not intended to limit the scope of embodiments of the invention. Those skilled in the art will recognize that the examples provided herein have many useful alternatives and fall within the scope of embodiments of the invention.

[0028] A thermal tracking system may include heating elements (e.g., thermal tracking cables) to control the temperature of a surface (e.g., a pipe surface), thereby controlling the temperature or flow of the fluid transported therein. Each heating element and its associated components may be referred to as an electrothermal tracking (EHT) circuit. Furthermore, each EHT circuit may have a dedicated controller (“EHT controller”) for controlling and / or monitoring the EHT circuit. Example EHT controllers may be suitable for applications such as flow maintenance, defrosting, hot water temperature maintenance, process temperature maintenance, de-icing, anti-icing, or other applications. Typically, each EHT controller may be configured to receive and monitor data relating to, for example, surface temperature, fluid flow, fluid temperature, heating element current, and / or other relevant information associated with the EHT circuit, and control the heating element accordingly.

[0029] Users can configure the EHT controller with their desired settings, including expected alarm values, data requests, on / off temperature thresholds, etc. This data can then be communicated to the user via a monitoring system server connected to the EHT controller. However, conventional thermal tracking systems may struggle to support proper data acquisition and control because data is transmitted at relatively slow speeds due to storage and bandwidth limitations of the associated connection lines.

[0030] For example, many applications typically include multiple EHT circuits, resulting in multiple EHT controllers within such a system. Each EHT controller may have the same or different functionality, including different firmware and hardware (and different firmware versions). Furthermore, EHT controllers often connect to the management system using the slow and often unreliable Modbus communication protocol over RS-485 serial lines. It is not uncommon for hundreds of devices to share a single RS-485 line, which is often electrically excessively long. It is also not uncommon for RS-485 lines to be shared by devices from multiple vendors.

[0031] For example, Modbus communication at 9600 baud on a multi-point drop RS-485 line gives approximately 1 kilobyte per second (kbyte) of usable capacity. When, for example, one hundred devices share the channel, this results in only ten bytes per device per second after accounting for frame overhead. Further considering arbitration and collisions, soft bit errors and retries, backoff and timeouts, it's easy to understand why some lines today can take several minutes to stabilize in response to status reads.

[0032] Despite the communication speeds on these lines, there is no command queue in traditional Modbus communication. Instead, for a given bus segment, only a single register operation is in progress at any given time. In the case of a read operation, the bus is fully occupied during the outgoing read packet transmission, the turnaround time of the target device, and the incoming read response transmission. For some EHT controllers, the bridge must receive the Modbus packet, decode it, generate CAN bus traffic to access its corresponding target module to recover the requested data, organize the read response, and send it back to the management system. This can take a considerable amount of time, which is dead time for all other devices. Therefore, if only one transaction is in progress, there is no opportunity for parallel transactions across multiple target EHT controllers, which severely limits system-level throughput.

[0033] Furthermore, many current communication protocols typically assume that every participant on the bus is friendly (and capable). With the anticipated growth of multi-vendor buses, these assumptions may no longer hold true. For example, one current Modbus protocol is open plaintext, lacking native mechanisms for encryption or authentication. The corresponding application programming interface (API) is an open register array, which any agent on the bus capable of assembling valid Modbus packets can read from or write to. Therefore, in some applications, Modbus traffic in a hot-tracking system can be openly visible to everyone, so any entity on a shared wire connection can arbitrarily manipulate any other entity.

[0034] Additionally, each EHT controller can be represented by hundreds or thousands of low-level registers (with 16-bit integers). These registers can be written to and read from when the controller configuration changes, to extract sensor and performance data. The corresponding management system must map these registers for each individual EHT controller, as these registers vary based on the controller type (e.g., based on vendor, model, firmware version number, and / or the currently relevant internal controller state). In other words, a management system that interacts with many different kinds of devices must combine code to handle each specific device. Effectively, the low-level driver logic for each device is not in the device itself; rather, the management system is obligated to mobilize a set of business logic for all the aforementioned permutations. This not only forces a significant amount of complexity into the management system but also creates a huge maintenance burden—the management system must be updated accordingly every time device behavior changes with a new firmware drop.

[0035] Therefore, this arrangement is prone to errors and can produce invalid configuration states, leading to potential false alarms or unwanted thermal regulation behavior in some EHT circuits. The configuration verification process can be performed by the management system by reading back all registers and performing a consistency check on its remote server; however, such verification may be bandwidth-limited.

[0036] Therefore, implementing configuration changes can involve numerous Modbus register changes, creating significant traffic on the line and exacerbating the aforementioned overload issues. Additionally, operationally, many devices may need to adjust in response to events such as emergency shutdowns, load balancing, or process changes across multiple circuits simultaneously. Network traffic is highly volatile, but it is precisely during such peak activity periods that smooth traffic flow is paramount. As another example, when writes are performed for configuration updates, the system may be in an internally inconsistent state. If a major outage occurs during this reconfiguration, misconfiguration may result.

[0037] Given the above, the current Modbus protocol may lack error control, authentication, and encryption, and its use of register mapping at a low level leads to an excessive burden on the management system. With the increasing demand for thermal tracking systems (and in industrial systems in general), including the expectation of increased data compilation for analysis, it would be beneficial to provide a way to enable secure, efficient, and reliable access to EHT controllers while coexisting with standard Modbus traffic. Embodiments of the disclosed invention provide such a solution to address these and other problems.

[0038] More specifically, some embodiments provide such a solution by replacing low-level register accesses with high-level commands that communicate in adjacent Modbus register arrays (collectively regarded as communication buffers). These strings are processed into Modbus packets to improve performance on noisy lines, significantly reduce line traffic, and introduce security through encryption and authentication protocols. These systems and methods are designed to address the aforementioned problems while maintaining interoperability with all existing devices on a shared Modbus link. While embodiments are described herein with respect to thermal tracking systems and, in particular, devices such as EHT controllers, it should be noted that the current systems and methods of some embodiments can be applied to any device controlled across a Modbus link in any type of control system, including, for example, industrial control and automation systems.

[0039] therefore, Figure 1 An example electrothermal tracking (EHT) control system 10 according to some embodiments of the present invention is shown. The EHT control system 10 can be used to heat a surface 12 and monitor the surface 12 and / or its surrounding environment. Therefore, the EHT control system 10 may include one or more thermal tracking cables 14, one or more sensors 16, and an EHT controller 18. Furthermore, the EHT controller 18 may communicate with the management system 20 via a wired connection 22 (such as an RS-485 serial connection or an Ethernet connection) and / or a wireless point-to-point or mesh connection 23 (e.g., Wi-Fi, Wi-SUN, Zigbee, Bluetooth®, etc.). The management system 20 may also be further connected to one or more remote devices 24 (e.g., a remote user interface).

[0040] about Figure 1Surface 12 in the system, the EHT control system 10 can be used to heat any type of surface in industrial, commercial, or residential applications via thermal tracking cable 14. Examples of surfaces in industrial applications may include, but are not limited to: piping requiring freeze protection, such as water supply and drainage lines, safety showers and eyewash stations, fire and sprinkler systems, and sewage and sanitation systems; piping requiring process temperature maintenance, such as in the oil and gas, petrochemical, power, pharmaceutical, paper, and food and beverage industries; piping requiring freeze protection, viscosity control, and / or temperature maintenance, such as for the transport of heavy oil or sulfur between processing plants, storage tanks, and transportation facilities; foundations or concrete slabs requiring protection against frost heave, such as those surfaces in liquefied natural gas (LNG) terminals and surfaces on refrigerated and cryogenic storage tanks; storage tanks requiring heating, such as those storing sensitive industrial liquids to prevent freezing or solidification and to facilitate smooth loading and unloading processes; and / or surfaces in marine environments, such as heated walkways and stairs, communication equipment; helicopter decks and lifeboats, etc. Example surfaces in commercial and residential applications may include, but are not limited to: pipes requiring frost protection, such as water supply and drainage lines, safety showers and eyewash stations, fire and sprinkler systems; sewage and sanitation systems; heated floors and / or stairs; roofs and gutters requiring de-icing; and / or outdoor driveways, sidewalks, terraces, emergency exits, etc., where snow melting is required.

[0041] Still referencing Figure 1 In some embodiments, the heat tracking cable 14 can be any type of heating cable used for heating the surface 12. Examples of heat tracking cables 14 include, but are not limited to, self-regulating heating cables, constant wattage heating cables, mineral-insulated heating cables, polymer-insulated heating cables, skin effect heating cables, power-limiting heating cables, etc. Referring to pipe heating applications, the heat tracking cable 14 can be adapted to heat the pipe surface 12 to heat the fluid within the pipe. Referring to skin effect heating cable systems, the heat tracking cable 14 can be routed through an additional heating tube (not shown) to heat the surface 12. Additionally, in some applications, the heat tracking cable 14 can include multiple heat tracking cables 14 that can be coupled together in series or parallel, such that the heat tracking cables 14 can be synchronously energized or de-energized. For example, the heat tracking cable 14 can be coupled to a power source (not shown), and the power from the power source to the heat tracking cable 14 can be controlled via an EHT controller 18. In addition, in some applications, system 10 can combine additional components with thermal tracking cable 14 to enable the length of EHT circuits, such as, but not limited to, transformers, power connection boxes, pull boxes, junction boxes and / or end termination boxes.

[0042] Continue to refer to Figure 1In some applications, the EHT control system 10 may utilize one or more sensors 16 to monitor the state of the system 10. For example, the system 10 may include one or more sensors 16 configured to sense variables such as surface temperature, fluid temperature, ambient temperature, flow through pipes (in pipe heating applications), and current to the heating tracking cable 14. The sensors 16 may be wirelessly connected (e.g., using Wi-Fi, Zigbee, Bluetooth, etc.) to the EHT controller 18, or coupled to the EHT controller 18 using a wired connection (e.g., a three-wire connection or other connection). In some embodiments, the network of wireless sensors 16 may communicate with the EHT controller 18 using a mesh communication protocol.

[0043] Based on an example, such as Figure 1 As illustrated, sensor 16 can be placed outside surface 12 to sense surface temperature, and another sensor 16 can be separated from surface 12 (e.g., positioned in a region close to surface 12) to sense ambient air temperature. Such sensors 16 can include resistance thermometers, resistance temperature detectors (RTDs), or other suitable sensors capable of detecting temperature. In pipe heating applications, fluid temperature and flow may vary along the length of the pipe or between different pipe sections. In this case, multiple sensors 16 can be used to monitor multiple temperatures along the pipe system, within the pipe system, or near the pipe system at different locations. Alternatively, in this case, sensors 16 can include a distributed temperature sensing (DTS) system. For example, a DTS system could be a fiber optic-based system capable of generating spatiotemporal temperature data along the length of surface 12.

[0044] In another example, such as in a pipe heating application, sensor 16 can be configured to measure the flow of fluid within a pipe in a piping system. For example, sensor 16 configured to monitor the flow of fluid within a pipe can be used to alert a user to low flow (e.g., flow stoppage) within the pipe. Such sensor 16 can be a flow meter or other suitable device capable of measuring one or more parameters related to fluid flow, such as changes in flow rate or fluid temperature over time. In yet another example, system 10 may also include sensor 16 configured to measure other relevant state values, such as ground fault current. Any of these sensors 16 can be communicatively coupled to EHT controller 18 to provide data to EHT controller 18 for monitoring and EHT system management.

[0045] Return to reference Figure 1The EHT controller 18 may include a memory 26 configured to store data and EHT monitoring, control, and / or communication protocol programs, and a processor 28 configured to execute such programs. For example, in some embodiments, the EHT controller 18 may be a programmable logic controller (PLC). In some embodiments, the memory 26 may be a non-transitory machine-readable medium, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, storage drive, optical disk, or the like. In some embodiments, the EHT controller 18 may also include a user interface (not shown) and one or more ports 30 (such as a serial communication port, Ethernet port, or other ports) for, for example, connection to a management system 20.

[0046] Typically, the EHT controller 18 may include core independent functions: monitoring variables such as temperature and current, controlling the EHT circuitry, and generating alarms to alert the user to alarm conditions. Therefore, the EHT controller 18 (e.g., a corresponding processor 28 executing the supervisory program) can be configured to receive outputs from one or more sensors 16 and can determine, based on the outputs from the sensors 16, to perform one or more actions, such as energizing the heating tracking cable 14, de-energizing the heating tracking cable 14, or alerting the user to a current or potential fault in the system 10. These alerts can be communicated to the user via the management system 20, as described below.

[0047] More specifically, view Figure 1 For example, the EHT controller 18 can be coupled to the sensor 16 to receive state values ​​(e.g., temperature values, flow state values, or other relevant values) related to temperature, fluid flow, or other relevant variables. The EHT controller 18 can be configured to store the state values ​​from the sensor 16 in memory 26 and communicate the state values ​​to the management system 20.

[0048] Furthermore, the EHT controller 18 can be configured to selectively energize and de-energize the heating tracking cable 14 based on status values. For example, the EHT controller 18 can compare the status values ​​with multiple thresholds used for heating tracking cable management and alarm management. Additionally, the EHT controller 18 can be configured to alert the user to faults in the EHT control system 10. For example, the EHT controller 18 can issue an alarm when certain alarm conditions are present, such as, but not limited to, when the sensed surface 12 temperature becomes too low, the fluid flow in the pipe becomes too slow or stops, or when the ground fault current along the EHT circuit becomes too high. In this case, the EHT controller 18 can issue an alarm, communicate an alarm flag to the management system 20, and / or cut off power to the heating tracking cable 14.

[0049] Return to reference Figure 1 The management system 20 may include one or more ports 32, such as serial communication ports or Ethernet ports, to enable the management system 20 to be coupled to devices, such as EHT controllers 18 or other devices, via wired (e.g., RS-485 or Ethernet) connections 22 and / or wireless connections 23. It should be noted that although the following discussion will generally refer to connection 22 as an RS-485 line, any embodiments described herein are equally applicable to Ethernet connections (each Ethernet connection typically carries Modbus protocol frames) or wireless communication protocols carrying Modbus protocol frames. Therefore, the management system 20 may be coupled along RS-485 line 22 to multiple EHT controllers 18 to receive status values, alarms, etc., in a centralized location for user monitoring and / or control of the system 10. For example, while the EHT controllers 18 may be located "in the field," typically close to the surface 12 to be heated, the management system 20 may be a centralized supervisory program system located in a control facility located away from the surface 12. As another example, Figure 2 The illustration shows an example system 10 including a management system 20 connected along an RS-485 connection 22 to multiple EHT controllers 18 and / or other devices 19 (e.g., other sensors, PLCs, programmable automation controllers (PACs), and / or actuators). For example, system 10 may include a typical point-to-point or multi-point descent (daisy-chain) network topology typical of a Modbus RTU environment.

[0050] In some embodiments, such as Figure 1 As shown, the management system 20 may be a supervising computing device, including a memory 36 (a non-transitory machine-readable medium storing data and / or instructions), a processor 34 executing instructions, and a user interface 38 for displaying information to the user and / or receiving input from the user. The management system 20 may also communicate with a remote device 24, which may also include a user interface, allowing the user to remotely view information and / or provide input to the management system 20. For example, the remote device 24 may include, but is not limited to, mobile devices, tablets, remote personal computers, etc. For example, the management system 20 may communicate with the remote device 24 via a wired connection or wirelessly (e.g., via a network 25). Therefore, information displayed to the user may be displayed at the management system 20 or at the remote device 24 communicating with the management system 20, and control input provided to the management system 20 may be provided directly at the management system 20 (e.g., via user input to a user interface 38 such as a keyboard) or via the remote device 24 communicating with the management system 20. Therefore, the user interface of system 10 can be considered either the user interface 38 of the management system 20 or the user interface of the remote device 24.

[0051] Typically, the management system 20 may include instructions stored in memory 36 and executed by processor 34 to perform certain functions. For example, such instructions may include an application programming interface (API) for communicating with the EHT controller 18. For instance, the API may include instructions for writing desired configurations to the EHT controller 18, such as providing thresholds for alarm levels, providing thresholds for heated cable tracking functionality, etc., as provided by a user through user interface 38. It should be noted that throughout this disclosure, references to the management system 20 performing certain actions can be equivalent to the processor 34 of the management system 20 executing program instructions stored in memory 36, such as executing the API or other programs. Furthermore, the management system 20 may also request data from the EHT controller 18 via the API, and the EHT controller 18 (executing instructions stored in memory 26 via its processor 28) may communicate data to the management system 20 in response to the data request. The management system 20 may check alarm flags, request alarm data, and clear alarm flags, and the EHT controller 18 may return alarm flags and alarm data to the management system 20 accordingly. In this example, "alarm data" may be a status value and / or other data after an alarm is triggered.

[0052] Therefore, the management system 20 acts as a central parent device (e.g., a master or initiator) that periodically queries information from the child EHT controllers 18 (e.g., slaves or responders). Such communication is typically accomplished via the Modbus protocol over an RS-485 connection 22 (or other wired or wireless connection). As discussed above, conventionally, the management system 20 maps all the low-level registers of a particular EHT controller 18 to enable proper communication with it. That is, communication with a particular EHT controller 18 requires the management system 20 to provide read or write instructions with specific data to a particular register in order to execute the request. Each register has a fixed assigned function, conventionally listed in the Modbus register mapping of device 18.

[0053] Instead of hundreds of low-level register operation sequences (e.g., traditional register mapping methods) each time EHT controller 18 is managed, some embodiments provide a command / response protocol that utilizes Modbus register mapping in a completely different way (e.g., a command / response method). That is, instead of writing to specific registers for EHT controller 18 based on how EHT controller 18 should perform something, management system 20 can write general high-level commands based on what it needs EHT controller 18 to do. This minimizes or completely eliminates the need for management system 20 to have and maintain register mappings for each EHT controller 18 (e.g., based on type, vendor, firmware version, etc.) for management system 20 to communicate with EHT controller 18. In other words, according to some embodiments, device-specific (e.g., controller) details do not permeate outside the data model (driver) layer. Although the physical layer (e.g., RS-485 at 9600 baud rate) is slow and unreliable, management system 20 can still communicate with any EHT controller 18 in a secure, efficient, and robust manner while remaining compatible with standard Modbus traffic.

[0054] Therefore, some embodiments provide a command / response communication protocol between devices via RS-485 line 22. Such a protocol can be enabled via APIs stored in the management system 20 and the corresponding devices 18, 19. For example, Modbus communication over the RS-485 line supports multiple register reads and writes within a single Modbus transaction, thus providing an efficient way to move bytes across line 22, as many bytes can be moved with only a single packet overhead. According to the command / response protocol of some embodiments, block reads and writes can operate on a vector of consecutive Modbus registers. More specifically, an array of consecutive registers in EHT controller 18 (or other device 19) can be used as a command input buffer, through which commands are communicated via a multiple register write function, and a second array of consecutive registers in EHT controller 18 (or other device 19) can be used as a response buffer, through which responses are communicated via a multiple register read function, as described below. Figure 6 and Figure 7 Further description.

[0055] While the new EHT controllers 18, 19 can be designed to support command / response control schemes from the outset, there is already a large existing base of older equipment based on register-mapped control schemes. Therefore, in cases where the EHT controller 18 lacks the capability for such a command / response protocol (e.g., older "legacy" equipment, third-party equipment, etc.), some embodiments provide an edge module (also considered an edge security module ("ESM") or command response module ("CRM")) that can act as a dedicated bidirectional converter along RS-485 line 22 between upstream command / response Modbus communication from management system 20 and downstream conventional Modbus register communication to EHT controller 18 or other devices 19.

[0056] For example, Figure 3 Another example system 10 is illustrated, which includes multiple EHT controllers 18 and / or other devices 19 communicating with a management system 20 via a shared connection 22. The management system 20 is configured to communicate via a command / response Modbus protocol, as further described below. The EHT controllers 18 include a first EHT controller 18A, which is an older "legacy" controller configured to communicate via a traditional Modbus register communication protocol; a second EHT controller 18B, which is a third-party controller configured to communicate via a traditional Modbus register communication protocol; and a third EHT controller 18C, which is configured to communicate via a command / response Modbus protocol. Furthermore, the other devices 19 include a first device 19A configured to communicate via a traditional Modbus register communication protocol and a second device 19B configured to communicate via a command / response Modbus protocol. Being configured to communicate via a command / response Modbus protocol means that devices 18 and 19 enable this protocol, for example, via APIs stored in the respective memories of devices 18 and 19. Devices 18A, 18B, and 19A configured for conventional Modbus register communication may lack the capability or capacity to enable communication via the command / response Modbus protocol. Additionally, system 10 may include one or more edge modules 300 (“Edge Security Modules,” “ESM,” or “Command Processor Modules,” “CRM”), where each edge module 300 may connect between management system 20 and the corresponding devices 18, 19, or may act as a standalone “device” (e.g., independently or integrated with another device operating within system 10 but not previously connected to or controlled by management system 20, as described below regarding…). Figures 11-15 (More detailed description).

[0057] More specifically, such as Figure 3 As shown, each device 18C, 19B, configured to communicate via the command / response Modbus protocol, is directly connected to the management system 20 along RS-485 line 22. The management system 20 can write general high-level commands based on what it needs specific devices 18C, 19B to do. The corresponding devices 18C, 19B can interpret the high-level commands from the management system 20 and execute the desired commands. On the other hand, each device 18A, 18B, 19A, configured to communicate via conventional Modbus register communication, is indirectly connected to the management system 20 via a corresponding edge module 300 along RS-485 line 22. The management system 20 can write general high-level commands based on what it needs specific devices 18A, 18B, 19A to do. The corresponding edge module 300 can maintain register mappings (e.g., based on type, vendor, firmware version, etc.) for the devices 18 and 19 connected to it. It can interpret high-level commands from the management system 20 and output traditional Modbus packets to the devices 18 and 19 based on the stored register mappings, enabling the devices 18 and 19 to execute the desired commands. Therefore, compared to a traditional gateway, the function code and data payload of the incoming Modbus packets from the management system 20 are different from those generated for the outgoing Modbus packets destined for the devices 18 and 19, because the command / response Modbus protocol is only for a dedicated command and response buffer register array. Thus, the edge module 300 enables the management system 20 to discover and interoperate with all devices 18 and 19 (legacy, contemporary, and yet-to-be-designed) via a single, unified API by allowing all devices 18 and 19 (legacy, contemporary, and yet-to-be-designed) to use the command / response protocol.

[0058] therefore, Figure 4 An example schematic layout of an edge module 300 according to some embodiments is shown. Typically, the edge module 300 can be a small, low-cost microcontroller system with onboard memory and sufficient processing power to present command / response targets to the management system 20 on its upstream RS-485 port (or other wired or wireless connectivity interface) and generate traditional Modbus register read / write traffic on its downstream RS-485 port (or other wired or wireless connectivity interface). More specifically, as Figure 4 As shown, the edge module 300 may include a housing 402 having an upstream port 404, a downstream port 406, and a power port 408. Internally, the edge module 300 may include a microcontroller 410, a power regulator 412, and a memory 414. Additionally, optionally, in some embodiments, the edge module 300 may include a wireless module, such as a field area network (FAN) module 416 and / or a Bluetooth or Wi-Fi module 418.

[0059] Still referencing Figure 4 In some embodiments, housing 402 may employ a variety of packaging options suitable for accommodating the mounting requirements of specific devices 18, 19 with minimal footprint. According to one example, housing 402 may simply comprise a printed circuit board assembly (PCBA) that is shrink-packed or dipped, with protruding wire terminals serving as ports 404, 406, 408. As a result, in some embodiments, the entire edge module 300 can be physically small, for example, approximately 2.5 cm by 5 cm. Alternatively, for certain device types, the PCBA may not be wrapped or dipped, but instead wired into the wiring cavities of devices 18, 19. According to another example, housing 402 may have a thin DIN rail form factor that integrates the wire terminals for ports 404, 406, 408. For example, housing 402 may have the size and form factor of a standard miniature relay. In other examples, housing 402 may fully encapsulate the PCBA and be configured to be mounted to or adjacent to devices 18, 19. In some embodiments, the edge module 300 may include the same PCBA packaged in different form factors to better accommodate various specific devices 18, 19. Further details are provided below. Figures 11-15 Further example shape factors are described in detail.

[0060] Typically, regardless of the enclosure design, the edge module 300 can be physically mounted adjacent to or on its respective devices 18, 19, enabling the downstream RS-485 link 22A (from the downstream port 406) to be connected. Figure 3 The edge module 300 (shown in the diagram) can be very short (e.g., in the range of a few centimeters to a few inches) and electrically pristine with proper structured termination. Therefore, the edge module 300 can drive a large volume of traffic on downstream link 22A without being contested by any other device in system 10, as it has a short, dedicated point-to-point connection with its connected devices 18, 19. Additionally, in some embodiments, the housing 402 can be fully potted to allow the edge module 300 to match the hazardous location rating, tamper resistance, and robustness of its target devices 18, 19. Furthermore, the low power consumption of the edge module 300 makes it highly feasible to have intrinsic security levels.

[0061] Therefore, it is still recommended to refer to Figure 4Edge module 300 may include an upstream port 404, a downstream port 406, and a power port 408. Upstream port 404 may be a serial port configured to interface with, for example, RS-485 line 22 for communication with management system 20. Downstream port 406 may also be a serial port configured to interface with a dedicated RS-485 line 22A for communication with corresponding devices 18, 19. For example, as further described below, edge module 300 may communicate with management system 20 via upstream port 404 via the command / response Modbus protocol, and may read from and write to Modbus registers of connected devices 18, 19 via downstream port 406. In some embodiments, upstream and downstream ports 404, 406 are RS-485 ports configured to operate at a baud rate of 9600.

[0062] Although edge module 300 includes wired connection ports 404, 406, in some embodiments, edge module 300 can also be configured for wireless communication, and thus allow communication via the wireless Modbus protocol. For example, edge module 300 may include optional wireless modules such as FAN module 416 and / or Bluetooth / Wi-Fi module 418. Therefore, in some embodiments, edge module 300, and more specifically microcontroller 410, may be configured to wirelessly communicate with management system 20, other edge modules 300, other devices 18, 19, and / or remote device 24 via FAN module 416 and / or Bluetooth / Wi-Fi module 418. Thus, edge module 300 can provide legacy devices or third-party devices 18, 19 that do not have wireless capabilities with the ability to participate in robust mesh or peer-to-peer networks.

[0063] For example, in some embodiments, the microcontroller 410 may include integrated Bluetooth and Wi-Fi radios. Furthermore, in some embodiments, the wireless antenna supporting the Bluetooth / Wi-Fi module 418 may be printed directly onto the PCBA of the edge module 300. As a result, the edge module 300 can communicate with the management system 20 via the Bluetooth / Wi-Fi module 418 (e.g., using a mesh network or point-to-point link). Therefore, the Bluetooth / Wi-Fi module 418 can provide a secondary communication option as an alternative to the wired bus 22, allowing system operation to continue even if the bus 22 is disconnected. Additionally, in some embodiments, a local administrator in the field may be able to connect to and communicate with a specific edge module 300 via Bluetooth connection through, for example, a remote device 24 (such as a mobile phone or tablet).

[0064] According to another example, in some embodiments, FAN module 416 can enable long-range mesh networking across system 10 via a Wireless Smart Utility Network (Wi-SUN). In such embodiments, management system 20 may also include a corresponding FAN module (e.g., a Wi-SUN module) designed to act as a Wi-SUN router, bridging the mesh network to a wired network. Therefore, edge module 300, including FAN module 416, can bring remote, previously unconnected devices 18, 19 into communication with management system 20. Furthermore, in some applications, edge module 300 may utilize FAN module 416 instead of upstream port 404. For example, instead of an integrated FAN module 416, in some embodiments, a separate FAN module 416 may interface with upstream port 404. Using this configuration, edge module 300 can provide legacy or third-party devices 18, 19 with the ability to participate in a robust mesh network, aggregating devices 18, 19 in system 10 where no hardwired infrastructure is available.

[0065] Still referencing Figure 4 Edge module 300 may include a power port 408. Power port 408 may be configured to receive power from, for example, an alternating current (AC) or direct current (DC) power source (not shown) to power edge module 300. In some embodiments, edge module 300 may have relatively low power requirements. In one example, edge module 300 has a rated power of less than 2 watts. In another example, edge module 300 has a rated power of approximately 2-3 watts.

[0066] Power from an external power source can be routed to the microcontroller 410 via power conditioner 412. For example, in some embodiments, depending on the intended power supply, power conditioner 412 may be an AC / DC power conditioner or a DC / DC power conditioner. In some embodiments, microcontroller 410 may include memory (e.g., computer-readable storage media, including random access memory (RAM)), configured to store, for example, program instructions (such as one or more APIs), and one or more processors configured to execute the program instructions. Edge module 300 also includes memory 414, such as flash memory (e.g., non-volatile computer storage media), communicating with microcontroller 410. In some embodiments, memory 414 may be used for data storage, such as for data recording, as further described below. Although memory 414 (and the memory of microcontroller 410) is described above as optionally having a particular non-transitory machine-readable medium, in some embodiments it may additionally or alternatively include other forms of non-transitory machine-readable media, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, storage drive, optical disk, etc.

[0067] As noted above, microcontroller 410 may include memory for storing program instructions (such as one or more APIs) and one or more processors configured to execute the program instructions. It should be noted that any description herein of edge module 300 performing certain actions is equivalent to the microcontroller 410 of edge module 300 performing these actions (e.g., via the processor of microcontroller 410). In some embodiments, microcontroller 410 may execute program instructions to operate in a “translation mode”, thereby providing bidirectional interpretation between the Modbus register mapping control scheme of downstream devices 18, 19 and the command / response Modbus protocol of upstream management system 20. To do this, microcontroller 410 may store the Modbus register mapping of connected devices 18 in its memory or flash memory 414 and then translate incoming general commands from management system 20 into appropriate configuration settings for its connected devices 18, 19 (e.g., conventional Modbus register read / write sequences) while allowing devices 18, 19 to maintain their autonomous operational control. In some embodiments, microcontroller 410 may also execute program instructions to operate in an “overlay mode”. In overlay mode, the microcontroller 410, while making the devices passive, takes over the execution control of the connected devices 18 and 19 by directly accessing and controlling their low-level functions.

[0068] Figure 5 The illustration shows an example setup and operation process 500 of an edge module 300 according to some embodiments. For example... Figure 5 As shown, at step 502, upon first power-on after the edge module 300 has been installed within the system 10, the edge module 300 can detect the devices 18, 19 connected to it on downstream port 406 to determine device information such as vendor, model, and firmware version. At step 504, when the management system 20 first detects the edge module 300 (e.g., during a routine scan of devices along connection line 22), the edge module 300 can identify itself and request the download of an appropriate firmware module to allow it to correctly translate for the accompanying devices 18, 19 to which it is hardwired. For example, the firmware module may include a specific Modbus register mapping for the vendor, module, and firmware version of the connected devices 18, 19. In this way, the edge module 300 can be considered self-configuring.

[0069] Still referencing Figure 5At step 506, after downloading the firmware module, the module is activated, and the edge module 300 can begin mapping incoming commands from the management system 20 to Modbus register read / write sequences for companion devices 18 and 19. That is, the edge module 300 can initiate continuous bidirectional conversions between the management system 20 and the devices 18 and 19 to which it is connected. By doing so, the edge module 300 presents standardized controller capabilities to the management system 20, which no longer needs to precisely understand which underlying devices are actually performing EHT control, sensor readings, RTD mapping, digital I / O capabilities, etc. Given this process 500, because companion device-specific firmware modules are downloaded after attaching and identifying companion devices 18 and 19, only a single SKU and firmware pre-load will be required for all edge module variants, making the edge module 300 a plug-and-play type device.

[0070] Alternatively, in some embodiments, edge module 300 may include a pre-downloaded firmware module prior to connection to specific devices 18, 19, or may communicate with a separate remote device 24 during installation (e.g., via Bluetooth or other wireless connection to a remote device 24 in the field) to receive the firmware download. Upon initial power-on, edge module 300 may probe the devices 18, 19 connected to its downstream port 406 to confirm that the pre-downloaded firmware module matches the device information. If so, edge module 300 may immediately begin mapping between incoming commands from management system 20 and Modbus register read / write sequences for accompanying devices 18, 19. If not, edge module 300 may perform... Figure 5 The entire process is 500.

[0071] In view of the above, based on Figure 3In the system 10 illustrated in the diagram, the management system 20 can issue unified commands to all devices 18, 19, and 300 on RS-485 line 22 via a command-response protocol. These commands can be directly directed and interpreted by some devices 18C and 19B, or indirectly directed and interpreted by other devices 19A, 19B, and 18C via edge module 300. Therefore, as noted above, under the command / response protocol, each individual device 18C, 19B, and device combinations 300 / 19A, 300 / 19B, and 300 / 18C are treated as standardized, generic devices by the management system 20. In other words, using this protocol, the thermal tracking channel can be completely abstracted, allowing a highly heterogeneous set of controllers (potentially spanning a mix of various vendors) to be forced into a regularized resource pool from which the management system 20 can freely assemble and aggregate complex virtual controller systems. The management system 20 can treat all devices 18, 19, and 300 as qualitatively identical, differing only quantitatively in the number of EHT circuits, sensors, relays, etc. On the other hand, no additional requirements are imposed on legacy controllers and third-party controllers 18, 19—no firmware updates are needed to interact with edge module 300, and the low-level register commands from edge module 300 are no different from the instructions these devices 18, 19 previously received from management system 20. This is a highly efficient way to leverage existing site equipment while gracefully integrating new controllers in a unified manner.

[0072] The command / response protocol will now be described in more detail, with particular reference to the communication between the management system 20 and the edge module 300 according to some embodiments, although such communication may also occur between the management system 20 and other devices 18C, 19B.

[0073] For example, Figure 6 The illustration shows an array of registers 600 (i.e., the Modbus address space) in a device such as edge module 300. According to some embodiments, a first region in the Modbus address space of edge module 300 may be reserved for use as a command buffer 602, similar to a command-line interface in a computer shell. Command buffer 602 may include a fixed maximum buffer length. In some implementations, the maximum buffer length may be 2700 bytes (e.g., a Modbus limit for multiple write operations), although smaller or larger maximum buffer lengths may be used in other implementations.

[0074] Still referencing Figure 6 Another portion of Modbus space 600 can be reserved for the corresponding response buffer 604. Both buffer regions 602 and 604 can reside at fixed addresses across all devices 18, 19, and 300. Figure 6In the example shown, command buffer 602 includes registers 1-15, and response buffer 604 includes registers 16-31. However, in some implementations, the register addresses can be selected to avoid conflicting with existing active register addresses on any device type (e.g., possibly in a high address region, as they may need to coexist during the transition from a register-mapped approach to a command / response approach). In some implementations, command buffer 602 and response buffer 604 may also each contain more than 16 registers. Therefore, this data structure allows management system 20 to interact with devices 18, 19, and 300 in entirely different ways without disrupting interoperability with other devices communicating via the traditional Modbus protocol on the same line 22.

[0075] As noted above, it is not about how the communication EHT controller 18 or other devices 19 should act (e.g., by writing to individual registers), but rather that the management system 20 can write general high-level commands based on what it needs the EHT controller 18 to do. Therefore, such commands can replace many Modbus register-level operations. As an example, such a command could be:

[0076] > MODE MAINTAIN SETPOINT=50C DEADBAND=2C

[0077] It is worth noting that the command above involves multiple variables. In a traditional register mapping approach, the management system 20 would need to determine which registers (multiple of them) of a specific EHT controller 18 are suitable for implementing the command, create Modbus packets that include write functionality to these registers, and send the Modbus packets on wire 22. However, the command above, at such a high level of abstraction, can replace these Modbus register-level operations, and then the edge module 300 assumes the responsibility of mapping the high-level command to create Modbus packets that include write functionality to specific registers and sending them to the connected devices 18, 19 via a dedicated short link 22A. Therefore, the edge module 300 does not merely relay low-level register reads and writes between the management system 20 and devices 18, 19, but rather abstracts the interface between devices 18, 19 and the management system 20 by translating between high-level Modbus commands and low-level Modbus register instructions.

[0078] Additionally, such high-level commands from the management system 20 would be easily interpretable by humans, both because of their high level and because it would eliminate the need to constantly refer to Modbus mappings of different devices to infer intent and consequences. Furthermore, due to the high level of abstraction, text files can be used to write complex operations, thereby contributing to enhanced automation capabilities.

[0079] Compared to register mapping methods, these high-level commands can significantly reduce traffic along line 22. For example, the same command can work across all EHT controllers 18, including those capable of using command / response protocols and those connected via edge module 300. In effect, multiple devices 18, 19, 300 (and multiple EHT channels within each device) can be addressed by a single command using lists or bitmasks (e.g., the same command applied to multiple channels as indicated in a mask subset or list), resulting in potential orders-of-magnitude savings in line traffic. Furthermore, management system 20 no longer needs to track which firmware version is running on which devices 18, 19, greatly simplifying management system code, and further, firmware updates for EHT controller 18 will generally not require updates to management system 20. Instead, such updates only need to be maintained and monitored by edge module 300.

[0080] Additionally, command operations can be executed atomically from the perspectives of both the edge module 300 and the management system. More specifically, as an example, the edge module 300 can receive a single command that combines changes to multiple registers of the EHT controller 18, as discussed above, and can interpret and communicate with the EHT controller 18 to execute all necessary functions within the command locally. A response is only provided back to the management system 20 when the complete command has been executed. This contrasts with register-by-register execution from conventional Modbus packets.

[0081] Therefore, the management system 20 can generate commands in the command buffer 602 (e.g., multi-register write functionality to the registers of the command buffer 602) and transmit the commands on the RS-485 line 22 (or via the wireless Modbus protocol). The receiving edge module 300 can receive commands and may include its own API stored in the microcontroller memory, which is configured to process commands and act accordingly with its connected device 18. Furthermore, the API of the edge module 300 can organize responses in the response buffer 604 for retrieval by the management system 20 of the returned message. The management system 20 can read the contents of the response buffer 604 via a block read function to the registers of the response buffer 604. For some commands, the response may be a one-byte acknowledgment of success or error when processing the command. For others, the response may also include data. As an example, if the management system 20 is querying the instantaneous current flowing through a specific EHT channel, the command and result response might look like this:

[0082] > CURRENT CHANNEL=7

[0083] OK CURRENT=27

[0084] More specifically, the first line above is a command to query the current on EHT channel 7. This command can be communicated to the EHT controller 18 via line 22 via edge module 300 as a multi-register write to a register associated with command buffer 602. Edge module 300 can interpret the command from command buffer 602 to query the specific channel of interest from EHT controller 18 (e.g., without requiring a command from management system 20 to specify the particular Modbus register of EHT controller 18 associated with that specific channel). The second line is a response acknowledging the command and returning 27 amps of current. That is, edge module 300 can obtain the current from a specific channel of EHT controller 18 (e.g., via conventional Modbus register mapping methods) and write an acknowledgment command and a response providing specific response data in its response buffer 604, which can be communicated back to management system 20 via a multi-register read of the register associated with response buffer 604.

[0085] Furthermore, some embodiments can implement tokenization to further simplify commands and responses. More specifically, keywords can be mapped to or from single-byte or multi-byte representations, and numerical values ​​can be represented in binary form. However, for some commands / responses, text strings can still be concatenated character by character (e.g., when setting remote device names). Therefore, each device 18, 19, 300 and the management system 20 can store such keywords in memory for message tokenization.

[0086] By way of example, using the command above, CURRENT CHANNEL=7 can be folded into two bytes {0x14, 0x07}, where 0x14 is the default opcode for "read channel current" and 0x07 is the parameter (i.e., channel 7). The response can also be two bytes, such as {0x00, 0x1B}, where 0x00 is the "OK" error return code and 0x1B is the requested data. As a more complex example (e.g., more complex than the register mapping command level), the following command can be encoded into only four bytes:

[0087] > MODE MAINTAIN SETPOINT=50C DEADBAND=2C CHANNELS=0x3F

[0088] For example, the first byte can provide an opcode (e.g., "Set mode maintained"), and the second, third, and fourth bytes are the relevant parameters (e.g., providing the setpoint amplitude, deadband, and applicable channels (e.g., via a channel mask)). These four bytes can override many raw register-level writes because the above command affects many channels simultaneously, as indicated by the channel bitmask (CHANNELS = 0x3F), and changing the thermostat mode may involve multiple setting changes for each of these channels. Additionally, during the execution of such a command, the command / response model allows the microcontroller 410 to verify and inspect the requested internal configuration. In conventional register mapping methods, this type of verification is unavailable because the EHT controller 18 only operates on the individual registers indicated by its master device (i.e., the management system 20). However, in the command / response method, for example, the edge module 300 has the ability to understand the entire command (e.g., the purpose of the command) and can verify that the entire command has been executed accordingly.

[0089] The internal structure and format of the command set and corresponding responses can be open-ended and, in some cases, application-specific. However, in some implementations, commands can take the form of opcodes, which optionally follow parameters in a fixed format, the offsets of which, along with their correct interpretation and type (e.g., integers, floating-point values, characters, etc.), can be explicitly inferred from the opcodes. This eliminates the need for syntax parsing, thereby minimizing computational overhead and error conditions at both the management system 20 and the devices 18, 19, and 300.

[0090] Using such tokenization, the software burden for organizing and interpreting both commands and responses will be very low. Although devices will "talk" in binary, commands can be composed of ASCII or Structured Markup Language, and responses can also be rendered back to ASCII or Structured Markup Language for the purpose of simplifying the encoding and human interpretation of supervisor / controller traffic. Additionally, in some implementations, formats such as XML or JSON can be used as alternative human- and machine-readable forms.

[0091] Additionally, in some embodiments, the command and response payloads can be encrypted, for example, via ciphertext. For instance, the payloads can be protected using standard key exchange and encryption protocols, and the sender and receiver identities for each command / response exchange can also be securely authenticated.

[0092] therefore, Figure 7 An example Modbus grouping 700 format according to some embodiments is shown. Figure 7As shown, the Modbus packet 700 may include a Modbus header 702 and a payload 704. The Modbus header 702 may include a corresponding device address, a function code indicating the transaction type (e.g., multi-register read or write), a CRC (Cyclic Redundancy Check), a register address identifying the command buffer or response buffer, and / or other fields. The payload 704 may be the content provided to the command buffer 602 and / or response buffer 604 as a multi-register read / write instruction; that is, it may encapsulate the command buffer 602 or response buffer 604. More specifically, the payload 704 may include an encrypted payload portion 706, for example, including a tokenized opcode 708 and one or more corresponding parameters 710, as described above. The payload 704 may also include a length field (LEN) 712, a version field (VER) 714 (e.g., indicating the API protocol version), and an optional forward error correction (FEC) 716.

[0093] By way of example, a third-party device sniffing all Modbus traffic along bus 22 will see that, instead of the previous scattered register read and write pattern across hundreds of addresses currently used for configuring, monitoring, and controlling each of devices 18, 19, Modbus packets 700 will now be multi-register accesses, and will always go to the same location (e.g., the register associated with command buffer 602 or response buffer 604). Apart from the length and version fields, which may fall outside the encrypted area, the FEC field 716 (described further below) and the encrypted payload 706 will appear as white noise. In fact, repeating the same operation on the same devices 18, 19, 300 will never generate the same packet 700 twice. Additionally, in some implementations, all Modbus payloads 706 can conform to a standard length, thus eliminating the need for the length field 712. Using this encryption method will make it difficult for third parties to reverse engineer how to interoperate with the corresponding devices 18, 19, 300 simply by observing the traffic on line 22.

[0094] Still referencing Figure 7 In some implementations, the Forward Error Correction (FEC) field 716 can be implemented to partially mitigate poor line conditions. For each block of data to be transmitted, additional data is calculated and transmitted with it within packet 700. The FEC data can be used to reliably detect whether a communication error has occurred during transmission, and for corrupted data fields, it may be possible to repair the data on the spot. For example, the amount of corruption that packet 700 can withstand and can still be repaired can be configurable, where a trade-off of greater corruption resistance will result in a larger FEC field 716.

[0095] Modbus Packet 700 can locally include a Cyclic Redundancy Check (CRC) field (e.g., with...). Figure 4 The Modbus header 702 (as in the original text) is designed to allow the receiver to determine whether the most recently arrived packet 700 has suffered any data corruption. Currently, in the event of a CRC failure, target devices 18, 19, and 300 are simply instructed to ignore the corrupted packet 700. There is no negative acknowledgment (NACK) signal returned to the initiator. This uncertainty complicates the communication process, and such problems are typically detected and corrected using timeouts followed by retrying. To help mitigate such problems, long multi-read packets can be broken down into smaller blocks, which statistically have a better chance of passing. However, this solution may waste bandwidth and complicate the process at both ends. On the other hand, error correction may be unnecessary, for example, on lines with good signal quality or for small packets involving only a few bytes of payload. In such cases, additional FEC data would only prolong packet 700.

[0096] Therefore, in some implementations, the FEC field 716 can be optional and can be added on demand during system operation. For example, by adjusting the packet version byte 714, the management system 20 can indicate whether a portion of the payload is FEC field 716. This provides the option for the management system 20 to start without FEC (and therefore smaller packets and higher performance) and dynamically apply progressively stronger FEC support until communication problems are under control. In noisy environments, this can reduce packet loss and improve aggregate throughput performance. Thus, subfields in the packet version field 714n can indicate not only the protocol version but also the FEC used in the payload encoding (if any).

[0097] Furthermore, in some embodiments, an optional set of "common" register address regions can be implemented. That is, in addition to the command and response buffers 602 and 604 described above (which can be written to and read from via encrypted payloads, respectively), a common register space (e.g., a "common buffer") can be designated for regular Modbus register access, which can be accessed without requiring encryption. Examples of access to the common area could be, for example, reading emergency alarm flags or read-only requests for benign status information (e.g., on / off status, etc.).

[0098] Although Modbus is primarily a wired protocol, as stated above, devices 18, 19, 300 and management system 20 can communicate via wireless communication method 23, such as via Wi-Fi (e.g., LAN, mesh Wi-Fi network, WAN, etc.), Wi-SUN, Bluetooth®, Zigbee, or other methods. Therefore, the command / response protocol described herein can be considered a scheme independent of protocol network transmission. That is, packets 700 used and described herein can be transmitted along line 22 or via wireless communication 23. Therefore, any discussion herein of packets 700 or other aspects of the command / response protocol transmitted along wired line 22 also applies to wireless transmission.

[0099] In view of the above, Figure 8 An example of a command / response protocol method 800 according to some embodiments is shown. The steps of method 800 can be executed by management system 20 or edge module 300, as shown below. Additionally, any one or all of these steps can be stored on the memory of the corresponding device as computer-readable instructions, such as as part of an API or other program instructions. Furthermore, although the steps are illustrated and described in a specific order, in some implementations, certain steps may be executed concurrently or in a different order than shown.

[0100] like Figure 8 As shown, typically, method 800 may include management system 20 generating an outgoing command (step 802) and sending the outgoing command as a Modbus packet 700, the Modbus packet including multi-register read / write, writing to a command buffer 602 of a receiving device (such as edge module 300), and reading from a response buffer 604 of the receiving device (step 804). The receiving edge module 300 may interpret and process the command and write a response to the response buffer 604 (step 806). Management system 20 may then read the contents of response buffer 604 (step 808).

[0101] More specifically, at step 802, the management system 20 may generate an outgoing command. The command may correspond to a request for specific devices 18, 19, and 300 to perform an action. For example, the command may be a request for information from specific devices 18, 19, and 300, a configuration change for specific devices 18, 19, and 300, etc. Alternatively, the command may be a broadcast to all devices 18, 19, and 300 on line 22, requesting all devices 18 and 19 to perform an action. Such commands may be automatically generated from the scheduler and / or may be generated in response to user input via user interface 38 or remote device 24.

[0102] At step 804, the management system 20 can send outgoing commands via bus 22 as Modbus packets 700, which include multi-register (“block”) reads / writes, for example, writing to command buffers 602 of receiving devices 18, 19, 300 (or for all broadcasting devices 18, 19, 300), and reading from response buffers 604 of devices 18, 19, 300. That is, as described above and in… Figure 7 As illustrated, Modbus data packet 700 may include a Modbus header 702 with target device information, a Modbus payload 704 including a length field 712, a version field 714, an optional forward error correction field 716, and an encrypted payload portion 706 including an opcode 708 and one or more parameters 710. Additionally, as discussed above, the opcode 708 and / or parameter 710 may be text strings or may be tokenized, for example, by mapping request keywords to single-byte tokens. It is noteworthy that because the commands are high-level commands rather than register-mapped commands that must be specific to the receiving device, the same commands can be used across all devices 18, 19, 300 in system 10. Furthermore, the local firmware in devices 18, 19, 300 may interpret the generic command set differently depending on their local architecture. Moreover, as noted above, in some embodiments, management system 20 may encrypt some or all of the payload 706 (e.g., including block write commands and block read commands) into ciphertext.

[0103] At step 806, the receiving edge module 300 can receive Modbus data packets 700 on bus 22, write the commands of the packets to buffer 602, and then interpret and process the commands from command buffer 602. For example, the receiving edge module 300 can update thresholds or other configuration parameters of devices 18, 19 connected to the edge module 300, turn specific coils on / off, obtain relevant status values ​​or other information, etc. Such changes may affect multiple registers of connected devices 18, 19 that are not specifically identified by the management system 20 or commands, but are communicated by the edge module 300 with devices 18, 19 based on command mapping and via conventional Modbus register read / write through dedicated link 22A. That is, the microcontroller 410 of the edge module 300 can execute instructions in memory to interpret and process commands by mapping requests to specific registers of connected devices 18, 19, so as to perform actions on those registers (e.g., by sending another Modbus packet to devices 18, 19, which has corresponding read / write to the mapped registers). Such processing and interpretation may also include, for example, mapping single-byte tokens within the data in command buffer 602 to keywords associated with a request (e.g., stored in memory), reading macros from the command, and retrieving a list of requests associated with the macros from memory to perform multiple actions, as well as other processing actions. The microcontroller 410 may also, as part of this processing, decrypt the payload 704 from ciphertext to plaintext.

[0104] Furthermore, at step 806, the receiving edge module 300 may generate a response. As described above, in some cases, the response may be a simple acknowledgment of a command (e.g., indicating success or error when processing a command). In other cases, the response may include acknowledgment of a command and / or requested information, such as a requested status value, alarm flag, etc. Data associated with the response may be generated (e.g., written) within the response buffer 604 of the edge module 300. In some embodiments, as described above, the generated response to the management system 20 may be encrypted.

[0105] At step 808, the management system 20 can receive a response by reading the contents of the response buffer 604 (as part of the read / write command discussed in step 804 above) and process the contents of the response buffer 604 to obtain the requested data.

[0106] In some embodiments, Figure 8Method 800 can be conversely broken down into separate write and read steps. That is, the management system 20 can generate an outgoing command as a multi-register write to the command buffer 602, and the receiving edge module 300 can interpret the command and generate a response in its response buffer 604. The management system 20 can then generate another command as a multi-register read from the response buffer 604 of the edge module 300. Additionally, although steps 804-808 have been discussed above regarding the actions performed by the edge module 300, other devices 18, 19 along line 22 capable of communicating via the command / response protocol can similarly perform such actions.

[0107] refer to Figure 2 and Figure 3 System 10 may include a number of EHT controllers 18 and / or other devices 19, 300 that communicate with management system 20 via shared connection 22. Using conventional Modbus communication, there is no command queue. For example, bus 22 will be fully occupied during outbound command packet transmissions, round-trip response times for target devices 18, 19, 300, and incoming response transmissions. This can take a considerable amount of time, which is dead time for all other devices 18, 19, 300. According to some embodiments, asynchronous communication methods may be provided to allow many devices 18, 19, 300 to concurrently process (temporarily overlapping) command / response transactions.

[0108] More specifically, Figure 9 An asynchronous communication method 900 according to some embodiments is illustrated. Additionally, any one or all of these steps may be stored in computer-readable instructions on the memory of the corresponding device, for example, as part of an API or other program instructions. Furthermore, although the steps are shown and described in a specific order, in some implementations, certain steps may be performed in parallel or in a different order than shown.

[0109] like Figure 9As shown, typically, method 900 may include management system 20 sending an outbound multi-register read / write command as a Modbus packet 700, which includes multi-register writes to command buffers 602 of receiving devices 18, 19, and 300 and multi-register reads from response buffers 604 of receiving devices 18, 19, and 300 (step 902). Receive edge module 300 may receive the command, begin processing the command, and generate an automatic response in its response buffer 604 indicating that a response is not immediately available and suggesting a delay before retrying (step 904). After this delay, management system 20 may send a second outbound command as a Modbus packet 700, which includes multi-register reads from response buffers 604 of receive edge module 300 (step 906). If the receiving edge module 300 has completed the initial command (i.e., "Yes" at step 908), the receiving edge module 300 responds to the second command with a response from the response buffer 604, which contains the requested data and / or confirmation of the initial command (step 910). If the receiving edge module 300 has not completed the initial command (i.e., "No" at step 908), the receiving edge module 300 responds to the second command with a response from the response buffer 604, which contains an automatic response with a specified delay (step 912). The management system 20 then waits for the specified delay time (step 914), while the receiving edge module 300 continues processing the command and optionally determines an updated delay time to add to the automatic response in the response buffer 604 (step 916). If the original delay time has expired (i.e., "Yes" at step 918), the management system 20 returns to step 906 and resends the response request command.

[0110] More specifically, at step 902, the management system 20 may send an outbound command as a Modbus packet 700, which contains multi-register read / write commands, wherein the commands are written to the command buffer 602 of the receiving devices 18, 19, 300 and read from the response buffer 604 of the receiving devices 18, 19, 300. This can be similar to... Figure 8 Method 800 describes steps 802 and 804.

[0111] At step 904, the receiving edge module 300 may receive a command, begin processing the command, and generate an automatic response in its response buffer 604. This automatic response indicates that the response is not immediately available and suggests a delay before retrying; this delay can be read by the management system 20. For example, at the moment the receiving edge module 300 receives the incoming command, its response buffer 604 may already be preloaded with a short message indicating that the response will not be immediately available and including a suggested default delay before retrying. The receiving edge module 300 also immediately gets busy processing the command. Additionally, if the receiving edge module 300 can determine an estimated processing time that is significantly different from the default delay in the preloaded response, the receiving edge module 300 may optionally refine the estimate in the response buffer 604.

[0112] At the same time, the receiving edge module 300 can begin preparing a response message to be sent via the response buffer 604. That is, during this period, the receiving edge module 300 can map commands to the registers of its connected devices 18, 19 and send its own commands to the connected devices 18, 19 to obtain requested data or instruct certain actions. In some implementations, this modification of the response buffer 604 of the edge module 300 can be implemented atomically using double buffering, for example, ensuring that the receiving edge module 300 is never caught in the middle of editing the response buffer 604. More specifically, the receiving edge module 300 may include a first "active" response buffer 604 with automatic response, while preparing a second "inactive" response buffer 604 with the requested response. When the requested response is complete, the receiving edge module 300 can make the second inactive response buffer "active" response buffer 604, while invalidating the response buffer 604 with automatic response. Therefore, when the command has been fully processed, the response buffer 604 is properly prepared for the management system 20 to read.

[0113] Still referencing Figure 9 At step 906, the management system 20 may send a second outbound command as a Modbus packet 700, which contains reads from multiple registers in the response buffer 604 of the receiving devices 18, 19, 300. In some cases, the management system 20 may send the second outbound "read" command immediately after the first outbound "read / write" command in step 902. In other cases, the management system 20 may send the second outbound "read" command after a delay from the first outbound "read / write" command in step 902, for example, based on the delay indicated in the initial response from the edge module 300.

[0114] If the receiving edge module 300 has completed the initial command (i.e., "Yes" at step 908), the receiving edge module 300 responds to the second command with a response from the response buffer 604, which contains the requested data and / or confirmation of the initial command (step 910). That is, the receiving edge module 300 has activated the response buffer 604 with the completion request and can allow the management system 20 to read the response buffer 604 containing the response to the initial command from step 902. Communication is then complete because the management system 20 has received confirmation, an error message, or the requested data for the initial command.

[0115] On the other hand, if the receiving devices 18, 19, and 300 have not yet completed the initial command (i.e., "No" at step 908), the receiving edge module 300 responds to the second command with a response from the response buffer 604, which includes an automatic response with a specified delay (step 912). That is, the receiving edge module 300 has activated the response buffer 604 with an automatic response, including a default delay time or an updated delay time, which can be read by the management system 20.

[0116] At step 914, the management system 20 then waits for the specified delay time. At step 916, the receiving edge module 300 continues processing the command and optionally determines the delay time for the update to be added to the automatic response in the response buffer 604. At this time, the receiving edge module 300 still keeps the response buffer 604 with the automatic response active, including the default delay time or the updated delay time, until the inactive response buffer 604 with the actual response completes.

[0117] If the original delay time has expired (i.e., "Yes" at step 918), the management system 20 returns to step 906 and resends the response request command as a second attempt to retrieve the requested response. The loop of steps 906, 908, 912, 914, 916, and 918 can be repeated in a loop until the receiving edge module 300 completes the command (i.e., "Yes" at step 908).

[0118] Therefore, using the method 900 described above, the management system 20 will immediately receive a response from the edge module 300 with an immediate follow-up read request, or will receive a message indicating a minimum suggested waiting time before the management system 20 should attempt to read the response again. In some implementations, devices 18, 19, and 300 may be polled in a cyclical manner to read their status flags to determine whether further processing is required. Figure 9In the asynchronous command response scheme 900 shown, the management system 20 can store a list of all target devices 18, 19, 300 in a table in memory 36. The scheduler of the management system 20 (e.g., executed by processor 34) can determine which device 18, 19, 300 is next to be polled, where each table entry for device 18, 19, 300 can be in one of two states: "command pending" or "no command pending".

[0119] Devices 18, 19, and 300 in a "command pending" state will not be accessed until the time delay indicated in their respective automatic responses expires, because disturbing devices 18, 19, and 300 is pointless if they are not expected to have completed their command processing. However, devices 18, 19, and 300 not in a "command pending" state can be polled cyclically to check for external events, such as alarm conditions, or to collect routine sensor data for trend analysis. Therefore, with a properly constructed scheduler, command responses can be collected shortly after they become available (e.g., after a specified timer expires), and simultaneously, since devices 18, 19, and 300 in a "command pending" state do not participate in polling scheduling before their timers expire, devices 18, 19, and 300 without pending commands can be polled more frequently than in other cases.

[0120] Therefore, the method 900 described above allows commands to be completed asynchronously, and as a result, line 22 can be used for interaction with other devices between command transmission and response reception. Many commands can be executed at any given time, unlocking opportunities for parallel processing and potentially significantly reducing overall completion time. By way of example, complex compound commands received by a single multi-channel device 18, 19, 300 (such as cases where device 18, 19, 300 needs to be initialized, reconfigured, or receive firmware updates) could take a very long time to process. Using the method 900 described above, this processing time will no longer be a dead time on line 22, and furthermore, the management system 20 will not disturb devices 18, 19, 300 with inquiries about their status until a specified delay time has expired. The greater the number of devices 18, 19, 300 sharing Modbus segment 22 in system 10, the greater the positive effects of the method described above. As another example, the management system 20 can send broadcast commands to the command buffer 602 of all devices 18, 19, 300, and the management system 20 can immediately begin to independently query each device 18, 19, 300 for its response, thus giving devices 18, 19, 300 time to generate their responses without occupying line 22.

[0121] As mentioned above, and referring back to Figure 6In some embodiments, devices 18, 19, and 300 may include a response buffer 604 containing a set of consecutive registers, and management system 20 may transmit Modbus packets 700 containing multiple register reads from the response buffer 604 (i.e., those corresponding registers) of receiving devices 18, 19, and 300. Alternatively, in some embodiments, to further improve communication efficiency, a MODBUS FIFO (First-In-First-Out) read queue function may be used to receive variable-length register read vectors up to thirty-one registers in length.

[0122] In some embodiments, to further reduce line traffic and simplify code from the perspective of management system 20, embedded macros can be used in the command / response messaging scheme. For example, during operations such as initialization, large-scale configuration changes, and shutdown, long sequences of operations must be applied to all devices 18, 19, 300 on bus 22. The advanced command / response scheme described above can significantly reduce the number of transactions required on line 22. Additionally, using macros can further reduce these numbers by allowing target devices 18, 19, 300 to store named or numbered command sequences (e.g., downloaded from management system 20).

[0123] By way of example, a simple macro can take the form of a named list of commands stored in the memories 26 and 414 of devices 18, 19, and 300. Once stored in each device 18, 19, and 300, specific commands from the management system 20 can invoke them, at which point devices 18, 19, and 300 execute the commands and automatically perform the corresponding actions. Additionally, in some embodiments, if a command produces an error response, execution can be paused, and the response returned to the management system 20 can include a record indicating the nature of the error and where it occurred during macro execution. Alternatively, to avoid handling partial execution of large macros in the event of errors, the macro system of devices 18, 19, and 300 can run the macro to completion to check for errors before starting to submit changes. In this way, errors will be flagged before any changes are attempted. Furthermore, in some applications, the initial response from devices 18, 19, and 300 can provide a checksum or hash signature to confirm that devices 18, 19, and 300 and the management system 20 have the same stored macros. This additional exchange will prevent the execution of macros that have been modified on one side.

[0124] In some applications, the management system 20 can use macro commands to provide input parameters adapted to different situations. For example, a macro "setpoint" can set all EHT channels with a specific hot setpoint when the macro is invoked, which is passed as a command parameter. That is, the command includes both the macro and the setpoint parameter. As another example, the management system 20 can use macro commands to upload preset system states, allowing the entire composite devices 18, 19 (e.g., multiple channels or groups of channels on devices 18, 19) to switch to a new, pre-recorded preset configuration state via a single command from the management system 20. Given these examples, not only can macros further reduce the number of transactions on line 22, but using macros can also reduce the size of such transactions.

[0125] U.S. Patent Application No. 19 / 2716,612, filed July 8, 2025, describes other examples of Modbus command / response protocol interactions and processes, the entire contents of which are incorporated herein by reference.

[0126] In light of the above, a secure, high-command-based protocol is provided to overcome several key limitations of traditional one-at-a-time control of remote devices (such as industrial controls). Edge module 300 can connect to legacy or third-party devices 18, 19, enabling such devices 18, 19 to present a standardized interface to management system 20, greatly simplifying the control of thousands of such devices 18, 19 of different types across an industrial complex. In other words, according to some embodiments, edge module 300 provides a way to recruit all existing installed controllers 18 into the cybersecurity solution of management system 20 of industrial system 10. Existing devices 18 and 19 can remain in place, and their functionality is enhanced by rewiring their Modbus interfaces to edge module 300 via dedicated link 22A for a few minutes. This allows them to participate in command / response based connections with all the associated advantages (e.g., authentication, encryption, wired efficiency, tolerance to degraded signals, simplified commands, atomic transactions, transaction authentication, understandable advanced logging, protection against competitor snooping and unauthorized interoperability, etc.) while maintaining compatibility with legacy Modbus traffic on the same bus 22. Therefore, edge module 300 provides a low-cost alternative to significantly enhance industrial system 10 without requiring a complete rebuild and controller replacement.

[0127] Furthermore, once the operation of the third-party controller 18 at the Modbus register level is understood, firmware modules for the edge module 300 can be written, allowing these third-party controllers 18 to be seamlessly integrated into the system 10 without the management system 20 needing to know the nature of the third-party controllers 18 abstracted behind its edge module 300. This can elevate the usability of third-party products to a higher level by providing network security that is not natively provided by the third party itself.

[0128] Therefore, edge module 300 can receive commands from management system 20 via command / response protocol, interpret the commands, and control its connected devices 18, 19 accordingly. In some embodiments, edge module 300 can enable two different operating modes: conversion mode and overriding mode. In conversion mode, edge module 300 receives high-level commands from management system 20, as described above, and interprets them in the context of connected devices 18, 19. Edge module 300 translates these commands into appropriate configuration changes for connected devices 18, 19, which continue to operate autonomously using their own execution control functions. That is, connected devices 18, 19 maintain their independent decision-making capabilities and behaviors based on the configuration parameters communicated by edge module 300. In overriding mode, edge module 300 assumes the execution functions of connected devices 18, 19, which are simplified to a set of non-execution low-level functions. Edge module 300 directly accesses and manipulates the core low-level features of connected devices 18, 19, and directly complies with command / response commands by assuming the role of the underlying controller hardware.

[0129] More specifically, in conversion mode, edge module 300 receives advanced commands from its upstream port 404 and interprets them within the context of host devices 18, 19. Downstream link 406 is then used to configure host devices 18, 19 to reflect the requirements of the received commands. For example, in the case where EHT controller 18 acts as the host, management system 20 can send a command to select an "anti-freeze" mode, in which the associated thermal tracking cable 14 will be energized in such a way as to prevent heat load (e.g., Figure 1 Surface 12) is close to the freezing point. Edge module 300 transitions from the high-level command domain to the local characteristics of host device 18, i.e., by writing commands to specific device registers, causing EHT controller 18 to perform this function. This can be beneficial because it allows many different host devices 18, 19 to be controlled in the same way, thereby simplifying many aspects of managing system 20 and the operator's interpretation of system status.

[0130] In contrast, in overlay mode, edge module 300 can assume the execution functions of host device 18, which are now reduced to a set of non-execution low-level functions. For example, the basic EHT controller 18 may include an RTD (temperature sensor), a CT (load and ground fault current sensor), and a relay driver for modulating heating current. Edge module 300 can determine how to directly access and operate these core low-level features via Modbus register commands through its downstream link 22A, and continues to directly comply with commands / respond to commands, assuming the role of the underlying controller hardware (i.e., the controller logic that takes over these core functions). When access to sensors and actuators is required, edge module 300 only uses its downstream link 22A to slave hosts 18, 19, such as in the case of Modbus, by reading or writing the appropriate function-specific control registers.

[0131] Figure 10 Example process 1000 covering host devices 18 and 19 is shown. Figure 10 As shown, process 1000 may include four steps: identification step 1002, mapping step 1004, conditional step 1006, and overlay step 1008.

[0132] For example, in identification step 1002, edge module 300 can identify the type of host devices 18, 19 to which it is attached by probing host devices 18, 19 via its downstream port 406. This identification can be performed by matching device resources against a signature database from known devices (e.g., stored in memory 414 of edge module 300). Edge module 300 can query host devices 18, 19 (e.g., by reading from specific Modbus registers) to determine their vendor, model, firmware version, and other identifying characteristics that allow edge module 300 to appropriately interface with a particular device type.

[0133] In mapping step 1004, using the device identification information from step 1002, edge module 300 can refer to another internal database in memory 414 to identify the quantity, type, and location of each resource (e.g., RTD, CT, relay) to be used. For example, in the case of Modbus-based host devices 18, 19, this involves determining the Modbus register address of each resource and mapping them to internal variables so that these resources can be accessed during overlay operations. This mapping process involves establishing the location of access to specific control points and how to configure or interpret them. For example, in the case of EHT controller 18, the temperature representation format may depend on the specific register in question, including variations in units (Celsius, Fahrenheit, Kelvin), data type (floating-point, integer, fixed-point), data width, and other formatting considerations.

[0134] In conditional step 1006, before coverage can begin, the host devices 18 and 19 can be adjusted so that they will be passive and will not make decisions or take actions independently without a request from the edge module 300. For example, the displays, radios, and other peripherals of devices 18 and 19 can be disabled or silenced, and the automatic control mode can be deselected. As an example, in the case of the EHT thermostat controller 18, if available, the output state of any power relay can be configured to manual ON / OFF mode. If no such mode is available, the same effect can be achieved by establishing a temperature maintenance management mode and instead by changing the command setpoint, which is equal to or below the minimum value (turning the relay on) or equal to or above the maximum value (turning the relay off).

[0135] In the coverage step 1008, the edge module 300 becomes the sole execution agent, indirectly reading sensor values ​​and setting actuation values ​​using the passivated host devices 18 and 19. During this coverage operation, the edge module 300 assumes the role of the underlying controller hardware and directly complies with / responds to commands by accessing and manipulating the core low-level features of the host devices 18 and 19 (such as ON / OFF control of associated relays). In other words, the edge module 300 implements its own control algorithms (e.g., thermostat logic) while utilizing the hardware resources of the host devices. The host devices 18 and 19 are effectively reduced to a set of non-executing low-level functions in response to commands from the edge module 300.

[0136] In some examples, overlay mode can provide a lower-risk and simpler path to utilize external controllers. More specifically, operating in conversion mode requires a complete understanding of the operation of host devices 18, 19, as expressed through their low-level APIs (typically Modbus register mappings in the case of EHT controller 18). This can result in complex software drivers for each specific type of host controller 18, increasing development time and implementation risk. In overlay mode, much of the standard controller logic of edge module 300 remains unchanged across the entire range of possible host controllers 18. The controller's API needs to be understood to the minimum required to perform steps 1002-1006 above. Therefore, assimilating new host controllers 18 is much faster and carries significantly less operational risk.

[0137] In addition to the conversion and overlay services provided by edge module 300 as described above, in some embodiments, edge module 300 may also be configured to leverage its privileged location adjacent to devices 18, 19 to perform additional services, such as high-fidelity logging and edge analytics capabilities, thus providing additional functionality while still operating across a low-data-rate and often unreliable installation cable infrastructure. More specifically, in some embodiments, edge module 300 may include relatively ample flash memory 214 to allow edge module 300 to cache high-frequency and high-fidelity logging and telemetry essentially at devices 18, 19 (e.g., at the “edge” of devices 18, 19 in the field rather than remotely at management system 20). Furthermore, edge module 300 may interact more intensively with its companion devices 18, 19 than, for example, management system 20, which typically sees sharing bus 22 with many other devices 18, 19.

[0138] For example, detailed logging of device parameters, behavior, and diagnostics can be valuable during any type of failure event. However, the logging capabilities of many existing EHT controllers 18 are typically very limited. For instance, some older EHT controllers 18 lack sufficient flash storage. Furthermore, the low reliability and data rates of upstream connections (e.g., along line 22), and the shared nature of the RS-485 bus 22, generally mean that continuous streaming of detailed log information for collection at the management system 20 is not feasible.

[0139] Even though the command / response protocol described above can maximize the utility of RS-485 link 22, line 22 is not fundamentally faster or less shared than before, so continuous upstream logging is generally still not a viable option. However, according to some embodiments, edge module 300 can very aggressively pump telemetry for its companion devices 18, 19 because it can write timestamped records into its own very large flash memory 214. For example, with 64 GB of flash memory 214, a continuous 9600 baud rate logging stream would not begin to overwrite the first entry for two years. In reality, the actual log generation rate may be far below the hard cap of 9600 baud rate (i.e., the limitation of the downstream RS-485 port), so 64 GB may be sufficient for logging information throughout the entire device lifecycle. In addition, since the flash memory cells used for such logging can be effectively written once, considerations such as wear leveling are not applicable, and the storage system 214 will be reliable and long-lived.

[0140] In some embodiments, in the event of a system failure or disturbance, the management system 20 can query all involved edge modules 300, recover relevant portions of their local log databases (e.g., between appropriate timestamp brackets), and reconstruct a detailed, time-indexed, multi-channel picture of what happened and in what order. This can greatly facilitate remote troubleshooting and debugging, and can also form the backbone of lifecycle trend information. Local free-running clocks can be used to timestamp log entries with high time resolution within each edge module 300. Additionally, periodic broadcast “tick” commands from the management system 20 will be registered to the logs of all edge modules 300 almost simultaneously, allowing for subsequent time registration of numerous parallel log sequences.

[0141] Furthermore, this onboard archiving of log information on the edge module 300 could be attractive to customers who do not wish to disclose operational details in the field. For example, system 10 could be configured such that this data will never routinely leave the edge module 300 and can only be retrieved under special circumstances.

[0142] Furthermore, performing many types of data analysis as close to the data as possible is far more efficient. As mentioned above, the microcontroller 410 is well-suited to perform this task because the edge module 300 is capable of storing large amounts of data from its high-frequency logging. For example, in some embodiments, the management system 20 can send commands to the edge module 300 to instruct it to perform searches, statistical analyses, and / or general computations, such as signal processing, Fourier transforms, etc., “in-place” (i.e., at the device) on the data. These “edge” analyses (i.e., analyses performed essentially at or near devices 18, 19) can be valuable because while much of this low-density data is effectively trapped within the edge module 300, summaries of many analytical functions can be very small and easily shared with the management system 20. For example, regression (curve fitting) can be performed locally on the edge module 300 in the background, and only a few bytes of data (such as fit coefficients, statistical features, etc.) need to be returned to the management system 20 while many gigabytes of data are ingested and processed. Furthermore, in some embodiments, the edge module 300 can be configured to automatically perform data analysis, for example by running programs in the background, such as searching for outliers or abnormal readings to report back to the management system 20.

[0143] As another example, in some embodiments, the edge module 300 can be configured to automatically perform data analysis, such as continuous sampling and logging of power and RS-485 signal integrity. For example, industrial equipment is frequently plagued by power integrity issues, and the EHT controller 18 often sees corrupted RS-485 data frames in the field. Since these problems are often transient, they can be difficult to prove. However, in some embodiments, the microcontroller 410 of the edge module 300 may include a multiplexed analog-to-digital converter (ADC) function, allowing it to digitally sample power lines and communication lines, including both alternating current (AC) lines and direct current (DC) lines. The microcontroller 410 can execute continuous digital signal processing (DSP) algorithms to check for power noise, surges, spikes, and low voltage detection, generate log data, and trigger configurable alarms. The microcontroller 410 can also continuously sample from the upstream RS-485 Modbus 22 into a circular buffer at high frequency. When the microcontroller 410 detects packet corruption, waveform capture can be temporarily paused while analyzing and / or saving the failed packet trace for later inspection.

[0144] As yet another example, edge module 300 can be configured to automatically store all Modbus transactions in its memory 214. This data can then be processed to understand network activity patterns and the traffic generated by all devices 18, 19, 300 on line 22.

[0145] In view of the above, the edge module 300 can be coupled to legacy devices or third-party devices 18, 19 in the industrial system 10 for purposes such as command interpretation (e.g., from the management system 20), downstream device normalization, FEC processing to support poor electrical signaling environments, local log services to capture far more data than can be flowed back, and / or integrated analytics to process archived log data in place, thereby allowing more data to be considered by the centralized management system 20.

[0146] In addition to connecting to legacy devices or third-party devices 18, 19 that were previously connected and communicated with the management system 20 via RS-485 bus 22, in some embodiments, the edge module 300 may be implemented in the system 10 to provide the management system 20 with information about devices 19 that were not previously communicating with the management system 20. By way of example, many components of the industrial system 10 may not be controlled by the EHT controller 18 or other devices 19 that communicate with the management system 20. For example, such components may be added to the system 10 and directly controlled by mechanical circuit breakers, relays, thermostats, etc. In this way, the management system 20 has little visibility into the operation of these components. In some embodiments, the edge module 300 may be coupled to such components or devices 19 in a manner that allows the edge module 300 to obtain data related to the operation of the devices 19 and to relay information about the devices 19 to the management system 20.

[0147] For example, Figure 11 Another example edge module 300 is shown according to some embodiments. For example... Figure 11 As shown, the edge module 300 may include a housing 402, an upstream port connection 404, a downstream port connection 406, a power port connection 408, and an internal PCBA 1102, for example, including the components described above. Figure 4 The microcontroller 410, power regulator 412, and flash memory 414 are mentioned.

[0148] Regarding housing 402, typically, in an example implementation, edge module 300 can be a small module designed to be mounted on the surface of a junction box, wall-mounted enclosure, or freestanding control panel. For example... Figure 11 As shown, housing 402 may include a base 1104 (e.g., a stainless steel plate), a threaded neck 1106 extending downward from the base 1104, and a top shell 1108 extending upward from the base 1104. For example, installation may involve finding or drilling a small hole (e.g., approximately 25 mm in one implementation) through a surface 1110 (e.g., a wall) of the box, housing, or panel. The threaded neck 1106 can pass through this hole and can be secured on the other side by a locking nut 1112. In some implementations, a gas seal 1114 may be provided and compressed between the base 1104 and the surface 1110 to ensure suitable explosion protection, for example, when deployed in an explosive atmosphere. For example, the locking nut 1112 can be tightened from the inside to securely mount the edge module 300 and compress the gas seal 1114. Alternatively, washers and locking washers may be used instead of the locking nut 1112.

[0149] Still referring to housing 402, extending upward from base 1104, top housing 1108 may be made of a suitable transparent plastic with high impact resistance, UV resistance, and temperature resistance. For example, in some embodiments, top housing 1108 may comprise an optically and radio-transparent plastic, thick enough to provide a dielectric depth suitable for ATEX (Explosive Atmospheres and X-rays) approval. Top housing 1108 may enclose internal components within housing 402, such as PCBA 1102 handling all electronic functions, including microcontroller 410, power regulator 412, and flash memory 414 (not included in the main unit). Figure 11 (As shown in the diagram), as well as a wireless communication antenna 1116 and an indicator LED 1118. In some implementations, PCBA 1102 may include multiple stacked PCBAs if required by a specific application. Furthermore, wires or connectors may be directly attached to PCBA 1102. Typically, the electronic area and threaded neck 1106 may be completely filled with potting compound 1120. Additionally, depending on the application, the hemispherical region 1122 in the upper region of the top shell 1108 may be empty or filled with an optically clear potting compound.

[0150] In some embodiments, the wireless communication antenna 1116 may be a low-gain (near omnidirectional) antenna for use with Wi-Fi, Bluetooth, or other radio modules integrated into the main PCBA 1102. The antenna 1116 may be a printed, metal, or ceramic chip antenna. Additionally, one or more upward-emitting RGB indicator LEDs 1118 may be used to indicate the status of connected devices 18, 19 (e.g., the status of EHT circuitry and / or control systems). In some embodiments, the indicator LEDs 1118 may be partially encapsulated in a potting compound 1120, with the top of the indicator LEDs protruding into a top region 1122. As described above, the top region 1122 may be optically transparent, and light may be designed to partially reflect at the interface between the top region 1122 and the inner surface of the top housing 1108 to provide a near-spherical coverage distribution. Additionally, in some embodiments, the top surface 1130 of the top housing 1108 may be multifaceted to amplify this effect and control how much light is directed to each subtended elevation angle. In some embodiments, the indicator LED 1118 may be the same color, different colors, or multiple colors to indicate different states and alarms, etc. Furthermore, in some embodiments, PCBA 1102 may include additional electronics. As an example, PCBA 1102 may include a resistor (not shown) that can be used as an internal heating system to prevent the top housing 1108 from icing.

[0151] As described above, the edge module 300 can be mounted on the housing wall 1110 such that the threaded neck 1106 extends into the panel or housing. The edge module 300 can interact with devices within the host housing via a cable that emerges directly from the potting compound 1120 at the end of the threaded neck 1106 or is inserted into a connector (not shown) protruding from the potting compound 1120 on the open surface of the threaded neck 1106. Either design can present a minimal footprint impact on internal equipment during retrofitting. Interaction connections extending from the edge module 300 may include an upstream Modbus link connection 404, a downstream Modbus link connection 406, a power connection 408, a current transformer (CT) input 1124, an RTD input 1126, and / or an electromechanical relay (EMR) or solid-state relay (SSR) output 1128. It should be noted that some implementations of the edge module 300 may not include all of these connections, or may include additional connections.

[0152] Regarding power port 408, in some embodiments, edge module 300 can draw DC or AC power from within the panel, which is most convenient. As mentioned above, in some implementations, the total power consumption can be very low, for example, up to 2-3 watts. Additionally, some edge modules 300 may appear only in DC or AC versions to control the complexity and cost of any given installation.

[0153] Regarding the Modbus interface, edge module 300 may include upstream and downstream links 404, 406, as described above. Specifically, upstream Modbus link 404 can provide a connection to management system 20 (via bus link 22) to enable command / response communication. Downstream Modbus link 406 can provide a dedicated connection 22A to devices 18, 19 to enable traditional register connections.

[0154] Regarding the additional inputs and outputs, CT input 1124 allows edge module 300 to connect to one or more current transformers that can measure instantaneous currents, such as load or ground leakage current. RTD input 1126 allows edge module 300 to connect to one or more RTD sensors, for example, for measuring load or ambient temperature. EMR / SSR drive output 1128 allows edge module 300 to directly energize or de-energize connected power relays or alarm relays. The functionality and benefits of these additional components will now be described with reference to some potential use cases.

[0155] According to the first scenario, the edge module 300 can be used for EHT circuits that lack instrumentation, controllers, or thermostats. For example, in areas that do not typically experience severe cold weather and / or only require freeze protection, many self-regulating (SR) EHT cables are directly energized through circuit breakers with manual switches. Such circuits are not associated with any thermostat or controller, and there is no means to remotely monitor the circuit status or any potential fault conditions. Furthermore, the current consumption of the EHT circuit is not monitored, making it difficult to detect aging cables or defective insulation. Therefore, such locations are not connected to RS-485 or any form of wired network.

[0156] In this scenario, edge module 300 can be deployed as a wireless CT / RTD sensor node. Edge module 300 can capture current and voltage readings (via CT input 1124), optionally ambient or local temperature readings (via RTD input 1126), process, store, and interact with management system 20 via a wireless network (via wireless antenna 1116), and also mark circuit status via indicator LED 1118. More specifically, readings can be acquired at high frequency, and all sampled data can be written to a large-capacity internal non-volatile log memory 414. Management system 20 can interact with command processor module via Wi-Fi or a field area network (FAN) such as Wi-SUN, and restore current temperature, power levels, ground fault levels, and alarm status. Management system 20 can also request edge module 300 to query its log entries using specified search or analysis criteria.

[0157] According to this scenario, numerous uncontrolled EHT circuits deployed in the field can be continuously monitored without installing communication lines or new enclosures. Due to its simplicity, low cost, and small size, the edge module 300 can be easily retrofitted into any existing installation. For example, the edge module 300 can be installed into existing junction boxes or power supply boxes for the EHT circuits. Furthermore, according to this scenario, in some applications, the edge module 300 can be used as a smart lighting end seal, as the LED 1118 can now do more than just confirm cable energization. Additionally, using the Bluetooth functionality of the edge module 300, operators can sample circuit status from nearby locations using Bluetooth-enabled mobile phones, tablets, or similar remote devices, as described above. In this mode, the edge module 300 can be completely passive, providing only monitoring services, while the operation of the EHT circuits remains completely unaffected. As a result, the risk of interruption to ongoing operations is very low when the edge module 300 is retrofitted into such a system. Furthermore, using a clip-on CT with the edge module 300, existing high-power cables do not need to be interfered with to introduce current sensing capabilities into this system.

[0158] According to the second scenario, the edge module 300 can be used to instrumentate existing mechanical thermostats. For example, similar to the first scenario described above, many installed circuits are controlled by simple mechanical thermostats. Such devices are simple and can be very reliable if simple and infrequently changed thermal regulation is required. However, again, it is impossible to know the performance of the thermostat, nor the performance of the cables and insulation.

[0159] In this scenario, edge module 300 can be deployed to monitor the output of each mechanical thermostat (e.g., relay commands) using, for example, CT input 1124, as current consumption changes when the thermostat switches the EHT circuit on or off. As a result, edge module 300 can bring non-electronically controlled EHT circuitry into the scope of central management system 20, monitoring its data and history for analytics services to generate valuable insights into the state of system 10. Bluetooth access can also provide operators with access to this data in the field (e.g., via remote device 24). Furthermore, by adding an RTD connected via RTD input 1126 to this configuration, edge module 300 can monitor thermostat performance by tracking the same temperature it inputs and observing its on / off decisions. In this scenario, edge module 300 can identify setpoints and dead zones and generate alarms if mechanical thermostats and / or cables are found not to be operating as required. Additionally, in some embodiments, edge module 300 can analyze RTD input 1126 to monitor cable status, allowing for lifespan data analysis and maintenance prediction. Furthermore, since the thermostat can inherit Bluetooth access from the edge module 300, it can be configured and monitored by a nearby technician using the remote device 24.

[0160] According to the third scenario, the edge module 300 can be used to instrumentate existing third-party (“external”) controllers. Similar to the example described above, some circuitry is managed by the electronic controller 18, but they lack command / response protocol capabilities. Therefore, the edge module 300 can be deployed to simulate the inputs and outputs of the third-party controller, returning this instrumentation to the management system 20. Thus, the edge module 300 further extends the coverage of the industrial system 10 to include circuitry managed by the external controller 18. Performance and faults can be independently flagged and indicated via alarms, Bluetooth interaction can be enabled, and a visual LED indicator 1118 can also provide status indication in the field.

[0161] The three scenarios above appear functionally identical, but they apply to different pre-installed EHT equipment. Overall, these three scenarios represent the majority of deployed EHT circuits, thus representing a significant increase in available data collection capabilities for real-time monitoring and alarm functions, as well as long-term analysis.

[0162] Furthermore, there is a significant market for the ability to upgrade EHT circuits in the aforementioned three scenarios to modern, cyber-secure electronic control and monitoring solutions. By additionally utilizing the EMR / SSR drive output 1128 to drive EMR / SSR switching devices, the edge module 300 can be used as a full-featured single-channel EHT controller with CT and RTD inputs, equipped with Wi-Fi, Bluetooth, visual indicators, and advanced logging / edge analytics.

[0163] For example, when upgrading an existing thermostat or external controller, the SSR or EMR may already be in place, and the upgrade is simply a matter of disconnecting the existing thermostat or controller and rewiring the relay to the edge module 300. Upgrading an existing EHT circuit lacking a controller or thermostat may require installing an SSR or EMR. Additionally, in this scenario, the downstream RS-485 Modbus port 406 may not be necessary because there will be no host devices 18 or 19 to interface with. In some cases, port 406 can be used to connect to other Modbus equipment, such as an RTD multiplexer, or even to an additional edge module 300 to provide fault-tolerant configuration.

[0164] Alternatively, in some embodiments, edge module 300 may not include CT input 1124, RTD input 1126, and / or EMR / SSR drive output 1128. Instead, these interfaces and functions can be implemented in a separate “auxiliary module” that acts as a controller 18 tailored for a specific control scenario and connects to downstream port 406 of edge module 300. In this way, edge module 300 forms the “brain” of controller 18 (including domain-specific interfaces RTD, CT, etc.) and provides communication interfaces, all business logic, etc. Thus, in this scenario, the auxiliary module will still communicate with edge module 300 via a dedicated serial interface, effectively acting as a host device manufactured for this purpose, since there are no existing devices that can be covered in this application.

[0165] Turn now Figure 12 and Figure 13 According to some embodiments, another example edge module 300 is shown. Figure 12 A top-view isometric view is shown, and Figure 13 A cross-sectional view of the edge module 300 is shown. (As shown) Figure 12 As shown, the edge module 300 may include a housing 1200, which includes a base 1202 and a top shell 1404 extending upward from the base 1202 (via, for example, fasteners 1318). Figure 13(As shown in the diagram) and coupled together with a suitable washer (not shown). The top shell 1404 may include a pyramidal structure having multiple wide faces 1406, and a lens 1408 (e.g., a Fresnel lens) is located at the apex of the pyramidal top shell 1404. For example, the lens 1408 may be coupled to (e.g., screwed to) an opening at the apex of the top shell 1404.

[0166] like Figure 12 As shown, the base 1202 has a generally octagonal shape with its corners truncated, thus providing a bottom surface suitable for mounting on a standard electrical junction box. The overall dimensions of the base 1202 can be configured such that the edge module 300 can be directly mounted onto the 100mm × 100mm bottom surface of the cover of a standard electrical junction box, wherein the truncated corners provide clearance for the corner screws that attach the cover to the junction box. However, other dimensions may also be used for other applications. For example, the pyramid housing 1200 can also be mounted onto the cover of other controllers 18 or onto the exterior of existing equipment panels and enclosures, or any other surface. By being configured for external mounting, the housing 1200 can be made of a material and have a sufficient sealing configuration for installation in hazardous locations, such as locations classified as ATEX Zone 1 (e.g., high-risk areas where explosive atmospheres may occur during normal operation).

[0167] like Figure 13 As shown, the edge module 300 may include a threaded neck 1300 extending downward from the base 1202. The threaded neck 1300 allows the edge module 300 to be attached by drilling a suitable hole, inserting the threaded neck 1300 into the hole from the outside, and securing it with an internal locking nut (similar to the above regarding...). Figure 11 The locking nut 1112 is discussed. The joint can be protected with an assembled washer to maintain an airtight seal across the interface (e.g., similar to the above regarding...). Figure 11 (Described gasket 1114). Then the sensor, power and communication cables can pass through the through-hole opening 1302 of the threaded neck 1300 to interface with the equipment inside the housing 1200.

[0168] Still referencing Figure 13 The edge module 300 may include two PCBAs positioned within the housing 1200. A first PCBA 1304 is positioned within an internal cavity 1308 adjacent to the base 1202, and an LED PCBA 1306 is positioned above, parallel to, and spaced apart from the first PCBA 1304, and adjacent to or located within a lens cavity 1310. The first PCBA 1304 may include various electronic components, such as, but not limited to, a microcontroller, a power converter (e.g., an AC / DC converter), memory, and / or other electronic components (as described above). Figure 4 (as described above). In some embodiments, the first PCBA 1304 may also include an accelerometer (not shown). For example, a six-axis accelerometer capable of detecting rotational and translational vibrations in all three spatial dimensions could allow the edge module 300 to monitor vibrations in its environment, as changes in vibration patterns can be precursors to equipment failures such as motors, pumps, and compressors. Vibration can also be used to determine whether liquid is flowing in pipes, so the accelerometer can be used at least in part for flow determination by the edge module 300 and / or connected devices 18, 19.

[0169] Still referencing Figure 13 The LED PCBA 1306 includes one or more LEDs 1312 mounted thereon, positioned to emit light upwards through a lens 1408 at the top of the top housing 1404 (e.g., similar to the indicator LED 1118 described above). The lens 1408 and its housing can be formed as a single piece of high-impact polymer, and the lens chamber 1310 can be filled with an optically clear gel to prevent air pockets and provide a clear light path to the outside for the LEDs 1312. For example, the LED PCBA 1306 can be directly pushed onto the top surface of this gel to meet the requirements of ATEX region 1. Additionally, the lens 1408 can be screwed into a female thread at the top of the pyramid housing 1404 along with a suitable gasket (not shown), and in some embodiments permanently secured with a thread-locking adhesive. Furthermore, the remaining internal chamber 1308 can be filled with a potting compound cured to a rigid state, providing mechanical support while sealing the interior to the environment and displacing any air pockets.

[0170] Additionally, in some embodiments, such as Figure 11 The edge module 300 is the same. Figure 12 and 13The edge module 300 may include multiple radios. In one embodiment, the edge module 300 may include four radios with different frequencies, using three antennas: a first antenna for Wi-SUN field area networks, a second antenna for Wi-Fi and Bluetooth® Low Energy (BLE), and a third antenna for near field communication (NFC) devices. Each of these antennas may be formed by a PCB structure 1314 and attached to the inner surface of a corresponding wide facet 1406 of the top housing 1404. The antenna PCB structure 1314 may be optimized for operation when embedded in a potting compound. For example, if the edge module 300 is intended to be located in a location where radio communication would be disadvantageous due to shadows from large metal structures, the edge module 300 may alternatively be configured without internal 900MHz and 2.4GHz antennas, instead leading its RF connections through opening 1302 to an external antenna that can be positioned for better radio operation. Such an option may also be used when a high-gain antenna is required for point-to-point beamforming over longer distances.

[0171] Turn now Figure 14 and 15 Another example edge module 300 is shown. Figure 14 A top-view isometric view is shown, and Figure 15 A perspective view of the edge module 300 is shown. In some embodiments, although Figure 12 and 13 The edge module 300 can be configured to be mounted outside the enclosure, thus allowing it to be installed in an explosive atmosphere (ATEX Zone 1 environment), but Figure 14 and 15 The edge module 300 can be configured to be mounted inside the enclosure. Since the module 300 can be protected from explosive atmospheres by its mounted enclosure, its design can alternatively be adapted to Zone 2 environments (e.g., where explosive atmospheres are unlikely to occur during normal operation, and if they do, they will only exist for a very short time). However, Figure 14 and 15 The edge module 300 may include and Figure 12 and 13 The edge module 300 is a similar component, and therefore the similar elements are numbered accordingly.

[0172] For example, such as Figure 14As shown, the edge module 300 may include a housing 1400, which includes a base 1202 and a top cover 1404 extending upward from the base 1202. The housing 1400 may have a compact, generally octagonal form factor suitable for mounting on a standard DIN rail. Therefore, the top cover 1404 may be substantially flat. An Ethernet port 1406 may be located on the front of the housing 1400 to provide communication with the management system 20. Multiple ports 1408 (e.g., similar to...) Figure 4 The upstream port 404, downstream port 406, and power port 408 can also be located on the front side to provide communication with the management system 20 and to receive power from connected devices 18 and 19, respectively. One or more radio couplers 1410 can be located on another front side (or the same front side) to interface with an external radio connection.

[0173] like Figure 15 As shown, the edge module 300 may include a first PCBA 1304 positioned within a housing 1400. As described above, the first PCBA 1304 may include various electronic components, such as, but not limited to, a microcontroller, a power converter (e.g., a DC:DC converter for a 24V DC input from within the housing), memory, and / or other electronic components. The edge module 300 may also include a terminal PCBA 1500 positioned within the housing 1400, which can be used for wire termination and Ethernet connectivity from corresponding ports 1406, 1408. Additionally, in some embodiments, the edge module 300 may include wireless communication capabilities via external connections. For example, Wi-SUN and Wi-Fi / BLE antennas may be connected to a coupler 1410 positioned on the top surface of the housing 1400. The coupler 1410 may be, for example, an SMA (subminiature version A) coupler or other couplers suitable for radio connectivity. This configuration may allow for optimal antenna placement when the edge module 300 is installed inside a metal housing that would otherwise interfere with radio communications.

[0174] Furthermore, in some embodiments... Figure 14 and 15 The edge module 300 can be configured without potting compound, allowing easier access to internal components when installed in a protected environment. Fasteners 1318 can be used to removably couple the base 1202 and top cover 1404 together while maintaining accessibility. Therefore, the housing 1400 can be designed to provide sufficient protection for internal components when necessary, while allowing maintenance and service access.

[0175] Given the above, many different shape factors and configurations of the edge module 300 can be used to adapt to the required application. Furthermore, according to further examples, such as... Figure 16As shown, a pair of edge modules 300 can redundantly manage circuitry. More specifically, in some applications, edge modules 300 can be deployed before a large controller 18 with numerous circuits, on a link between multiple controllers 18, or on a single controller 18 with plant-critical functions. In many cases, it may be desirable to eliminate edge modules 300 as single points of failure by using two edge modules 300 in a redundant pair mode. In this mode, two identical edge modules 300 can be installed side-by-side, sharing an upstream link to the management system 20. The two edge modules 300 can also be independently connected to all downstream host devices 18, 19. Additionally, the pair is connected via a dedicated point-to-point cable 1600, which provides bidirectional communication and a means for each module 300 to disable the other. Once powered on, each edge module 300 identifies its connection to its partner edge module 300 via their common communication links 22A, 1600. Edge modules 300 can compare their unique IDs, and in one embodiment, the edge module 300 with the highest numerical ID is determined to be the active edge module 300, and the other edge module 300 can assume a passive monitoring role.

[0176] During normal operation, the active edge module 300 performs its functions normally and frequently transmits all relevant operational data to the passive monitoring edge module 300. Simultaneously, the passive edge module 300 can monitor all command response traffic between the active edge module 300 and the management system 20. The passive edge module 300 can combine these two information sources to determine whether the active edge module 300 is functioning correctly. If it is determined that the active edge module 300 is unresponsive or has malfunctioned, the passive edge module 300 can assume its role and become the active edge module 300.

[0177] In some implementations, to change roles, the passive edge module 300 can first disable the faulty edge module 300 by continuously asserting its hardware reset signal via a shared dedicated link 1600. This may cause the edge module 300 to be suspended indefinitely in its reset state (e.g., the processor is no longer running and all peripherals and communication channels, including radio, are in a static state). The taking over edge module 300 continues to perform the role of the active module 300. It assumes the communication addresses associated with the faulty edge module 300, allowing the monitoring network to continue functioning normally. The new active edge module 300 begins communicating with the host devices 18, 19, which benefit from all the status information it tracked during monitoring mode. From the perspective of the management system 20 and the host devices 18, 19 behind it, the transition is seamless.

[0178] Additionally, in some embodiments, LED indicators 1118 and 1312 can indicate that the first edge module 300 has failed and that the pair of modules is now operating in a "failover" mode. LEDs 1118 and 1312 on the module 300, which remains in a reset state, are all off, which may indicate an abnormal operating state. An alarm indicating a device failure can be issued to the management system 20, but normal operation continues, although it is now in a non-redundant configuration. The passively monitored edge module 300 can also perform continuous self-tests on itself. If it determines that it has an internal fault in passive mode and the active edge module 300 is functioning normally, it suspends operation. If it can still communicate with its active edge module 300, it can request that it remain in a reset state. In this case, the management system 20 can be made aware that the previously fail-safe topology has degraded to a non-redundant topology.

[0179] As used herein, the wording and terminology employed are for descriptive purposes and should not be considered restrictive. The use of “comprising,” “including,” or “having,” and variations thereof throughout this document is intended to cover items subsequently listed and their equivalents, as well as additional items. Unless otherwise stated or limited, the terms “installation,” “connection,” “support,” and “coupling,” and variations thereof, are used extensively and cover both direct and indirect installations, connections, supports, and couplings. Furthermore, “connection” and “coupling” are not limited to physical or mechanical connections or couplings, but may also include fluid and electrical connections.

[0180] As used herein, the terms “comprising,” “including,” or “having,” and their variations, are intended to cover the items listed below and their equivalents, as well as additional items. Unless otherwise stated or limited, the terms “installation,” “connection,” “support,” and “coupling,” and their variations, are used broadly and to cover both direct and indirect installation, connection, support, and coupling. Furthermore, “connection” and “coupling” are not limited to physical or mechanical connections or couplings, but may also include fluid and electrical connections.

[0181] As used herein, unless otherwise limited or defined, “or” signifies a non-exclusive list of components or operations that can exist in any variety of combinations, rather than an exclusive list of components that can only exist as substitutes for each other. For example, a list of “A, B, or C” indicates options: A; B; C; A and B; A and C; B and C; and A, B, and C. Accordingly, the term “or” as used herein is intended to indicate an exclusive substitution only when preceded by an exclusive term such as “either,” “one of,” “only one,” or “exactly one.” For example, a list of “one of A, B, or C” indicates options: A, but not B and C; B, but not A and C; and C, but not A and B. “One or more” (and its variations) and “or” used to separate lists of listed elements indicate options of one or more of any or all of the listed elements. For example, the phrases “one or more A, B, or C” and “at least one A, B, or C” indicate options such as: one or more A; one or more B; one or more C; one or more A and one or more B; one or more B and one or more C; one or more A and one or more C; and one or more A, one or more B, and one or more C. Similarly, “multiple” (and its variations) and “or” used to separate the list of listed elements indicate options of multiple instances of any or all of the listed elements. For example, the phrases “multiple of A, B, or C” and “two or more of A, B, or C” indicate options such as: A and B; B and C; A and C; and A, B, and C.

[0182] As used herein, unless otherwise limited or defined, "substantially identical" means that features or components are manufactured according to the same design and the same specifications using the same processes. In some cases, substantially identical features may be geometrically identical.

[0183] In some implementations, the devices or systems disclosed herein may be utilized, manufactured, or installed using methods embodying aspects of the invention. Accordingly, any description herein of a particular feature, capability, or intended purpose of a device or system is generally intended to include methods of using such a device for its intended purpose, methods of otherwise realizing such capabilities, methods of manufacturing related components of such a device or system (or the entire device or system), and methods of installing disclosed (or otherwise known) components to support those purposes or capabilities. Similarly, unless otherwise indicated or limited, the discussion herein of any methods of manufacturing or using a particular device or system (including installing the device or system) is intended to inherently include the disclosure of the features and capabilities used as embodiments of the invention.

[0184] The foregoing description of the disclosed embodiments is intended to enable any person skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not intended to be limited to the embodiments shown herein, but should be given the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A communication method for devices within a control system, the control system comprising a plurality of devices communicating with a management system, the method comprising: The first Modbus packet is received from the management system via a communication line through an edge module connected to the device. The first Modbus packet includes: A block write command to the first contiguous register array of the edge module, the first contiguous register array of the edge module being collectively designated as a command buffer, wherein the block write command corresponds to a request for the device to perform an action, and A block read command for the second contiguous register array of the edge module, wherein the second contiguous register array of the edge module is collectively designated as a response buffer; The edge module interprets the request based on data in the command buffer, including determining the registers of the device associated with the request; The edge module generates and sends a second Modbus packet, the second Modbus packet including a command to a determined register of the connected device for the device to perform the action; and The edge module writes data into a response buffer based on the action performed by the device, for the management system to read.

2. The method of claim 1, further comprising the edge module storing operational data from the device in local memory for data recording.

3. The method of claim 1, wherein the edge module operates in a conversion mode, wherein the device retains autonomous operation control, and the edge module translates commands from the management system into configuration changes for the device to perform the action.

4. The method of claim 1, wherein the edge module operates in an overlay mode, wherein the edge module translates commands from the management system into direct control commands for the device's resources so that the device can perform the action.

5. The method according to claim 1, wherein the communication line is a wireless communication line.

6. The method of claim 1, further comprising the edge module directly reading sensor inputs and controlling relay outputs associated with the device.

7. The method of claim 1, wherein the edge module is a first edge module; and further comprising the first edge module communicating with a second edge module, the second edge module being connected to the device in a configuration redundant with the first edge module, wherein one of the first edge module and the second edge module operates as an active edge module to generate and send the second Modbus packet, and the other operates as a passive edge module.

8. The method of claim 7, further comprising the passive edge module monitoring the active edge module by monitoring the traffic between the active edge module and the management system.

9. The method of claim 8, further comprising, when it is determined during the monitoring period that the old active edge module has failed, the passive edge module becomes a new active edge module, and the active edge module becomes the old active edge module.

10. The method of claim 9, further comprising, when it is determined during the monitoring period that the old active edge module has failed, the new active edge module disables the old active edge module.

11. An edge module configured to connect between devices in a management system and an industrial system, the edge module comprising: Upstream serial port; Downstream serial port; A microcontroller includes a memory that stores program instructions and a processor that executes the program instructions to perform the following operations: Receive a first Modbus packet sent from the management system across the communication link to the upstream serial port. The first Modbus packet includes a multi-register write command to a first contiguous Modbus register array, which is designated as a command buffer. The multi-register write command is translated by mapping the Modbus register of the device associated with the multi-register write command; and A second Modbus packet is generated and transmitted via the downstream serial port. The second Modbus packet includes commands to the Modbus register of the mapped device.

12. The edge module of claim 11, further comprising flash memory in communication with the microcontroller, wherein the flash memory is configured to store operational data from the device for data logging operations.

13. The edge module of claim 11 further includes at least one wireless communication module, the wireless communication module being selected from a field area network module and a Bluetooth / Wi-Fi module, wherein the wireless communication module enables wireless communication with the management system, the device, other edge modules, remote devices, or a combination thereof.

14. The edge module of claim 11, further comprising a housing configured to be mounted on the outer surface of a casing, the housing comprising: The base is configured to be mounted against the outer surface; as well as The threaded neck extending from the base is configured to pass through an opening in the housing.

15. The edge module of claim 14, further comprising a top shell coupled to the base; and a wireless antenna structure coupled to the bottom side of the top shell.

16. The edge module of claim 15 further includes an indicator LED located within the housing, the indicator LED being configured to emit light to indicate the operating status of the edge module or the device.

17. The edge module of claim 16, wherein the indicator LED is located below a lens coupled to the top shell.

18. The edge module of claim 11 further includes a housing sized to be mounted on a DIN rail.

19. A method for an edge module to overlay a host device in an industrial control system, the method comprising: The type of host device is identified by probing the host device via the downstream port of the edge module to determine device information. The edge module maps the resources of the host device, wherein the mapping includes determining the register address of each resource; The edge module adjusts the host device to a passive state by disabling the automatic control mode; as well as In response to action commands from the management system, the edge module overrides the execution control of the host device by directly accessing and manipulating its resources.

20. The method of claim 19, wherein one of the resources comprises a relay; and the coverage includes implementing on / off control of the relay.

Images