Method and apparatus for controlling communication data rate of low energy devices

Abstract

Methods, apparatus, and articles of manufacture for controlling a communication data rate of a low energy device are disclosed. An exemplary apparatus includes: a Bluetooth Low Energy (BLE) radio; and a power manager for determining whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power source associated with the BLE radio and (2) a charging rate of the power source, and when the first computing task is to be performed by the BLE radio and the first computing task is divided based on the determination, instructing the BLE radio to enter a sleep mode after the second computing task is performed, and invoking the BLE radio to transition from the sleep mode to an operating mode to perform the third computing task, the invocation being responsive to a measurement result associated with the power source satisfying an energy threshold.

Description

[0001] Related Applications

[0002] This patent is a continuation-in-part of U.S. Patent Application Serial No. 16 / 144,748 filed on September 27, 2018, which claims the benefit of U.S. Provisional Patent Application Serial No. 62 / 567,051 filed on October 2, 2017. U.S. Patent Application Serial No. 16 / 144,748 and U.S. Provisional Patent Application Serial No. 62 / 567,051 are hereby incorporated by reference in their entirety. Priority is hereby claimed to U.S. Patent Application Serial No. 16 / 144,748 and U.S. Provisional Patent Application Serial No. 62 / 567,051. Technical Field

[0003] The present disclosure relates generally to process control systems and, more particularly, to methods and apparatus for controlling communication data rates of low energy devices. Background Art

[0004] Industrial communication protocols are implemented to manage industrial process control operations associated with field devices and other types of process equipment located in an industrial process control environment. Examples of such industrial communication protocols include the Highway Addressable Remote Transducer (HART) communication protocol, the PROFIBUS communication protocol, the FOUNDATION Fieldbus communication protocol, the MODBUS communication protocol, etc.

[0005] The Bluetooth Low Energy (BLE) communication protocol is implemented as a wireless personal area network communication protocol that facilitates wireless communication between BLE-compatible devices. Examples of such BLE-compatible devices typically include desktop computers, laptop computers, tablet computers, smartphones, and personal digital assistants (PDAs). Conventionally, data formatted according to the BLE communication protocol is incompatible with data formatted according to the above-mentioned industrial communication protocols. Summary of the invention

[0006] Methods and apparatus for controlling the communication data rate of low energy devices are disclosed herein. In some disclosed examples, an apparatus for managing the power profile of a network bridge of field devices in a process control environment is disclosed. The exemplary apparatus includes a Bluetooth Low Energy (BLE) radio device and a power manager, the power manager being used to: determine whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy associated with the BLE radio device stored in a power source and (2) a charging rate of the power source; and when the first computing task is executed by the BLE radio device and the first computing task is divided based on the determination, perform the following operations: after the second computing task is executed, instruct the BLE radio device to enter a sleep mode; and call the BLE radio device to transition from the sleep mode to an operating mode to perform the third computing task, the call being responsive to a measurement value associated with the power source satisfying an energy threshold.

[0007] In some disclosed examples, a non-transitory computer-readable storage medium including instructions is disclosed. The exemplary instructions, when executed, cause at least one processor of a network bridge of a field device in a process control environment to at least perform the following operations: determine whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power supply associated with a Bluetooth Low Energy (BLE) radio of the network bridge and (2) a charging rate of the power supply; and when the first computing task is executed by the BLE radio and the first computing task is divided based on the determination, perform the following operations: after the second computing task is executed, direct the BLE radio to enter a sleep mode; and call the BLE radio to transition from the sleep mode to an operating mode to perform the third computing task, the call being responsive to a measurement value associated with the power supply satisfying an energy threshold.

[0008] In some disclosed examples, a method for managing a power profile of a network bridge for field devices in a process control environment is disclosed. The exemplary method includes: determining whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power source associated with a Bluetooth Low Energy (BLE) radio of the network bridge and (2) a charging rate of the power source; and when the first computing task is executed by the BLE radio and the first computing task is divided based on the determination, performing the following operations: after the second computing task is executed, directing the BLE radio to enter a sleep mode; and invoking the BLE radio to transition from the sleep mode to an operating mode to perform the third computing task, the invocation being responsive to a measurement value associated with the power source satisfying an energy threshold. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a schematic diagram of an example environment including an example field device having an example network bridge to bridge communications between the field device and an example remote device via an example BLE connection in accordance with the teachings of the present disclosure.

[0010] Figure 2 According to the teachings of the present disclosure, Figure 1 An exemplary field device Figure 1 Another schematic diagram of an exemplary environment of Figure 1 The exemplary network bridge is used to bridge communications between the field device and first to third exemplary remote devices via the exemplary BLE connection.

[0011] Figure 3 yes Figure 1-Figure 2 A block diagram of an exemplary implementation of an exemplary network bridge.

[0012] Figure 4 is a block diagram of an example BLE communication path between an example remote device and an example field device.

[0013] Figure 5 is a block diagram of an exemplary implementation of an Attribute Protocol packet.

[0014] Fig. 6A is a block diagram depicting an example implementation of an example data packet based on an example BLE advertising data format.

[0015] Figure 6B is a block diagram depicting an exemplary implementation of an exemplary data packet based on an exemplary BLE advertising data format. Fig. 6A An exemplary BLE advertising data format is shown in FIG.

[0016] Figure 6C is a block diagram of an exemplary data packet based on an exemplary BLE extended advertisement data format.

[0017] Fig. 7A is a block diagram depicting an example implementation of an example data packet based on an example BLE scan response data format.

[0018] Figure 7B is a block diagram of an exemplary data packet based on an exemplary BLE scan response data format, the exemplary BLE scan response data format is based on Fig. 7A BLE scan response data format.

[0019] Fig. 8A is a block diagram of an exemplary data packet based on an exemplary BLE data channel packet format.

[0020] Figure 8B Describes the Figure 1-Figure 2 A block diagram of an exemplary industrial protocol data packet processed by a field device.

[0021] Figure 8C An exemplary concatenated set of HART frames is depicted.

[0022] Fig. 9A is a block diagram of an example implementation of an example manufacturer command profile and an example manufacturer command service.

[0023] Fig. 9B yes Fig. 9A An exemplary table of exemplary implementations of the manufacturer command service.

[0024] Fig. 9C yes Fig. 9A An exemplary table of another exemplary implementation of a manufacturer command service in which the transmit and receive data streams are separate.

[0025] Fig.10 is an exemplary table depicting exemplary attributes corresponding to exemplary characteristics of an exemplary manufacturer command service, wherein the characteristics include exemplary transmit characteristics and exemplary receive characteristics.

[0026] Fig.11 is an example table depicting example declaration attributes and example value attributes corresponding to characteristics of an example manufacturer command service, wherein the characteristics separate example transmit characteristics and example receive characteristics.

[0027] Fig.12is an exemplary table depicting exemplary declaration attributes, exemplary value attributes, and exemplary descriptor attributes corresponding to characteristics of an exemplary manufacturer command service, wherein the characteristics separate exemplary transmit characteristics and exemplary receive characteristics.

[0028] Fig.13A is an exemplary table depicting exemplary services corresponding to exemplary application program interface (API) commands.

[0029] Fig. 13B is an exemplary table depicting an exemplary format of an exemplary API command and an exemplary API response.

[0030] Fig.14 Describe the corresponding Figure 1-Figure 3 A first exemplary timing diagram of an exemplary radio device initialization task performed by an exemplary network bridge.

[0031] Fig.15 Describe the corresponding Figure 1-Figure 3 A second exemplary timing diagram of an exemplary radio device advertising task performed by an exemplary network bridge.

[0032] Fig.16 Describe the corresponding Figure 1-Figure 3 A third exemplary timing diagram of an exemplary data transmission task performed by an exemplary network bridge.

[0033] Fig.17 Depicted in an exemplary radio disable mode corresponding to Figure 1-Figure 3 A fourth exemplary timing diagram of an exemplary network bridge.

[0034] Fig.18 It is a depiction Figure 3 An exemplary table of exemplary power states for an exemplary power supply.

[0035] Fig.19 is plotted as a function of time Figure 3 An exemplary diagram of exemplary voltages of a power supply.

[0036] Fig. 20 is depicted as Figure 3 The charging rate of the power source is a function of Figure 1-Figure 3 An exemplary graph of exemplary data rates for an exemplary network bridge.

[0037] Fig.21 is an exemplary data flow diagram representing exemplary machine readable instructions that may be executed by Figure 1-Figure 3 An exemplary network bridge and / or more generally composed of Figure 1-Figure 3 The field device executes to perform one or more power management tasks.

[0038] Fig. 22 Depicted Figure 1-Figure 3 An exemplary state diagram of an exemplary network bridge.

[0039] Fig.23 Is the instruction that can be Figure 1-Figure 3 An exemplary network bridge performs to perform Figure 1-Figure 3 On-site equipment and Figure 1-Figure 3 A flow of exemplary machine-readable instructions for communicating between remote devices Figure 1-3 .

[0040] Fig.24 Is the instruction that can be Figure 1-Figure 3 The exemplary network bridge executes to call the platform manager to process Figure 1-Figure 3 A flow chart of example machine readable instructions for configuring a field device to receive data packets.

[0041] Fig.25 Is the instruction that can be Figure 1-Figure 3 A flow chart of example machine readable instructions that an example network bridge executes to identify a power assessment event.

[0042] Fig.26 Is the instruction that can be Figure 1-Figure 3 An exemplary network bridge performs to determine Figure 1-3 A flow chart of example machine readable instructions for configuring a mode of a field device.

[0043] Fig. 27 Is the instruction that can be Figure 1-Figure 3 A flow chart of example machine readable instructions executed by an example network bridge to perform power assessment and adjust parameters of a BLE radio device associated with the network bridge.

[0044] Figure 28A-28B Describes the instructions that can be Figure 1-3 The exemplary network bridge 104 performs to determine Figure 3 A flow chart of example machine readable instructions for controlling an example power state and adjusting parameters of a network bridge.

[0045] Fig.29 Is the instruction that can be Figure 1-Figure 3 A flow chart of example machine readable instructions that an example network bridge 104 executes to process one or more computing tasks based on a power budget.

[0046] Fig.30 Is the instruction that can be Figure 1 , Figure 2 and / or Figure 3 An exemplary remote device performs to perform Figure 1 , Figure 2 and / or Figure 3 A flow chart of example machine-readable instructions for communicating operations between an example field device and a remote device using BLE.

[0047] Fig.31 is constructed to execute Figure 21-Figure 29 Instructions to achieve Figure 1-Figure 3 A block diagram of an exemplary network bridge.

[0048] Fig.32 is constructed to execute Fig.30 Instructions to achieve Figure 1 , Figure 2 and / or Figure 3 A block diagram of an exemplary processor platform of an exemplary remote device.

[0049] The drawings are not drawn to scale. Generally, the same reference numerals will be used throughout the drawings and the accompanying written description to refer to the same or similar components. The connecting lines or connectors shown in the various figures presented are intended to indicate exemplary functional relationships and / or physical or logical couplings between the various elements.

[0050] Descriptors "first", "second", "third", etc. are used herein to identify multiple elements or components that can be referred to separately. Unless otherwise specified or understood based on the context of their use, such descriptors are not intended to impose any priority or time ordering, but are merely used as labels for referring to multiple elements or components separately to facilitate understanding of the disclosed examples. In some examples, the descriptor "first" can be used to refer to an element in the detailed description, while the same element can be referred to in the claims with different descriptors such as "second" or "third". In such cases, it should be understood that such descriptors are only used to facilitate reference to multiple elements or components. DETAILED DESCRIPTION

[0051] In recent years, Technology is increasingly used in industrial applications to facilitate communication between devices. Bluetooth is a wireless technology standard for exchanging data over short distances using short-wavelength ultra-high frequency radio waves in the Industrial, Scientific and Medical (ISM) radio band (e.g., 2.4 to 2.4835 GHz). Traditional methods of implementing Bluetooth in industrial applications such as process control systems include communicatively coupling an industrial protocol communicator such as a Highway Addressable Remote Transducer (HART) modem to a typical Bluetooth radio (e.g., a Bluetooth radio whose operation is based on Bluetooth Core Specification Version 5.0).

[0052] For example, a field device (e.g., a field device with sufficient power budget to operate a Bluetooth radio) can encapsulate HART information in a Bluetooth data packet and transmit the Bluetooth packet to a remote client, where the remote client receives information via a typical Bluetooth radio coupled to a main processor via bus communication. In such examples, a typical Bluetooth radio can transmit or receive information without considering the available power budget. As used herein, the terms "power accumulator" and "power budget" are used interchangeably and refer to a certain amount of electrical energy (e.g., based on a voltage, current, etc. and / or a combination thereof) that can be used by a component of a field device to perform an operation (e.g., a computing task, a process control operation, a BLE operation, a communication operation, etc.) at a specified rate. For example, a power budget may correspond to the amount of energy that can be used to perform an operation for a given or specified duration. In such an example, a remote client can use the entire allowable power budget to transmit information to increase the range and / or data throughput of a typical Bluetooth radio.

[0053] Typically, due to power budget limitations, standard Bluetooth radios have not been integrated into certain process control system field devices (e.g., valve positioners or other low-power instruments). For example, a valve positioner can operate under a power budget based on a 4-20 milliamp (mA) current loop provided by an external data acquisition and control system. In such an example, the valve positioner can utilize most of the available power budget to perform the main functions of the valve positioner (e.g., the main process control functions). In some examples, when the valve positioner utilizes most of the available power budget, power restrictions can be imposed on the standard Bluetooth radio. In some examples, the standard Bluetooth integrated circuit uses approximately 150 milliwatts (mW) of power to operate, while the exemplary power budget available for the potential Bluetooth interface on the valve positioner is less than 3mW. For example, there may not be enough energy in the power budget of the valve positioner for the standard Bluetooth radio to provide an effective communication path between the field device and another device (e.g., another field device, a remote device, etc.). As a result, based on the limited or limited power budget of the low-power field device, the standard Bluetooth radio may not be an ideal choice for the low-power field device to communicate with another device.

[0054] Bluetooth Low Energy (Bluetooth LE or BLE) is a wireless communication technology that operates within a communication or spectrum range of 2.4-2.4835GHz. For example, the BLE radio frequency (RF) channel is a subset of the classic Bluetooth channel. BLE is intended to provide significantly reduced power consumption and cost while maintaining a similar communication range. BLE is structurally different and incompatible with classic Bluetooth. For example, compared to classic Bluetooth, BLE uses a different set of channels. In such examples, BLE can have 40 2-MHz channels compared to 79 1-MHz channels of classic Bluetooth. In other examples, BLE does not support a serial port profile (SPP) for replacing a serial communication interface (e.g., RS-232 communication, RS-485 communication, etc.).

[0055] Examples disclosed herein use BLE to form a communication bridge between one or more low-power devices to improve communication interoperability, reduce the cost and complexity of performing communications, and increase the communication speed between devices. In some disclosed examples, a BLE bridge device facilitates one or more client devices (e.g., Emerson AMS TREX TM , mobile devices, etc.) and server devices (e.g., field devices, controllers, valve positioners, etc.). For example, a BLE bridge device can be coupled and / or communicatively coupled to a field device, such as a local controller, a headless controller (e.g., a PLC-type device), a valve positioner, a pressure transmitter, a temperature transmitter, a level transmitter, etc. For example, a BLE bridge device can be used to establish peer-to-peer communications with one or more client devices, one or more field devices, etc., and / or a combination thereof.

[0056] In some disclosed examples, a field device is communicatively coupled to one or more remote devices, such as an Emerson AMS Trex. For example, the remote device may include a computer running a standard operating system (e.g., Windows-based TM Operating systems, Apple Operating system, Android TM operating system, Process control related software applications operating on a processor (such as an operating system, etc.). In such examples, the remote device can communicate with the field device via BLE.

[0057] In some disclosed examples, the field device is communicatively coupled to one or more other field devices. For example, the field device can obtain information from one or more other field devices through an industrial communication protocol, and transmit the information to a remote device, a process control system, etc. through BLE or any other wired or wireless communication method. In some disclosed examples, the field device is communicatively coupled to one or more other field devices via a wired or wireless industrial communication protocol (e.g., HART communication protocol, WirelessHART (WiHART) communication protocol, PROFIBUS communication protocol, FOUNDATION Fieldbus communication protocol, or MODBUS communication protocol). In some disclosed examples, the field device is communicatively coupled to one or more other field devices via a wired or wireless industrial communication protocol and via BLE.

[0058] The examples disclosed herein improve communication interoperability between devices because the BLE bridge device can facilitate communication between (1) field devices using traditional industrial communication protocols and (2) remote devices via BLE. The examples disclosed herein reduce cost and complexity because the BLE bridge device can facilitate communication between field devices without requiring additional dedicated hardware to perform communication conversion and transmission (e.g., an external communication gateway device and corresponding hardware (e.g., power supply, circuit breaker, housing, etc.)).

[0059] The examples disclosed herein can be implemented in a software application layer above the physical hardware layer of a BLE radio device (e.g., a BLE transceiver). An exemplary BLE bridge device may include a software application layer corresponding to a software adaptation layer that can convert a standard supported industrial protocol into a compressed format or version for over-the-air (OTA) transmission. In an example where standard HART information is to be transmitted OTA, the software adaptation layer can remove unnecessary data (e.g., HART addresses, checksums, etc.), generate compressed or modified HART messages, and package the compressed HART messages into a BLE format for transmission. In an example where a compressed HART message is to be received OTA, the software adaptation layer can rebuild the HART message by adding back the previously removed HART address, checksum, etc. In such an example, one or both of the field device or the remote device may include a software adaptation layer.

[0060] Advantageously, the software adaptation layer can use standard industrial communication protocol messages, compress and / or otherwise modify the messages, and transmit the modified messages as standard BLE protocol data units (PDUs). Therefore, the standard industrial communication protocol data payload remains unchanged, so there is no need to develop custom software, personalized drivers, etc. for different hardware on different platforms. Therefore, the examples disclosed herein can improve the interoperability between remote devices and field devices because the remote devices can use any traditional industrial communication protocols, operating systems, BLE radio devices, etc. Compared to previous BLE systems, traditional BLE radio devices improve the operation of traditional operating systems and traditional BLE radio devices by providing additional functionality, communication interoperability, communication flexibility, etc.

[0061] In some disclosed examples, a BLE bridge device facilitates the transmission of information from a field device to a remote device. The field device may support an industrial communication protocol, such as the HART protocol. For example, the HART protocol defines a data packet structured based on the Bell 202 modem standard. Therefore, there is no need to send HART data packet support information (e.g., HART preamble, HART address, etc.) to the remote device via BLE. For example, the HART preamble is used for carrier detection and synchronization in accordance with the Bell 202 modem standard and does not need to be included in the BLE data packet because there is no Bell 202 modem to detect or synchronize. For example, the BLE bridge device may receive a HART protocol data packet from a field device, remove the HART protocol information from the HART protocol data packet, and transmit the payload data of the HART protocol data packet (e.g., only transmit the payload data) to the remote device via BLE. In such an example, the remote device may reconstruct the HART protocol data packet including the payload data, and transmit the reconstructed HART protocol data packet to an application operating on the remote device (e.g., an application that is expected and / or otherwise configured to obtain the HART protocol data packet).

[0062] In some disclosed examples, a BLE bridge device facilitates information transmission from a remote device to a field device. An exemplary BLE bridge device can identify one or more protocols supported by a field device. In response to receiving a receive request from a BLE radio device of a field device, the BLE bridge device determines whether the receive request corresponds to a protocol supported by the field device. In response to determining that the receive request corresponds to a supported protocol, the BLE bridge device approves the receive request and receives one or more data packets from the remote device. The exemplary BLE bridge device removes the BLE information from the received data packet, adds the supported protocol information (e.g., HART protocol preamble, HART protocol address, etc.) to the received data packet, and transmits the processed data packet to a microcontroller unit (MCU) of the field device via a universal asynchronous receiver-transmitter (UART) terminal, an internal integrated circuit (I2C) bus, a serial peripheral interface (SPI) bus, etc. For example, the MCU can be one or more processors that perform one or more process control operations of a field device (e.g., measuring valve position, transmitting information via an industrial communication protocol, etc.). In some disclosed examples, a BLE bridge device removes BLE information from a data packet received from a remote device and transmits the data packet to an MCU of a field device without adding supported protocol information to the data packet.

[0063] In some disclosed examples, receiving a data packet from a remote device with protocol information removed increases the data reception rate based on a limited power budget. For example, additional information (e.g., additional payload data) may be transmitted to a field device in place of protocol information. In such an example, the removed protocol information may be header data. For example, a header of a single data payload may be replaced with a single header, wherein an additional data payload may be concatenated to replace the removed header, thereby increasing the payload-to-header ratio of BLE communication. In some disclosed examples, transmitting a data packet to a remote device with protocol information removed increases the data transmission rate based on a limited power budget. For low-power field devices with limited available power budgets, an exemplary BLE bridge device may reduce the amount of non-data payload information such as protocol information to increase the data transmission rate between the field device and the remote device. By increasing the amount of payload information to be included in the data packet, the examples disclosed herein improve the efficiency of using a BLE radio device to perform improved data transmission between devices compared to existing BLE systems. Therefore, the examples disclosed herein are directed to one or more improvements to the functions of one or more processors associated with a BLE radio device, a field device, and / or a remote device.

[0064] In some disclosed examples, the BLE bridge device includes a power manager to facilitate the execution of computing tasks based on a power budget. In some disclosed examples, the power budget is substantially limited (e.g., limited to a power budget of 25 microjoules (μJ), 75μJ / s, 125μJ / s, etc. per second). For example, the BLE bridge device may be included in a field device operating in an explosive atmosphere, in which the power of electrical equipment is limited to prevent the generation of explosion-inducing sparks. In some disclosed examples, the power manager determines zero or more computing tasks (e.g., radio reception or transmission, device connection tasks, authentication and / or encryption tasks, etc.) to be performed by the BLE bridge device based on the available energy associated with the power budget. For example, the power manager can determine the amount of energy that can be consumed by the computing tasks in the computing queue and / or the time used to perform the computing tasks to determine the amount of computing tasks that can be completed based on the available power budget. In such an example, when a first threshold indicating that the BLE bridge device energy source has sufficient voltage or stored energy to perform one or more computing tasks is met, the power manager can determine one or more computing tasks that can be performed. In other examples, the power manager may determine that the computing task cannot be performed when a second threshold indicating that the BLE bridge device energy source has insufficient voltage or amount of stored energy is not met.

[0065] Figure 1 1 is a schematic diagram of an exemplary environment 100, which includes an exemplary field device 102 having an exemplary network bridge 104 (referred to herein as a BLE bridge 104, a BLE MCU 104, or a field device BLE MCU 104) to bridge communications between the field device 102 and an exemplary remote device 106 via an exemplary wireless connection 108 (referred to herein as a BLE network 108, a BLE connection 108, a BLE medium 108, etc.). The network bridge 104 may include one or more processors to perform computing tasks related to transmitting data via a BLE connection. For example, the network bridge 104 may include a first processor to perform a first computing task, such as generating a BLE data packet. In such an example, the network bridge 104 may include a second processor (e.g., a BLE radio processor) to perform a second computing task, such as transmitting a BLE packet to a different device. In the illustrated example, the field device 102 is coupled to a fluid flow control assembly 110 operating in a process control environment 112. The fluid flow control assembly 110 of the illustrated example is a pneumatically actuated valve assembly. Alternatively, the fluid flow control assembly 110 may be any other type of process control related assembly (eg, an electrically actuated valve assembly, a hydraulically actuated valve assembly, a motor, a pump, etc.).

[0066] exist Figure 1In the example shown, the housing 114 is coupled to a fluid flow control assembly 110, which includes at least an actuator 116 and a valve 118 (e.g., a butterfly valve, a globe valve, etc.). Although the BLE bridge 104 is included in the housing 114 in the example shown, the BLE bridge 104 may alternatively be located elsewhere (e.g., external to the housing 114, in a housing separate from the housing 114, etc.). The actuator 116 of the example shown is activated by a change in pneumatic pressure from the pneumatic tube connection 120. Alternatively, the actuator 116 may be activated by an electrical signal from an electrical connection, a change in hydraulic flow from a hydraulic tube connection, etc.

[0067] exist Figure 1 In the example shown, the field device 102 is a valve controller. Alternatively, the field device 102 can be a controller (e.g., a local single-loop process controller), a pressure transmitter, a temperature transmitter, a level transmitter, a pH transmitter, a valve positioner, etc. The field device 102 of the example shown controls, measures, and / or monitors one or more process control operations associated with the fluid flow control assembly 110. For example, the field device 102 can be implemented to control, measure, and / or monitor the operation of an actuator 116 operatively coupled to a valve 118 and transmit information corresponding to the operation to an external device such as a remote device 106. In such an example, the controller can control the operation of the actuator 116 and / or the position of the valve 118 (e.g., the degree to which the valve is opened or closed by the actuator 116).

[0068] exist Figure 1 In the example shown, the field device 102 controls, measures and / or monitors one or more process control operations associated with the fluid flow control assembly 110 (e.g., process control operations of opening the valve 118, calibrating the valve 118, closing the valve 118, etc.) based on data (e.g., control commands, control signals, etc.) formatted according to the industrial communication protocol and transmitted to and / or from the field device 102 through the industrial communication network. In some examples, the industrial communication protocol can be one of the HART communication protocol, the PROFIBUS communication protocol, the FOUNDATION Fieldbus communication protocol, or the MODBUS communication protocol. Alternatively, any other industrial communication protocol can be used.

[0069] exist Figure 1 In the example shown, the field device 102 communicates with the remote device 106 via a BLE connection 108 using a BLE bridge 104. Figure 1In some examples, the exemplary antenna 122 is embedded and / or otherwise coupled to a panel (e.g., a front panel, a side panel, etc.) of the field device 102 (e.g., in the front panel of the housing 114). Alternatively, the antenna 122 can be coupled to any other location of the field device 102. In some examples, the field device 102 transmits field device information (e.g., process control parameters corresponding to the fluid flow control assembly 110) to the remote device 106. Exemplary process control parameters may include actuator pressure, supply pressure, valve position, etc. In some examples, the field device 102 transmits field device information to the remote device 106, such as configuration information, diagnostic information, etc. of the field device 102. Exemplary configuration information, diagnostic information, etc. may include the identity of a logged-in user of the field device 102, an internal event log, a calibration version of the controller, a firmware version of the controller, a model of the fluid flow control assembly 110, etc. In some examples, the field device 102 transmits field device information to the remote device 106, such as alarm information. Exemplary alarm information may include calibration errors, missing position feedback alarms, low supply pressure alarms, security exceptions from non-BLE interfaces, security exceptions for ports using BLE radios, etc. Additionally or alternatively, any other field device information may be transmitted to the remote device 106 using the BLE bridge 104 .

[0070] In some examples, the remote device 106 transmits information to the field device 102 using the BLE bridge 104 via the BLE connection 108. For example, the remote device 106 can obtain configuration information from the field device 102, such as a firmware version associated with the controller (e.g., BLE MCU firmware, field device MCU firmware, etc.). In response to the remote device 106 determining that the firmware version of the BLE MCU firmware, the field device MCU firmware, etc. is not the current version, the remote device 106 can download the current version of the firmware to the field device 102 via the BLE connection 108. In other examples, the remote device 106 can configure one or more parameters associated with the fluid flow control assembly 110 via the BLE connection 108. For example, the remote device 106 can adjust the overpressure alarm setting, the measurement parameter unit, the process control variable minimum and / or maximum range setting, etc. of the field device 102 to control, measure, and / or otherwise monitor the fluid flow control assembly 110.

[0071] Performing such actions wirelessly via the BLE connection 108 reduces the complexity of performing operations (e.g., maintenance operations, technician operations, user operations, etc.) on and / or otherwise associated with the fluid flow control assembly 110. For example, without the BLE connection 108, a hotwork permit may need to be obtained to open the housing 114 to access the controller. In other examples, it may be necessary to shut down process control operations in the process control environment 112 before performing work on the field device 102 to prevent potential electric sparks from causing explosions in a hazardous atmosphere environment. In other examples, when the field device 102 is resealed, the water ingress protection of the field device 102 may be compromised. The BLE bridge 104 reduces the complexity of performing operations by facilitating communication between the field device 102 and the remote device 106 via the BLE connection 108.

[0072] Figure 2 Yes Figure 1 Field device 102 Figure 1 Another schematic diagram of an environment 100, the field device 102 having Figure 1 The BLE bridge 104 is used to bridge the communication between the exemplary remote devices 200, 202, 204 including the remote device 1 200, the remote device 2 202 and the remote device 3 204. Figure 2 In the embodiment, the BLE bridge 104 is processing (e.g., capable of processing, capable of processing simultaneously, etc.) one or more BLE communication connections between the field device 102 and the remote devices 1-3 200, 202, 204. For example, the field device 102 can transmit field device information to one or more of the remote devices 1-3 200, 202, 204 and / or receive information (e.g., firmware executable files, configuration settings, etc.) from one or more of the remote devices 1-3 200, 202, 204. Figure 2 , the BLE bridge 104 communicates with remote device 1 200 via a first BLE connection 108a, communicates with remote device 2 200 via a second BLE connection 108b, and communicates with remote device 3 204 via a third BLE connection 108c. Figure 2 Only remote devices 1-3 200, 202, 204 are depicted, but fewer or more remote devices 1-3 200, 202, 204 may be used.

[0073] exist Figure 2 In the example shown, the field devices 102 are communicatively coupled to a distributed control system (DCS) 206. For example, the DCS 206 may include one or more data acquisition and control systems including one or more controllers. Figure 2The field device 102 is communicatively coupled to the DCS 206 via an exemplary connection 208. Figure 2 In the embodiment of the present invention, the connection 208 is a cable including one or more wires. Additionally or alternatively, the field device 102 can be connected to the DCS 206 via a wireless connection. For example, the field device 102 can be connected via a wireless communication protocol corresponding to a WirelessHART (WiHART) connection, a Wi-Fi The connection 208 of a network connection, the like, and / or a combination thereof communicates with the DCS 206. Alternatively, the field device 102 may communicate with one or more of the remote devices 1-3 200, 202, 204 via the BLE bridge 104 without being communicatively coupled to the DCS 206.

[0074] exist Figure 2 In the example shown, the field device 102 is communicatively coupled to a pressure transmitter 210 via a wireless connection 212. For example, the pressure transmitter may be a ROSEMOUNT TM 3051S Wireless Differential Pressure Flow Transmitter. Alternatively, the pressure transmitter 210 may be any other type of field device, such as a flow rate transmitter, a temperature transmitter, a valve positioner, etc. The wireless connection 212 of the example shown is a WiHART connection. Alternatively, any other wireless connection may be used. Figure 2 In the embodiment of the present invention, the field device 102 transmits information to the pressure transmitter 210 and receives information from the pressure transmitter 210. For example, the pressure transmitter 210 can transmit information (e.g., pressure measurements, diagnostics of the pressure transmitter 210, configuration parameters of the pressure transmitter 210, etc.) to the field device 102. In other examples, the field device 102 can transmit information (e.g., requests for field device information, configuration information, etc.) to the pressure transmitter 210.

[0075] Figure 3 yes Figure 1-Figure 2 Field device 102 Figure 1-Figure 2 A block diagram of an exemplary implementation of the BLE bridge 104 is shown in FIG. Figure 3 In the BLE bridge 104, the BLE MCU includes one or more processors that execute machine-readable instructions, which, when executed, cause the one or more processors to perform one or more computing tasks. Figure 3In the example, the BLE bridge 104 includes an exemplary receiver transmitter (RX / TX) interface 300, an exemplary input / output interface 310, an exemplary platform manager 320, an exemplary Bluetooth low energy (BLE) stack handler 330, an exemplary database 335, and an exemplary BLE interface 340. The platform manager 320 of the illustrated example includes an exemplary command processor 322, an exemplary protocol handler 324, an exemplary power manager 326, and an exemplary security manager 332. Figure 3 , the protocol handler 324 includes an exemplary RX / TX interface handler 328. Also shown are an exemplary field device MCU 350, an exemplary power supply 355, an exemplary remote device 360, and an exemplary BLE wireless connection 370 (e.g., referred to herein as a BLE network 370, a BLE communication medium 370, a BLE connection 370, etc.).

[0076] exist Figure 3 In the illustrated example of , the BLE bridge 104 is an MCU for performing and / or otherwise facilitating communication operations between the field device MCU 350 and an external BLE compatible device such as the remote device 360. Figure 3 In the present invention, the field device MCU 350 is an MCU that includes one or more processors that execute machine-readable instructions, which, when executed, cause the one or more processors to perform one or more computing tasks. Figure 3 The remote device 360 ​​may correspond to Figure 1 remote device 106, Figure 2 One or more of the remote devices 1-3 200, 202, 204, and / or a combination thereof. The BLE interface 340 of the illustrated example facilitates BLE communication via a BLE connection 370. Figure 3 The BLE connection 370 may correspond to Figure 1 BLE connection 108 and / or Figure 2 BLE connections 108a-c. The BLE bridge 104 of the illustrated example is included in the field device 102. Alternatively, the BLE bridge 104 may not be included in the field device 102, wherein the BLE bridge 104 is communicatively coupled to the field device 102 via a cable or other communication means. In some examples, the field device MCU 350 transmits data packets to the BLE bridge 104 in a format (e.g., a data format) defined by an industrial communication protocol supported by the field device 102. For example, the field device 102 may support the HART protocol. In such an example, the field device MCU 350 may transmit data packets to the BLE bridge 104 via the receiver transmitter interface 300 and / or the input / output interface 310 in the HART protocol format.

[0077] exist Figure 3In the example shown, the BLE bridge 104 includes a receiver transmitter interface 300 to allow communication between the BLE bridge and the field device MCU 350. For example, the receiver transmitter interface 300 can facilitate inter-processor communication (IPC) corresponding to information exchanged between one or more processors of the field device MCU 350 and one or more processors of the BLE bridge 104. The receiver transmitter interface 300 of the example shown is a UART. For example, the receiver transmitter interface 300 can transmit information to the field device MCU 350 and / or receive information from the field device MCU 350 using an industrial communication protocol (e.g., a HART communication protocol, a PROFIBUS communication protocol, a WiHART communication protocol, etc.). Alternatively, the receiver transmitter interface 300 can be an I2C bus, an SPI bus, or other similar interfaces between integrated circuits (e.g., microcontrollers, processors, etc.).

[0078] exist Figure 3 In the example shown, the BLE bridge 104 includes an input / output interface 310 to allow and / or otherwise facilitate communication between the BLE bridge 104 and the field device MCU 350. The input / output interface 310 of the example shown corresponds to one or more analog-to-digital converters. For example, the input / output interface 310 can transmit a current signal, a voltage signal, etc. corresponding to information obtained from the remote device 360 ​​to the field device MCU 350. In other examples, the input / output interface 310 can obtain a current signal, a voltage signal, etc. from the field device MCU 350. In other examples, the input / output interface 310 can transmit a current signal, a voltage signal, etc. associated with the power supply 355 to the power manager 326. Alternatively, the exemplary input / output interface 310 can be a general purpose input / output (GPIO) interface or any other type of input / output interface.

[0079] exist Figure 3 In the example shown, the BLE bridge 104 includes a platform manager 320 to analyze and generate commands, convert data packets based on identified protocols and security measures, and / or manage the power budget of the BLE bridge 104. Figure 3In the embodiment, the platform manager 320 includes a command processor 322 to determine and direct communication operations based on the direction of the data stream. In some examples, the command processor 322 is a command controller corresponding to and / or otherwise associated with one or more processors of the BLE bridge 104 that can execute machine-readable instructions. For example, the command controller can be implemented by one or more processors that can execute machine-readable instructions. In some examples, the command processor 322 identifies one or more supported protocols of the field device 102. For example, the command processor 322 can determine that the field device 102 supports the HART communication protocol and the PROFIBUS communication protocol. In such an example, the command processor 322 can determine the supported protocols by querying the field device MCU 350, by querying the database 335, etc. For example, the command processor 322 can determine the supported protocols in response to querying the field device MCU 350. In such an example, the command processor 322 can store information (e.g., an identifier or value corresponding to the identified supported protocol) in the database 335 for future retrieval by the command processor 322. In other examples, the command processor 322 may determine the supported protocols based on querying fixed or hard-coded parameters stored in the database 335 that correspond to the protocols supported by the field device 102 .

[0080] In some examples, the command processor 322 determines the direction of the data flow based on the master-slave communication model. For example, the command processor 322 may determine that the data packet corresponds to a transmission request from the receiver transmitter interface 300 (e.g., a notification is transmitted from the device to the master device). In such an example, the command processor 322 may direct the data packet to be processed and transmitted from the receiver transmitter interface 300 to the BLE stack handler 330. In other examples, the command processor 322 may determine that the data packet corresponds to a request to receive from the BLE interface 340 (e.g., the master device transmits a data packet to the slave device without requiring a response from the slave device). In such an example, the command processor 322 may direct the data packet to be processed and transmitted from the BLE interface 340 to the receiver transmitter interface 300.

[0081] In some examples, the command processor 322 evaluates read and write BLE requests based on security information (e.g., security permissions, security rules, etc.). For example, the command processor 322 may determine to authorize the receive request based on comparing the operation code (opcode) (e.g., data field, data parameter, etc.) of the receive request with the authorized operation code list. In such an example, the command processor 322 may receive a data packet associated with the receive request and transmit the data packet to the security manager 332 for decryption. In other examples, when the command processor 322 determines that the operation code is not authorized, the command processor 322 may refuse to receive the request. For example, an unauthorized operation code may indicate that a computing device that transmits information to the field device 102 through the BLE bridge 104, a user associated with the computing device, etc. is not allowed to access information on the field device 102, change information on the field device 102, etc.

[0082] In some examples, the command processor 322 performs a communication operation of the BLE bridge 104 based on determining whether the value of the operation code corresponds to a specific industrial communication protocol. For example, the command processor 322 can determine that the value of the operation code corresponding to the receive request at the BLE interface 340 corresponds to the HART protocol. The command processor 322 can determine that the field device 102 supports the HART protocol. In such an example, the command processor 322 can direct the BLE interface 340 to receive information from the remote device 360, wherein the direction is based on the command processor 322 comparing the protocol indicated by the operation code value with the protocol supported by the field device 102. In some examples, the command processor 322 rejects the receive request by determining that the protocol indicated by the operation code value does not match the protocol supported by the field device 102. In some examples, the command processor 322 directs the processing of data packets received from the field device MCU 350 and / or the remote device 360 ​​by calling the protocol handler 324 and / or the security manager 332 to perform one or more operations associated with the data packets.

[0083] In some examples, command processor 322 processes radio specific commands. For example, command processor 322 may process the following in conjunction with Figure 13A-13BThe command described. For example, the command processor 322 can instruct the BLE stack handler 330 to adjust or change the transmit power level of the BLE interface 340 in response to processing a radio-specific command. For example, the command processor 322 can instruct the BLE stack handler 330 to reduce the transmit power level of the BLE interface 340 to save power. In other examples, the command processor 322 can instruct the BLE stack handler 330 to increase the transmit power level of the BLE interface 340 to increase the transmission range of the BLE interface 340. In some examples, when the command processor 322 detects that there is a problem with the existing radio frequency of the BLE interface 340, the command processor 322 processes the radio-specific command by executing a filter (e.g., a notch filter). In some examples, the command processor 322 processes the radio-specific command by completely shutting down the BLE interface 340 to enter a complete radio silence mode.

[0084] exist Figure 3 In the example shown, the platform manager 320 includes a protocol handler 324 to perform and / or otherwise facilitate communication operations based on the direction of the data flow between the field device MCU 350 and the remote device 360. In some examples, the protocol handler 324 is a protocol controller corresponding to and / or otherwise associated with one or more processors of the BLE bridge 104 capable of executing machine-readable instructions. For example, the protocol controller can be implemented by one or more processors capable of executing machine-readable instructions. In some examples, the protocol handler 324 performs communication operations based on the data flow from the field device MCU 350 to the BLE bridge 104. In such an example, the protocol handler 324 can determine whether the data packet for transmission is the first data packet for the communication session. In response to determining that the data packet is the first data packet of the communication session, the protocol handler 324 can read and store the protocol address (e.g., HART protocol address, PROFIBUS address, etc.), the protocol header (e.g., HART header, PROFIBUS header, etc.), and the like. In response to determining that the data packet is not the first data packet of the communication session, protocol handler 324 may remove the protocol address from the protocol data packet.

[0085] In some examples, the protocol handler 324 includes the protocol address in the data packet to be transmitted to the remote device 360 ​​for industrial communication protocol data packet reconstruction. For example, the first data packet to be transmitted to the remote device 360 ​​may include the protocol address that the remote device 360 ​​can use for future communication operations. Alternatively, the remote device 360 ​​can transmit a read request to the field device 102, wherein the read request includes an operation code corresponding to the protocol specific address. Alternatively, the protocol handler 324 can define a first operation code for returning a HART message with an address and a second operation code for returning a HART message without an address. For example, the remote device 360 ​​can transmit a data packet including a first operation code so that the field device 102 returns a HART message with the address of the field device 102. In such an example, the protocol handler 324 can remove protocol information (e.g., HART preamble, message integrity check, etc.), and insert the HART address into the data payload of the data packet to be transmitted to the remote device 360 ​​for data packet reconstruction.

[0086] In some examples, the protocol handler 324 removes protocol information (e.g., header data, checksum, etc.) from the data packet before transmitting the data packet via the BLE interface 340. For example, the field device MCU 350 can transmit a HART5 formatted data packet to the protocol handler 324. In such an example, the protocol handler 324 can remove HART 5 protocol information (e.g., HART 5 protocol preamble, HART 5 protocol address, HART 5 message integrity check, etc.) from the HART 5 formatted data packet. In response to removing the protocol information from the data packet, the protocol handler 324 can concatenate the payload data, wherein the concatenated payload data can replace the removed protocol information. For example, instead of transmitting a first header and a first payload data, a second header and a second payload data, etc., the protocol handler 324 can generate a concatenated data packet including a first header, a first payload data, and a second payload data without including a second header. In response to removing the protocol information from the data packet, the protocol handler 324 can call the security manager 332 to encrypt the data packet. In response to the data packet being encrypted, the security manager 332 may direct the BLE stack handler 330 to generate a BLE data packet (eg, a BLE PDU) based on the encrypted data packet and transmit the BLE data packet via the BLE interface 340 .

[0087] In some examples, the protocol handler 324 adds protocol information based on the protocol supported by the field device 102, such as a protocol preamble, a protocol address, a protocol message integrity check, etc. For example, the BLE interface 340 can receive a BLE data packet including an operation code corresponding to the HART 7 protocol from the remote device 360. In such an example, the security manager 332 can decrypt the BLE data packet (e.g., extract and decrypt the data payload contained in the BLE data packet) and transmit the decrypted data packet to the protocol handler 324. The protocol handler 324 can add HART 7 protocol information (e.g., HART 7 protocol preamble, HART 7 protocol address, HART 7 message integrity check, etc.) to the decrypted data packet to generate an industrial protocol formatted data packet. In response to generating the industrial protocol formatted data packet, the protocol handler 324 can instruct the receiver transmitter interface 300 to transmit the formatted industrial protocol to the field device MCU 350.

[0088] In some examples, the protocol handler 324 performs communication operations based on the data flow from the remote device 360 ​​to the BLE bridge 104. For example, the protocol handler 324 can determine whether the data packet received at the BLE interface 340 is valid or correctly formed (e.g., has valid syntax), formatted, etc. In such an example, the protocol handler 324 can protect the field device MCU 350 from intentionally malformed data or partially malformed data (e.g., fuzz testing) by determining whether the data packet is correctly formed.

[0089] In some examples, the protocol handler 324 determines whether the data packet is a conforming data packet and / or is otherwise a correctly formed data packet based on evaluating the industrial protocol command. For example, the protocol handler 324 can receive a data packet including an industrial protocol command. In such an example, the protocol handler 324 can determine whether the industrial protocol command is valid (e.g., the received HART command 0 is valid) or invalid (e.g., the received HART command 255 is invalid). The protocol handler 324 can (1) accept the data packet based on verifying that the industrial protocol command is valid or (2) reject the data packet based on not verifying that the industrial protocol command is valid.

[0090] In some examples, the protocol handler 324 determines whether the data packet is correctly formed based on the data length (e.g., number of bytes) corresponding to the industrial protocol command by evaluating. For example, the protocol handler 324 can receive the data packet of the industrial protocol command including the corresponding data length of 8 bytes. In such an example, the protocol handler 324 can determine that the industrial protocol command is correctly formed by a maximum of 6 bytes. The protocol handler 324 can compare the received 8 byte data length with the 6 bytes correctly formed length defined, and determine that the data packet is not correctly formed based on the comparison result. In such an example, the protocol handler 324 can reject the data packet and / or transmit an error code to the transmitter (e.g., remote device 360) of the data packet based on determining that the data packet is not correctly formed.

[0091] In some examples, the protocol handler 324 determines whether the data packet is correctly formed based on evaluating the range of parameter values ​​included in the data packet. For example, the protocol handler 324 may receive a data packet including a valve position set point parameter value of 2000%. In such an example, the protocol handler 324 may determine that the valve position set point parameter is defined by a range of 0 to 100% to be correctly formed. The protocol handler 324 may compare the received range of 2000% with the defined correctly formed range of 0 to 100%, and determine based on the comparison result that the data packet is not correctly formed. In such an example, the protocol handler 324 may reject the data packet and / or transmit an error code to the transmitter of the data packet (e.g., remote device 360) based on determining that the data packet is not correctly formed.

[0092] exist Figure 3In the example shown, the protocol handler 324 includes an RX / TX interface handler 328 to handle communication operations between the field device MCU 350 and the BLE interface 340. In some examples, the RX / TX interface handler 328 is an RX / TX interface controller corresponding to and / or otherwise associated with one or more processors of the BLE bridge 104 capable of executing machine-readable instructions. For example, the RX / TX controller may be implemented by one or more processors capable of executing machine-readable instructions. In some examples, the RX / TX interface handler 328 receives data packets from the receiver transmitter interface 300 and / or the input / output interface 310 and transmits the data packets to the BLE interface 340 via the BLE stack handler 330. For example, the RX / TX interface handler 328 may include a TX buffer to obtain data packets specified to be transmitted to the BLE interface 340 from the field device MCU 350. In some examples, the RX / TX interface handler 328 receives data packets from the BLE interface 340 and transmits the data packets to the field device MCU 350. For example, the RX / TX interface handler 328 may include an RX buffer to obtain data packets from the BLE interface 340 destined for transmission to the field device MCU 350. The BLE interface 340 and field device MCU 350 of the illustrated example support UART, I2C, SPI, and / or other similar integrated circuit communication protocols.

[0093] exist Figure 3In the example shown, the platform manager 320 includes a power manager 326 to determine the mode of the field device 102, perform a power assessment of the available power budget of the BLE bridge 104, and / or adjust one or more parameters of the BLE interface 340 based on a power assessment event. In some examples, the power manager 326 is a power controller corresponding to and / or otherwise associated with one or more processors of the BLE bridge 104 capable of executing machine-readable instructions. For example, the power controller can be implemented by one or more processors capable of executing machine-readable instructions. In some examples, the power manager 326 can direct, instruct, call, etc., different components of the platform manager 320 (e.g., the security manager 332, the command processor 322, the protocol handler 324, the RX / TX interface handler 328, etc.), and / or more generally, the BLE MCU 104 (e.g., the RX / TX interface 300, the input / output interface 310, the BLE stack handler 330, etc.) to perform computing tasks by generating one or more threads (e.g., computing threads, processor threads, etc.) for execution by one or more processors of the BLE MCU 104. In such an example, one or more processors of the BLE MCU 104 can perform computing tasks by executing threads. For example, the power manager 326 can call the security manager 332 to perform a security task or operation by generating a thread associated with a security task. In such an example, the security manager 332 can perform a security task by executing a thread.

[0094] exist Figure 3 In the example shown, the power manager 326 manages the power profile of the BLE bridge 104. For example, the power profile may correspond to a power budget allocated to the BLE bridge 104, a power dissipation rate of the BLE bridge 104, etc. In some examples, the power manager 326 directs the input / output interface 310 to measure a parameter of the power source 355 and generates a request to the field device MCU 350 to adjust the power delivery of the power source 355 based on the measured parameter. In some examples, the power manager 326 determines the mode of the field device 102 by querying the database 335, the field device MCU 350, etc. For example, the mode may be a standard operating mode, a maintenance mode, a safety mode (e.g., a security mode), etc. For example, the power manager 326 may determine that the field device 102 is in a maintenance mode based on information obtained from the field device MCU 350, information in the database 335, etc.

[0095] In some examples, the power manager 326 determines that the field device 102 is in a secure mode based on information from the security manager 332, the database 335, the field device MCU 350, etc. In such examples, the power manager 326 can disable write access to one or more field device parameters. For example, the power manager 326 can disable write access to firmware version values, serial number values, error log files, BLE interface parameters (e.g., BLE connection interval, BLE radio address, etc.) stored in the database 335, the field device MCU 350, etc.

[0096] In some examples, the power manager 326 requests additional current from the field device MCU 350 to charge the power supply 355. For example, when the field device 102 is in a maintenance mode or a different mode, the power manager 326 can request that additional current be provided to the power supply 355. In some examples, the field device MCU 350 adjusts the operation of the field device 102 to meet the request from the power manager 326 by providing additional current to the power supply 355. In other examples, because the field device 102 is operating in a mode (e.g., a standard operating mode) in which the field device MCU 350 cannot adjust the operation of the field device 102, the field device MCU 350 can deny the request from the power manager 326. In some examples, the field device MCU 350 directs the power manager 326 to reduce the power consumption of the BLE bridge 104. For example, the field device MCU 350 can generate a GPIO interrupt, a UART message, an SPI message, etc. to call the power manager 326 to transition to a power saving state. In such an example, the power manager 326 may transition from a first state in which a first number of computing tasks is executed to a second state in which a second number of computing tasks is executed, where the second number (eg, zero, one, or more computing tasks) is less than the first number.

[0097] exist Figure 3 In the example shown, the field device 102 includes a power supply 355 to provide power and / or otherwise facilitate operation of the field device 102 including the BLE bridge 104. For example, the power supply 355 can be electrically coupled to an external power source, a power supply that powers the field device MCU 350, etc. Figure 3 In the embodiment, the power source 355 is a current source. For example, the power source 355 can be a 0.25 mA current source of 3.8 VDC, a 0.5 mA current source of 3.8 VDC, etc., which provides input current to the BLE bridge 104.

[0098] exist Figure 3In the example shown, the power source 355 includes an exemplary energy storage device 356 to ensure continuous radio communication of the BLE interface 340 when needed. Alternatively, the power source 355 may include two or more instances of the energy storage device 356. Figure 3 In the embodiment of the present invention, the energy storage device 356 is a capacitor (eg, a storage capacitor). Alternatively, the energy storage device 356 may be a battery or any other type of energy storage device.

[0099] In some examples, the supply current (e.g., 0.15 mA, 0.25 mA, etc.) to the energy storage device 356 is less than the draw current (e.g., a current in the range of 3-15 mA) from the energy storage device 356. In such examples, when the energy storage device 356 is sufficiently charged (e.g., above an energy storage threshold, a voltage threshold, etc.), the power manager 326 can monitor the voltage of the energy storage device 356 to draw current. Figure 3 In the example, the power manager 326 obtains energy measurements associated with the power source 355 via the GPIO or analog-to-digital converter hardware included in the input / output interface 310. For example, the power manager 326 can obtain analog current values, analog voltage values, etc. In other examples, the power manager 326 can obtain digital values ​​(e.g., logical high values, logical low values, 0, 1, etc.) corresponding to the analog current values, analog voltage values. In some examples, the power manager 326 uses a filter (e.g., a Kalman filter) based on the input power (e.g., input current, input voltage, etc.) and / or output power (e.g., output current, output voltage, etc.) of the BLE bridge 104 and / or more generally the field device 102.

[0100] exist Figure 3 In the example shown, the power supply 355 includes example comparators (e.g., voltage comparators) 358a-b, which include a first example comparator 358a and a second example comparator 358b to determine the energy stored in the power supply 355 for the BLE bridge 104. For example, the comparators 358a-b can be used to determine the energy stored by the power supply 355 and / or otherwise include the stored energy in the power supply 355. Alternatively, the power supply 355 may include a comparator. Figure 3The power supply 355 includes comparators 358a-b to measure the voltage across the energy storage device 356 and / or otherwise associated with the energy storage device 356 to determine an indication of energy storage of the energy storage device 356. In some examples, the comparators 358a-b determine whether the voltage across the energy storage device 356 meets an energy threshold (e.g., a high energy threshold, a low energy threshold, etc.). In other examples, the comparators 358a-b determine whether the voltage across the energy storage device 356 meets a voltage threshold. For example, the voltage threshold can be a high voltage threshold, a low voltage threshold, etc.

[0101] exist Figure 3 In the example shown, the power supply 355 includes (1) a first comparator 358a for indicating whether the voltage of the energy storage device 356 meets a high voltage threshold and (2) a second comparator 358b for determining whether the voltage meets a low voltage threshold. In such an example, the first comparator 358a is a high voltage comparator capable of generating or outputting a first digital signal, and the second comparator 358b is a corresponding low voltage comparator capable of generating or outputting a second digital signal, wherein the first digital signal and the second digital signal can be measured and / or otherwise obtained by the input / output interface 310. For example, the first comparator 358a can compare the measured voltage of the energy storage device 356 with a high voltage threshold (e.g., 1.8V, 2V, etc.) corresponding to or otherwise converted to a high energy threshold (e.g., 350μJ, 380μJ, etc.). For example, when the high energy threshold is met, the power manager 326 can set the power budget or power accumulator to a known value (e.g., 350μJ, 380μJ, etc.). When the measured voltage meets the high voltage threshold, the first comparator 358a can assert a logic high (e.g., a voltage corresponding to a digital 1) signal as a first digital input signal to the input / output interface 310. When the measured voltage is greater than or equal to the high voltage threshold, the measured voltage can meet the high voltage threshold. In other examples, the second comparator 358b can compare the measured voltage with a low voltage threshold (e.g., 0.8V, 1V, etc.) corresponding to a low energy threshold (e.g., 140μJ, 180μJ, etc.). When the measured voltage meets the low voltage threshold, the second comparator 358b can assert a logic high signal as a second digital input signal to the input / output interface 310. When the measured voltage is greater than or equal to the low voltage threshold, the measured voltage can meet the low voltage threshold. In other examples, when the high voltage threshold is not met, the first comparator 358a can generate a logic low (e.g., a voltage corresponding to a digital 0) signal. In other examples, the second comparator 358b can generate a logic low signal when the low voltage threshold is not met.

[0102] In some examples, the high energy threshold indicates that the power supply 355 is able to provide sufficient power to the BLE bridge 104 to perform one or more computing tasks. For example, if the power manager 326 determines that the first comparator 358a has asserted a logic high signal, the power manager 326 may determine that the BLE bridge 104 can perform one or more computing tasks without depleting the power supply 355, and thus abruptly disconnect. In some examples, the low energy threshold indicates that the power supply 355 is able to provide sufficient power to the BLE bridge 104 to perform one or more computing tasks. For example, if the power manager 326 determines that the second comparator 358b has not asserted a logic high signal and thus the low energy threshold is not met, the power manager 326 may determine that the BLE bridge 104 cannot perform one or more computing tasks without depleting the power supply 355 and shut down prematurely during the execution of the one or more computing tasks (e.g., the BLE bridge 104 may brown out).

[0103] In some examples, the power manager 326 determines a state of the power source 355. For example, the power manager 326 can determine whether the power source 355 is in a first state, a second state, a third state, etc. based on assertions of the comparators 358a-b. For example, the state of the power source 355 can indicate an amount or level of energy stored by the energy storage device 356. In other examples, the state of the power source 355 can indicate an amount of computing tasks that can be performed before consuming or depleting a portion or all of the available energy associated with and / or otherwise corresponding to the state without causing the BLE bridge 104 to shut down, disconnect, etc. due to a lack of available energy.

[0104] In some examples, the power manager 326 may determine that the power source 355 is in a first state. The first state may correspond to the energy storage device 356 being fully charged or nearly fully charged (e.g., 90% charged, 95% charged, 99% charged, etc.). The power manager 326 may determine that the power source 355 is in the first state when the first comparator 358a asserts a logic high signal or when the first and second comparators 358a-b assert logic high signals. The first state may correspond to an ENERGY_STATE_HIGH power state (e.g., a HIGH-HIGH power state) in which the first comparator 358a and the second comparator 358b assert logic high signals. The first state indicates that the energy storage device 356 is fully charged or nearly fully charged. In the first state, the power supply 355 may facilitate a high-power, one-shot event, such as a radio frequency operation (e.g., the BLE interface 340 receives a BLE data packet, the BLE interface 340 transmits a BLE data packet, etc.), a non-volatile memory (NVM) flash erase (e.g., an NVM flash erase of the database 335 or a portion thereof), an NVM flash write (e.g., an NVM flash write to the database 335), or an asymmetric cryptographic calculation performed by the security manager 332. For example, the one-shot event may correspond to an energy commitment of the power supply 355 to provide a certain amount of energy to the BLE bridge 104 to perform a computing task associated with the one-shot event. In other examples, the one-shot event may correspond to a power commitment of the power supply 355 to provide a certain amount of energy to the BLE bridge 104 at a specified rate to perform a computing task associated with the one-shot event.

[0105] In some examples, the power manager 326 may determine that the power supply 355 is in a second state. The second state may correspond to the energy storage device 356 being less than (e.g., substantially less than) fully charged (e.g., 25% charged, 35% charged, 50% charged, etc.). The power manager 326 may determine that the power supply 355 is in the second state based on the non-assertion (or lack of assertion) of the first comparator 358a and the assertion of the second comparator 358b. The lack of assertion may correspond to generating a logic low signal as a digital input signal. The second state may correspond to an ENERGY_STATE_MEDIUM power state (e.g., a LOW-HIGH power state), which indicates that the voltage associated with the energy storage device 356 is less than fully charged but higher than the voltage level associated with the second comparator 358b. In the second state, the power supply 355 may facilitate high-speed data transmission, wherein the BLE bridge 104 operates at a specified data transmission rate until the second comparator 358b changes state (e.g., the output changes from a logic high value to a logic low value). In the second state, the power supply 355 may not have enough energy to support a single trigger event.

[0106] In some examples, the power manager 326 may determine that the power supply 355 is in a third state. The third state may correspond to the energy storage device 356 having an insufficient amount of stored energy (e.g., less than 120 μJ, 160 μJ, etc.) to perform one or more computing tasks, and therefore, the BLE bridge 104 needs to enter a sleep state before the BLE bridge 104 powers down due to insufficient power from the power supply 355. The power manager 326 may determine that the power supply 355 is in the third state based on the absence of assertions from the first comparator 358a and the second comparator 358b. The third state may correspond to an ENERGY_STATE_LOW power state (e.g., a LOW-LOW power state) indicating that the voltage across the energy storage device 356 has insufficient energy to support one or more functions of the BLE bridge 104. In the third state, the power manager 326 may direct the BLE bridge 104 to enter a sleep mode or a standby mode until the value of the first comparator 358a and / or the second comparator 358b changes. In such examples, the sleep mode or standby mode may correspond to examples where the BLE interface 340 is disabled and / or otherwise not performing radio frequency operations.

[0107] In some examples, the power manager 326 determines the input power (e.g., input current, input voltage, etc.) of the BLE bridge 104 during each cycle (e.g., each control cycle, every 100 milliseconds (ms), every 1 second, etc.). For example, the input power can correspond to the power delivered to the power supply 355 by the field device MCU 350. In some examples, the field device MCU 350 transmits information corresponding to the input power to the BLE bridge 104. For example, the field device MCU 350 can generate an SPI message and transmit it to the RX / TX interface 300. The RX / TX interface 300 can obtain the SPI message and write the first data (e.g., a machine-readable value, a hexadecimal value, a binary value, etc.) included in the SPI message to a memory. For example, the field device MCU 350 can set the SPI bus chip select value to a logic high, write the first data to the data buffer when the SPI bus chip select value is logic high, and set the SPI bus chip select value to a logic low after the first data has been written to the data buffer. The power manager 326 may retrieve the first data from the data buffer in response to a hardware interrupt that may be generated based on a SPI bus chip select value change value.

[0108] In some examples, the RX / TX interface 300 stores the first data in a data buffer included in the database 335. The power manager 326 can read the first data from the data buffer and determine a first charging rate of the power source 355 based on the first data in the data buffer, wherein the field device MCU 350, and / or more generally, the field device 102 can write the first data to the data buffer (e.g., via the RX / TX interface 300). For example, the first data can indicate that the field device MCU 350 is providing power and / or otherwise charging the power source 355 at a rate of 0.25 mW. In some examples, the power manager 326 determines a power budget associated with the BLE interface 340 based on the first charging rate. For example, the power manager 326 can determine the power budget based on (1) the stored energy indicated by at least one of the comparators 358a-b or (2) at least one of the first charging rates. In some examples, the field device MCU 350 adjusts the first charging rate to a second charging rate, wherein the second charging rate can be greater than or less than the first charging rate. For example, the field device MCU 350 may write second data different from the first data to the data buffer, wherein the second data indicates that the field device MCU 350 is charging the power source 355 at a rate of 0.5 mW. In response to the adjustment, the power manager 326 may adjust the power budget when the first charging rate is changed to the second charging rate when the field device MCU 350 writes the second data to the data buffer.

[0109] In some examples, the power manager 326 may compare the charging rate to a charging rate threshold and determine whether the charging rate satisfies the charging rate threshold based on the comparison result. For example, the power manager 326 may determine that the first charging rate is 0.25 mW based on the first data in the data buffer, compare the first charging rate to the charging rate threshold of 0.15 mW, and determine that the first charging rate satisfies the charging rate threshold because the first charging rate is greater than the charging rate. In such an example, the power manager 326 may identify a power assessment event based on the first charging rate satisfying the charging rate threshold. In other examples, the power manager 326 may identify a power assessment event in response to a change in data in the data buffer (e.g., in response to second data replacing first data, in response to second data being written to the data buffer, etc.).

[0110] In some examples, the power manager 326 performs a power assessment of the power source 355 and / or, more generally, a power assessment of the field device 102. The power assessment may correspond to the power manager 326 determining the current state, status, etc. of one or more components of the field device 102 (such as the BLE interface 340, the power source 355, etc.). For example, the power manager 326 may measure the amount of energy stored by the power source 355 and / or a power metric that may be provided by the power source 355. In other examples, the power manager 326 may identify the state, status, etc. of the BLE interface 340, including the energy consumption, power consumption, etc. of the BLE interface 340, the data transmission rate or data reception rate of the BLE interface 340, whether the BLE interface 340 is transmitting data packets, receiving data packets, etc., and / or a combination thereof. In some examples, the power manager 326 performs the power assessment by measuring the radio transmission rate of the BLE interface 340. For example, the power manager 326 may calculate a transmission rate (eg, radio transmission rate, instantaneous radio transmission rate (eg, calculate the transmission rate in bytes / second)) of the BLE interface 340 based on the number of bytes transmitted per second by the BLE interface 340 .

[0111] In some examples, the power manager 326 calculates a radio energy consumption (REC) value (e.g., a REC value measured in μJ) based on the radio transmission rate. For example, the power manager 326 can determine the amount of energy consumed to activate, enable, wake up, etc. the BLE interface 340. For example, the power manager 326 can determine an energy overhead value for the BLE interface 340, including power used to perform the following items: (1) execute machine-readable instructions or processes using the platform manager 320, the BLE stack handler 330, etc., (2) process data from the receiver transmitter interface 300, (3) encrypt data received from the receiver transmitter interface 300 using the security manager 332, (4) decrypt data received from the BLE interface 340, etc., and / or a combination thereof.

[0112] In some examples, the power manager 326 calculates the REC value without including the activation energy of the BLE interface 340 (e.g., the activation energy is calculated separately). For example, the power manager 326 can calculate the REC value based on (1) a first energy cost (EO) per byte of data (e.g., EO measured in mJ) multiplied by the number of bytes transmitted per connection interval (e.g., data interval), the connection interval being measured in seconds. For example, the power manager 326 can calculate the REC based on equation (1), as follows:

[0113]

[0114] In some examples, the power manager 326 calculates a REC value that includes the activation energy of the BLE interface 340. For example, the power manager 326 can calculate the REC based on the sum of (1) the first EO per byte of data multiplied by the number of bytes transmitted per connection interval and (2) the amount of energy per second (e.g., activation energy, startup energy, etc.) multiplied by the amount of time required for the BLE interface 340 to be activated (activation time). For example, the power manager 326 can calculate the REC based on equation (2), as follows:

[0115]

[0116] In some examples, the power manager 326 performs power assessment by determining the energy associated with the power supply 355 based on the values ​​generated by the comparators 358a-b, determining a power budget based on the determined voltage, and determining the number of zero or more computing tasks to be executed in the task queue based on the power budget. For example, the power manager 326 can determine that the power supply 355 has a voltage of 1.8V based on the first and second comparators 358a-b asserting a logic high signal obtained by the input / output interface 310. In such an example, the power manager 326 can determine a power budget of 380μJ because the measured 1.8V corresponds to 380μJ of energy stored by the energy storage device 356.

[0117] In some examples, the power manager 326 determines the available power budget of the power source 355 by determining the amount of power delivered to the power source 355 and by determining the amount of power used from the power source 355. For example, when the field device MCU 350 is providing power to the power source 355, the field device MCU 350 can assert a logic value (e.g., a logic high value) to be read by the power manager 326. In such an example, the power manager 326 can read data from the database 335 to determine the charging rate during the time period when the field device MCU 350 asserts the logic value. The power manager 326 can determine the amount of power delivered to the power source 355 using equation (3) as described below:

[0118] Energy input = power input * charging time

[0119] Equation (3)

[0120] In the illustrated example of equation (3) above, the power input may correspond to a predetermined rate of energy transfer value of 1 mW or any other value of the field device MCU 350. For example, the power manager 326 may determine that the field device MCU 350 provides an energy input of 10 μJ based on a power input value of 1 mW and a charging time of 10 ms. The power manager 326 may determine the amount of power being used from the power source using equation (4) as described below:

[0121] Energy output = power output * power consumption time

[0122] Equation (4)

[0123] In the illustrated example of equation (4) above, the power output may correspond to a predetermined rate of energy transfer value for a computing task to be performed by the field device MCU 350. For example, the power manager 326 may determine that the BLE interface 340 will transmit a BLE data packet for 10 ms and that a current of 1 mA at 3 V is required to perform the transmission. In such an example, the power manager 326 may determine that the amount of energy being used from the power source is 30 μJ (e.g., energy output = 30 μJ) based on the power output of 1 mA at 3 V for 10 ms. Thus, the power manager 326 may determine the power budget of the BLE MCU 104 based on the difference between the energy input and the energy output as described above in conjunction with equations (3) and (4).

[0124] In some examples, the power manager 326 obtains a task queue of one or more items, which may include authentication tasks, connection establishment tasks, encryption tasks, radio frequency tasks (e.g., radio transmission tasks, radio reception tasks, etc.), etc. The power manager 326 can allocate and / or otherwise determine the amount of energy that each task included in the task queue may consume when executed (e.g., energy consumption parameters, energy consumption values, etc.). For example, the power manager 326 can determine that the authentication task in the task queue can consume 80 μJ (i.e., has an energy consumption value of 80 μJ). In other examples, the power manager 326 can obtain the energy consumption value from the database 335. The power manager 326 can determine whether zero, one, or more tasks of the task queue can be executed based on the power budget. For example, the power manager 326 can determine the number of computing tasks to be executed in the task queue before converting the BLE MCU 104 to sleep mode to facilitate charging of the power supply 355.

[0125] In some examples, the power manager 326 performs a power assessment in response to a power assessment event. The power assessment event may include a change in the assertion or state of one or both of the comparators 358a-b, the passage of a timer, a sudden change in the power of the field device 102, a change in the amount of data to be transmitted by the field device 102, a change in the amount of data to be received from the remote device 360, a change in the charging rate, etc. In some examples, the power assessment event is a transition from a first comparator 358a and / or a second comparator 358b from generating a logic low signal to asserting a logic high signal. In some examples, the power assessment event is a transition from a first comparator 358a and / or a second comparator 358b from asserting a logic high signal to generating a logic low signal. In some examples, the power assessment event is a start-up of a BLE bridge 104, a field device 102, etc. In some examples, the power assessment event is an asynchronous trigger from a power manager 326, a computing device, a user via a computing device, an external device such as a remote device 360, etc. In some examples, the power manager 326 reads data from the database 335 indicating input power 350 to the power supply 355 corresponding to the output from the field device MCU when a power assessment event is detected and / or otherwise occurs.

[0126] In some examples, the power manager 326 determines the size of the requested communication operation. For example, the power manager 326 can calculate the number of data packets or the amount of data to perform a data transmission operation or a data reception operation. In some examples, the power manager 326 determines a data rate to support the size of the requested communication operation. For example, the power manager 326 can determine the data transmission rate to send the field device information from the BLE interface 340 to the remote device 360 ​​based on the available power budget of the BLE bridge 104, the time-based requirements for completing the communication operation, etc. In some examples, the power manager 326 calculates the maximum transmission rate based on the power assessment (e.g., the available power budget determined by the power assessment).

[0127] In some examples, the power manager 326 directs the BLE stack handler 330 to adjust the parameters of the BLE interface 340 based on the power assessment. In such examples, the BLE stack handler 330 can communicate with the connected device (e.g., Figure 1The power manager 326 may determine the adjustment of parameters such as the connection interval, the radio power level (e.g., the radio transmission power level, the radio reception power level, etc.), the payload size, the delay level (e.g., the delay level), etc., and / or a combination thereof, and direct the BLE stack handler 330 to implement the adjustment. In such an example, the power manager 326 may determine the adjustment based on a power measurement associated with the power source 355. In some examples, the power manager 326 determines the adjustment of parameters such as the data interval. For example, the power manager 326 may call the BLE stack handler 330 to change the first data interval to the second data interval, wherein the first data interval and the second data interval correspond to the duration between the radio frequency operations of the BLE interface 340. In an example where the second data interval is a data interval that is longer than the first data interval, the power manager 326 may call the BLE stack handler 330 to adjust to the second data interval to save energy (e.g., at least one of the comparators 358a-b is generating a logic low value). In an example where the second data interval is a shorter data interval than the first data interval, since the comparators 358a–b are asserting logic high signals and thereby indicating that the energy storage device 356 is fully charged, the power manager 326 can call the BLE stack handler 330 to adjust to the second data interval to increase the data rate of the BLE interface.

[0128] In some examples, the power manager 326 adjusts the power assessment event timer (e.g., the amount of time between power assessments) based on the power assessment (e.g., the available power budget determined by the power assessment). For example, the power manager 326 can increase the power assessment event timer based on determining a relatively low power budget based on the second comparator 358b not asserting a logic high signal. For example, the power manager 326 can reduce the number of power assessments performed within a period of time to save power for the field device 102. In some examples, the power manager 326 calculates the power assessment timer based on the input power of the BLE bridge, the amount of energy stored in the power supply 355, the amount of power of the request of the BLE stack handler 330 to send or receive data via the BLE interface 340, etc., and / or a combination thereof.

[0129] In some examples, the power manager 326 can calculate the amount of time (e.g., the stored energy consumption time) that the BLE interface 340 can consume the stored energy of the power supply 355 based on the configuration of the BLE interface 340 (e.g., the instantaneous transmission rate, the instantaneous antenna power, etc.). For example, the power manager 326 can calculate a power evaluation timer that will be less than the stored energy consumption time to ensure that the energy state of the field device 102, the BLE bridge 104, etc. is evaluated before the BLE bridge 104 consumes enough available power budget to create a power starvation event (e.g., the field device 102, the BLE bridge 104, etc. cannot perform a function due to insufficient available power, an electrical power-off event, etc.). For example, the power manager 326 can adjust the power evaluation event timer based on the input power of the field device 102 measured in mJ / s, the stored energy of the power supply 355 in mJ, and the output power of the field device 102 measured in mJ as described in equation (5) below:

[0130]

[0131] exist Figure 3In the example shown, the platform manager 320 includes a security manager 332 to handle and / or otherwise facilitate decryption or encryption of data packets processed by the BLE bridge 104. In some examples, the security manager 332 is a security controller corresponding to and / or otherwise associated with one or more processors of the BLE bridge 104 that can execute machine-readable instructions. For example, the security controller can be implemented by one or more processors capable of executing machine-readable instructions. In some examples, the security manager 332 deploys an asymmetric encryption algorithm or a symmetric encryption algorithm. For example, the security manager 332 can use symmetric encryption technology to decrypt / encrypt data packets by converting plaintext and converting plaintext to ciphertext using the same key or secret. For example, the security manager 332 can use the Advanced Encryption Standard (AES) to decrypt / encrypt data packets, including using a block cipher (e.g., AES-128 block cipher, AES-192 block cipher, AES-256 block cipher, etc.) to encrypt and decrypt text included in the data packet. In other examples, the security manager 332 may use an AES cipher block chaining (AES-CBC) algorithm, a ciphertext feedback (AES-CFB) algorithm, an AES output feedback (AES-OFB) algorithm, a 2-byte CBC message authentication code (CBC-MAC) algorithm, a Galois MAC (GMAC) algorithm, or a keyed hash MAC (HMAC) algorithm. Alternatively, the security manager 332 may use any other symmetric algorithm to decrypt / encrypt data packets. In other examples, the security manager 332 may use asymmetric encryption techniques by using two independent keys (a first key for encrypting data packets and a second key for decrypting data packets) to decrypt / encrypt data packets. For example, the security manager 332 may use a Diffie-Hellman key exchange, a Rivest, Shamir, and Adleman (RSA) algorithm, or a cryptographic hash function such as a secure hash algorithm 1 (SHA-1), SHA-2, or SHA-3 to decrypt / encrypt data packets of interest). Alternatively, the security manager 332 may use any other asymmetric encryption techniques to decrypt / encrypt data packets of interest.

[0132] In some examples, the security manager 332 authenticates and / or otherwise verifies a connection between the field device 102 and an external device such as a remote device 360. For example, the security manager 332 may determine whether the remote device 360 ​​has permission to exchange data with the field device MCU 350. In such an example, the security manager 332 may receive a first data packet corresponding to a request from the remote device 360 ​​for the remote device 360 ​​to communicate with the field device 102. In response to receiving the request, the security manager 332 may send a second data packet including a signature request to the remote device 360. For example, the signature request may correspond to a signature associated with an elliptic curve digital signature algorithm (ECDSA). In response to receiving the signature request, the remote device 360 ​​may generate a third data packet including a signature and send the third data packet including a signature to the security manager 332 via the BLE interface 340. The security manager 332 may verify the signature provided by the remote device 360 ​​and verify subsequent data packet transmissions between the field device 102 and the remote device 360. Alternatively, the security manager 332 may authenticate hardware that wants to communicate with the field device 102 through any other digital signature algorithm (DSA). In some examples, the security manager 332 performs security-related functions, such as facilitating OTA requests to change passwords or settings of the field device 102, generating security alerts (e.g., connection request alerts, connection failure alerts, etc.), authenticating OTA firmware updates, etc.

[0133] exist Figure 3 In the example shown, the BLE bridge 104 includes a BLE stack handler 330 to facilitate communication operations performed by the BLE interface 340. In some examples, the BLE stack handler 330 simulates a serial port connection connected via a Bluetooth wireless connection. For example, the BLE stack handler 330 can simulate a UART to facilitate communication between the BLE interface 340 and the platform manager 320. In some examples, the BLE stack handler 330 implements a change to a parameter of the BLE interface 340. For example, the BLE stack handler 330 can adjust the connection interval of the BLE interface 340 based on the determination of the power manager 326 to adjust the connection interval. In other examples, the BLE stack handler 330 can adjust the data interval, the radio power level (e.g., the radio transmission power level, the radio reception power level, etc.), the payload size, the delay level (e.g., the slave delay level), etc., and / or a combination thereof.

[0134] exist Figure 3In the example shown, the BLE bridge 104 includes a database 335 to record data (e.g., firmware of the BLE bridge 104, modes of the field device 102, protocol addresses, parameters of the BLE stack handler 330, parameters of the BLE interface 340, task queues, energy consumption values ​​of computing tasks, data buffers including data indicating the charging rate of the power source 355, etc.). The database 335 can respond to queries for information related to the data in the database 335. For example, the database 335 can respond to queries for additional data by providing additional data (e.g., one or more data points), by providing an index associated with the additional data in the database 335. The exemplary database 335 can additionally or alternatively respond to queries by providing an empty index, a database end identifier, etc. when there is no additional data in the database 335.

[0135] The exemplary database 335 may be implemented by volatile memory (e.g., synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), etc.) and / or non-volatile memory (e.g., read-only memory (ROM)), electrically erasable programmable read-only memory (EEPROM), flash memory, etc. The exemplary database 335 may additionally or alternatively be implemented by one or more double data rate (DDR) memories, such as DDR, DDR2, DDR3, DDR4, mobile DDR (mDDR), etc. The exemplary database 335 may additionally or alternatively be implemented by one or more mass storage devices, such as hard disk drives, CD drives, digital versatile disk (DVD) drives, solid-state drives, etc. Although the database 335 is illustrated as a single database in the illustrated example, the database 335 may be implemented by any number and / or type of databases.

[0136] In the example shown, the BLE bridge 104 includes a BLE interface 340 to transmit information to and / or receive information from an external device (e.g., a remote device 360). The BLE interface 340 of the example shown is a radio transceiver that operates in the 2.4 GHz unlicensed ISM band. For example, the BLE interface 340 can operate the radio transceiver based on connection intervals, radio power levels, delays, etc. defined by the power manager 326 and / or the BLE stack handler 330 and / or implemented by the BLE stack handler 330. The BLE interface 340 includes one or more processors that execute machine-readable instructions that, when executed, can receive and / or transmit BLE information via the BLE connection 370. For example, the BLE interface 340 may include a radio transceiver and at least one processor, wherein the at least one processor calls the radio transceiver to receive and / or transmit one or more BLE data packets (e.g., based on BLE configuration parameters). Alternatively, the BLE interface 340 may be a radio transmitter, radio receiver, or radio transceiver operating in any other communication band, spectrum, or the like.

[0137] Although Figure 3 The implementation is illustrated in Figure 1-Figure 2 The BLE bridge 104 is an exemplary embodiment, but Figure 3 One or more of the elements, processes and / or devices illustrated in the example may be combined, divided, rearranged, omitted, eliminated and / or implemented in any other manner. In addition, the exemplary receiver transmitter interface 300, the exemplary input / output interface 310, the exemplary platform manager 320, the exemplary command processor 322, the exemplary protocol handler 324, the exemplary power manager 326, the exemplary RX / TX interface handler 328, the exemplary BLE stack handler 330, the exemplary security manager 332, the exemplary database 335, the exemplary BLE interface 340 and / or more generally, Figure 1-Figure 2The example BLE bridge 104 may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Thus, for example, the example receiver transmitter interface 300, the example input / output interface 310, the example platform manager 320, the example command processor 322, the example protocol handler 324, the example power manager 326, the RX / TX interface handler 328, the example BLE stack handler 330, the example security manager 332, the example database 335, the example BLE interface 340, and / or more generally, the example BLE bridge 104 may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), digital signal processors (DSPs), application specific integrated circuits (ASICs), programmable logic devices (PLDs), and / or field programmable logic devices (FPLDs). When any device or system claim of this patent is read to cover pure software and / or firmware implementations, at least one of the exemplary receiver transmitter interface 300, exemplary input / output interface 310, exemplary platform manager 320, exemplary command processor 322, exemplary protocol handler 324, exemplary power manager 326, RX / TX interface handler 328, exemplary BLE stack handler 330, exemplary security manager 332, exemplary database 335, and / or exemplary BLE interface 340 is expressly defined herein as comprising a non-transitory computer-readable storage device or storage disk (e.g., memory, DVD, CD, Blu-ray disc, etc.), including software and / or firmware. Further, Figure 1-Figure 2 An exemplary BLE bridge 104 may include in addition to Figure 3 elements, processes and / or devices in addition to or in lieu of those shown in Figure 3 One or more of those elements, processes and / or devices shown in, and / or may include one or more of any or all of the elements, processes and devices shown. As used herein, the phrase "in communication," including variations thereof, includes direct communication and / or indirect communication through one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or continuous communication, but rather requires selective communication at periodic intervals, predetermined intervals, non-periodic intervals and / or one-time events.

[0138] Figure 4 4 is a block diagram of an exemplary BLE communication path 400 between an exemplary BLE protocol stack 402 of a remote device 404 and a BLE protocol stack 402 of a field device 406. The BLE protocol stack 402 of the illustrated example is based on the Bluetooth Core Specification (e.g., Bluetooth Core Specification Version 5.0). The BLE protocol stack 402 of the illustrated example may be combined, divided, rearranged, omitted, eliminated, and / or implemented in any other manner. Figure 4One or more of the elements, processes and / or blocks shown in . Figure 4 The remote device 404 of the example shown in FIG. 4 may correspond to Figure 1 remote device 106, Figure 2 Remote devices 1-3 200, 202, 204 and / or Figure 3 Remote device 360. Figure 4 The field device 406 of the illustrated example may correspond to Figure 1-Figure 2 The field device 102 and / or Figure 3 The BLE protocol stack 402 can be composed of a field device MCU 350. Figure 3 The BLE stack handler 330 of the remote device 404 is executed and / or otherwise implemented. In the illustrated example, the physical layer 450 of the remote device 404 is communicatively coupled to the physical layer 450 of the field device 406 and / or otherwise communicates with the physical layer 450 of the field device 406.

[0139] In the illustrated example, the BLE protocol stack 402 includes an exemplary host 410, which includes an exemplary Generic Access Profile (GAP) layer 415, an exemplary Generic Attribute Profile (GATT) layer 420, an exemplary Attribute Protocol (ATT) layer 425, an exemplary Security Manager layer 430, and an exemplary Logical Link Control and Adaptation Protocol (L2CAP) layer 435. Figure 4 , the BLE protocol stack 402 includes an exemplary controller 438 , which includes an exemplary host-controller interface (HCI) layer 440 , an exemplary link layer 445 , and an exemplary physical layer 450 .

[0140] exist Figure 4 In the example shown, the BLE protocol stack 402 includes a host 410 to acquire and process application data. For example, the host 410 of the remote device 404 may include an interface to a process control application running on a standard operating system. In other examples, the host 410 of the field device 406 may include an interface to a process control application running on a standard operating system. Figure 3 An interface for an application (e.g., a firmware application, a firmware application that uses a processor to execute instructions, etc.) on the field device MCU 350. Figure 4 In the embodiment, the host 410 can package and unpack the BLE data packets corresponding to the BLE stack handler 330 for Figure 3 The platform manager 320 handles this.

[0141] exist Figure 4In the example shown, the BLE protocol stack 402 includes a GAP layer 415 to define the general topology of the BLE protocol stack 402. For example, the GAP layer 415 defines how the remote device 404 and the field device 406 make themselves available (e.g., broadcast) and how the remote device 404 and the field device 406 communicate with each other (e.g., connect). For example, the GAP layer 415 defines the roles of a BLE broadcaster and a BLE observer. For example, a BLE broadcaster can be a device that broadcasts a public notification data packet, and a BLE observer can be a device that listens for data in the notification packet sent by the broadcaster.

[0142] exist Figure 4 In the example shown, the BLE protocol stack 402 includes a GATT layer 420 to define a BLE client (e.g., Figure 1 remote device 106) and a BLE server (e.g., Figure 1-Figure 3 For example, a BLE client may be a device that sends a request to a GATT server, where the BLE client may read and / or write attributes found in the server. A BLE server may be a device that stores attributes. For example, once a BLE client sends a request, the server must make the attribute available.

[0143] exist Figure 4 In the example shown, the BLE protocol stack 402 includes an ATT layer 425 to define a protocol for transmitting attribute data between the remote device 404 and the field device 406. The exemplary ATT layer 425 includes the functionality of the exemplary GATT layer 420, such as write requests, write responses, notifications, read responses, etc. For example, the GATT layer 420 defines and creates appropriate attributes for a given application in the host 410, and the ATT layer 425 creates outgoing data packets and parses incoming data packets that define actions in the GATT layer 420.

[0144] exist Figure 4 In the example shown, the BLE protocol stack 402 includes a security manager layer 430 to handle attribute permission levels such as read permission, write permission, etc. In some examples, the security manager layer 430 performs functions such as device authentication, device authorization, data integrity, data confidentiality, and / or data privacy. In some examples, the security manager layer 430 compares the permission level of a user (e.g., an administrator, engineer, user, etc.) with the action requested by the user (e.g., a read request, a write request, etc.). In such an example, if the permission levels do not match, the security manager layer 430 can prevent the user from performing the action. For example, the security manager layer 430 can discard data packets corresponding to unauthorized actions and can transmit an error code to the user indicating that the action is not authorized. In some examples, the security manager layer 430 is bypassed and / or otherwise disabled. For example, Figure 3 The BLE stack handler 330 can disable Figure 4 The security manager layer 430 is configured to Figure 3 The security manager 332 performs security-related functions instead of the security manager layer 430.

[0145] exist Figure 4 In the example shown, the BLE protocol stack 402 includes an L2CAP layer 435 to manage quality of service (QoS), routing, segmentation, and reassembly of data packets for use with higher layer protocols (e.g., ATT, Security Management Protocol (SMP), etc.). Figure 4 In the example shown, the BLE protocol stack 402 includes an HCI layer 440 to communicate with Figure 3 For example, the HCI layer 440 can transmit BLE commands, BLE events, BLE data packets, etc. between the layers of the BLE protocol stack 402. Figure 4 In the example shown, the BLE protocol stack 402 includes a link layer 445 and a physical layer 450 to control, handle, manage, etc., the transmission of L2CAP data packets while ensuring delivery (eg, guaranteed delivery) and integrity of the data.

[0146] Figure 5 5 is a block diagram of an example implementation of an ATT protocol packet 500. In the example shown, the ATT protocol packet 500 includes a preamble 502, an access address 504, a protocol data unit (PDU) 506, and a cyclic redundancy check (CRC) 508. The preamble 502 of the example shown is a 2-byte value used for synchronization and timing of a data receiver (e.g., a remote device 404, a field device 406, etc.). For example, a preamble value of 0xAA in a BLE data packet may indicate that the BLE data packet is a broadcast data packet. The access address 504 of the example shown is a 4-byte value that identifies a BLE device. For example, an access address value of 0x8E89BED6 for a BLE packet may indicate that the BLE packet is a broadcast packet.

[0147] exist Figure 5 In the example shown, PDU 506 may be a value in the range of 2 to 257 bytes. For example, Figure 3 The power manager 326 can be based on Figure 3 The size of the PDU 506 is determined based on the available power budget of the BLE bridge 104. The PDU 506 includes an exemplary link layer (LL) header 510, which is a 2-byte value that identifies Figure 4The exemplary PDU 506 includes an exemplary PDU payload 512, which is a value in the range of 0 to 251 bytes. The PDU 506 includes an exemplary message integrity check (MIC) 514, which is a 4-byte value used to evaluate the data integrity of the BLE data packet. Alternatively, the MIC 514 may not be used and the 4 bytes of the MIC 514 may be reallocated to the PDU payload 512. For example, by not using the MIC 514, the PDU payload 512 may have an extended range of 0 to 255 bytes. Figure 5 In the example, the PDU payload 512 includes an exemplary L2CAP header 516, which is an identifier Figure 4 The 4-byte value of the L2CAP layer 435.

[0148] Figure 5 The PDU payload 512 of the illustrated example includes example ATT data 518, which is a value in the range of 0 to 247 bytes. In an example where the MIC 514 is not used, the ATT data 518 may have a range of 0 to 251 bytes. The ATT data 518 includes an example ATT header 520 and an example ATT payload 522. The ATT header 520 is a 3-byte value organized by an example operation code (opcode) 524 and an example handle 526. The operation code 524 is a 1-byte value that may correspond to an instruction or operation to be performed. The handle 526 is a 1-byte value corresponding to an instruction or operation to be performed. Figure 4 The ATT payload 522 is a 2-byte value corresponding to an attribute on a GATT server on an exemplary GATT layer 420 of the embodiment of the present invention. The ATT payload 522 is data (e.g., field device information, firmware executable files, etc.) to be transmitted to the remote device 404, the field device 406, etc. In an example where the MIC 514 is not used, the ATT payload 522 can have an extended range of 0 to 248 bytes.

[0149] exist Figure 5 In the example shown, there are one or more elements of the ATT protocol packet 500 that can be adjusted, modified, or removed based on the available power budget. For example, Figure 3 The protocol handler 324 can transmit the data packet to Figure 3 LL header 510, L2CAP header 516 and / or MIC 514 are removed before the remote device 360. In other examples, Figure 3 The power manager 326 can direct Figure 3 The BLE stack handler 330 of the power manager 326 may increase or decrease the size of the PDU 506 and / or adjust the maximum transmission unit (MTU) parameter based on the available power budget. For example, the power manager 326 may call the BLE stack handler 330 to communicate with the Figure 1The power manager 326 may instruct the BLE stack handler 330 to negotiate with the remote device 106 to increase the size of the PDU 506 from 100 bytes to 257 bytes based on the increase in the available power budget of the BLE and / or the increase in the MTU. In other examples, the power manager 326 may direct the BLE stack handler 330 to communicate with the remote device 106. Figure 1 The remote device 106 negotiates to reduce the size of the PDU 506 from 257 bytes to 10 bytes based on a reduction in the available power budget of the BLE bridge 104 and / or a reduction in the MTU.

[0150] Fig. 6A 6 is a block diagram depicting an exemplary implementation of an exemplary BLE advertising data format 600. The BLE advertising data format 600 of the illustrated example is a known conventional BLE PDU format (e.g., based on the Bluetooth Core Specification Version 5.0). The BLE advertising data format 600 describes a format used by a device to generate a BLE data packet for advertising information via a BLE connection. Fig. 6A , the BLE advertising data format 600 includes three exemplary data structures 602, 604, 606, which include AD data 1 602, AD data 2 604, and AD data 3 606, wherein each of the data structures 602, 604, 606 includes an exemplary length parameter 608a, an exemplary AD type parameter 608b, and an exemplary AD data parameter 608c. For example, the length parameter 608a may correspond to the length (e.g., the number of bits, the number of bytes, etc.) of the data included in the AD data parameter 608c. The AD type parameter 608b may correspond to the data type of the data included in the AD data parameter 608c. For example, the data type may be Boolean, integer, floating point, etc.

[0151] Figure 6B is a block diagram of an exemplary data packet 611 based on an exemplary BLE advertising data format 610. Fig. 6A The BLE advertising data format is 600. For example, Figure 6B The data packet 611 may be a notification packet, a notification data packet, etc. The BLE notification data format 610 describes the format of the BLE packet used by the device to generate OTA notifications and / or otherwise broadcast information on a BLE connection. For example, Figure 1 The field device 102 may generate an advertisement packet based on the BLE advertisement data format 610 and transmit the advertisement packet to the Figure 1 The BLE connection 108 transmits the advertising packet to the device (e.g., Figure 1 remote device 106).

[0152] exist Figure 6BIn FIG. 6 , the BLE advertising data format 610 includes an exemplary preamble data field 612, an exemplary access address data field 614, an exemplary PDU data field 616, and an exemplary CRC data field 618. Figure 6B , the preamble data field 612 has a data size of 1 byte, the access address data field 614 has a data size of 4 bytes, the PDU data field 616 has a data size in the range of 2-39 bytes, and the CRC data field 618 has a data size of 3 bytes. Alternatively, one or more of the preamble data field 612, the access address data field 614, the PDU data field 616, or the CRC data field 618 may have different data sizes or data size ranges. Figure 6B The preamble data field 612 may correspond to an identifier of a broadcast Bluetooth data packet based on the BLE advertising data format 610. The access address data field 614 may correspond to an address (e.g., a radio frequency (RF) address) of the BLE bridge 104, and / or more generally, to an address associated with the field device 102. Figure 6B The PDU data field 616 may correspond to the data payload of the data packet. Figure 6B The CRC data field 618 may correspond to a CRC value used by a receiving device to determine whether a data packet is valid, corrupted, etc. For example, a CRC value such as Figure 1 A receiving device, such as remote device 106 , may reject the data packet by determining that the data packet is corrupted based on the value of the CRC in CRC data field 618 .

[0153] exist Figure 6B In the example shown, the PDU data field 616 includes an exemplary header data field 620 and an exemplary payload data field 622 . Figure 6B The header data field 620 has a data size of 2 bytes and the payload data field 622 has a data size in the range of 0-37 bytes. Alternatively, the header data field 620 and / or the payload data field 622 may have different data sizes and / or data ranges. Figure 6B The payload data field 622 may correspond to the Figure 1 data of the remote device 106.

[0154] exist Figure 6B In FIG. 6 , the payload 622 includes an exemplary advertisement address (Adv Address) data field 624 and an exemplary advertisement data (Adv Data) field 626 . Figure 6BThe exemplary announcement address data field 624 has a data size of 6 bytes and the announcement data field 626 has a data size in the range of 0-31 bytes. Alternatively, the announcement address data field 624 and / or the announcement data field 626 may have different data sizes and / or data ranges. Figure 6B The advertising address data field 624 may correspond to the address of the BLE bridge 104, and / or more generally, to the address of the BLE bridge 104. Figure 1 The address associated with the field device 102. For example, the advertising address data field 624 may be composed of Figure 3 The BLE stack handler 330 is assigned and / or configured by Figure 3 The BLE stack handler 330 is defined in other ways. Figure 6B The announcement data field 626 may correspond to data to be transmitted to the remote device 106 .

[0155] exist Figure 6B In the example shown, the notification data field 626 may be one of three exemplary notification data formats 628, 630, 632, including a first exemplary notification data format 628, a second exemplary notification data format 630, and a third exemplary notification data format 632. The notification data field 626 may be a Figure 3 The field device MCU 350 will be based on Figure 3 The first notification data format 628 corresponds to an authenticated encryption security protocol. The second notification data format 630 corresponds to an authenticated plaintext security protocol. The third notification data format 632 corresponds to a plaintext security protocol.

[0156] exist Figure 6B In, each of the advertising data formats 628, 630, 632 includes an exemplary data structure AD data 1 634. AD data 1 634 can correspond to broadcast device description data. For example, AD data 1 634 can correspond to a <<flag>> data type defined by the Bluetooth Core Specification Version 5.0. For example, AD data 1 634 can indicate whether the broadcasting device (e.g., the BLE bridge 104) is transmitting at an enhanced data rate, whether the broadcasting device is a low energy device, etc. In Figure 6B , AD data 1 634 includes an exemplary length data field 636, an exemplary type data field 638, and an exemplary flag data field 640. The length data field 636 may correspond to the data size of the AD data 1 634. The type data field 638 may correspond to the data type of the data included in the flag data field 640. The flag data field 640 may correspond to the data to be transmitted by the broadcasting device. Figure 6BThe AD data 1 634 has a data size of 3 bytes. For example, the length data field 636, the type data field 638, and the flag data field 640 may each have a data size of 1 byte. Alternatively, each of the data fields 636, 638, 640 of the AD data 1 628 may have a different data size.

[0157] exist Figure 6B In the announcement data formats 628, 630, 632, each has one of the second exemplary data structures AD data 2 642, 644, 646. AD data 2 642, 644, 646 may correspond to manufacturer-specific data. AD data 2 642, 644, 646 each includes a data header including an exemplary length data field 648, an exemplary type data field 650, and an exemplary manufacturer identifier (Mfg.ID) data field 652. The length data field 648 may correspond to the data size of the data included in AD data 2 642, 644, 646. The type data field 650 may correspond to the data type (e.g., floating point type, integer type, string type, etc.) of the data included in AD data 2 642, 644, 646. The manufacturer identifier data field 652 may correspond to the manufacturer of the broadcasting device. For example, Figure 1 The manufacturer of the field device 102 may be Emerson. In such an example, the manufacturer identifier data field 652 of the data packet broadcast by the field device 102 may be 0x04DF.

[0158] exist Figure 6B In the example shown, the AD data 2 642 of the first advertisement data format 628 includes an exemplary ciphertext data field 654, an exemplary message authentication code (MAC) data field 656, and an exemplary random number data field 658. Figure 6B In, the ciphertext data field 654 may correspond to encrypted data represented by the ciphertext. The MAC data field 656 may correspond to data used by the receiving device to authenticate the message. For example, the remote device 106 may use the data included in the MAC data field 656 to confirm that the received data packet is from the stated sender and has not been altered. The MAC defined in the MAC data field 656 may correspond to a MAC based on a CBC-MAC algorithm, a GMAC algorithm, an HMAC algorithm, etc. or any other cryptographic algorithm. The random number data field 658 is a one-time parameter for generating an initialization vector for a block cipher (e.g., AES). For example, the BLE bridge 104 may generate a different value for the random number data field 658 each time a data packet is sent to the remote device 106. In Figure 6B, the ciphertext data field 654 may have a data size in the range of 0-18 bytes, the MAC data field 656 has a data size of 2 bytes, and the random number data field 658 has a data size of 4 bytes. Alternatively, one or more of the ciphertext data field 654, the MAC data field 656, or the random number data field 658 may have different data sizes and / or ranges.

[0159] exist Figure 6B , the AD data 2644 of the second announcement data format 630 includes a first exemplary plaintext data field 660, a MAC data field 656 of the first announcement data format 628, and a first exemplary placeholder data field 662. The first plaintext data field 660 may correspond to plaintext data with a data size in the range of 0-21 bytes. Alternatively, the first plaintext data field 660 may have a different data size and / or range. Since the authenticated plaintext security protocol does not require a random value, the random number data field 658 of the first announcement data format 628 has been replaced with a first placeholder data field 662. The first placeholder data field 662 has a data size of 1 byte. Alternatively, the first placeholder data field 662 may have a different size. The first placeholder data field 662 has an exemplary value of 0x10. The value of 0x10 is used to determine the data boundaries of the first plaintext data field 660, the MAC data field 656, and the first placeholder data field 662. For example, if the hexadecimal representation of the plaintext data field is 0x0000 0000 and the hexadecimal representation of the MAC data field 656 is 0x0000, then the hexadecimal representation of the first placeholder data field 662 can mark the data boundary when the data fields are concatenated. For example, when concatenated, the hexadecimal representation can be 0x0000 0000 0000 10. Reading from right to left, the boundary is obvious. In some examples, in order to distinguish it from the ciphertext included in the ciphertext data field 654, the cryptographic nonce value in the random number data field 658 may not end with 0x10. For example, if the cryptographic nonce value ends with 0x10, the cryptographic nonce value can be increased by 1 before use.

[0160] exist Figure 6B, the AD data 2 646 of the third announcement data format 632 includes a second exemplary plaintext data field 664, a second exemplary placeholder data field 666, and a third exemplary placeholder data field 668. The second plaintext data field 664 may correspond to plaintext data having a data size in the range of 0 to 22 bytes. Alternatively, the second plaintext data field 664 may have a different data size and / or range. Since the plaintext security protocol does not require a MAC or random number value, the MAC data field 656 of the first and second announcement data formats 628, 630 and the random number data field 658 of the first announcement data format 628 have been replaced with a second placeholder data field 666 and a third placeholder data field 668, respectively. The second placeholder data field 666 has a data size of 1 byte. Alternatively, the second placeholder data field 666 may have a different size. The second placeholder data field 666 has an exemplary value of 0x10. The value 0x10 is used to determine the data boundary of the second plaintext data field 664 and the second placeholder data field 666. The third placeholder data field 668 has a data size of 1 byte. Alternatively, the third placeholder data field 668 may have a different size.

[0161] exist Figure 6B In the example shown, AD Data 2 642, 644, 646 is an extensible, flexible structure for announcing data. In some examples, AD Data 2 642, 644, 646 can be constructed according to the needs of the operator of the field device 102. For example, an operator in the process control industry can eliminate AD Data 2 642, 644, 646 to achieve data privacy (e.g., limit the information to be broadcasted via OTA via BLE connection) or construct AD Data 2 642, 644, 646 based on the operator's requirements. In such an example, the operator can freely define the order of the data, the data length of the maximum PDU size, the number of elements in the data, the information included in the data, etc. In some examples, AD Data 2 642, 644, 646 can be dynamic. For example, AD Data 2 642, 644, 646 can be adjusted between data packet transmissions.

[0162] Figure 6C is a block diagram of an exemplary data packet 671 based on an exemplary BLE extended advertisement data format 670. Fig. 6A The BLE advertising data format is 600. For example, Figure 6C The data packet 671 may be an extended advertising packet, an extended advertising data packet, etc. The BLE extended advertising data format 670 describes the format used by a device to generate a BLE packet for announcing and / or otherwise broadcasting information on a BLE connection. For example, Figure 1The field device 102 can generate an extended advertising packet based on the BLE extended advertising data format 670 and transmit it via Figure 1-2 The BLE connection 108 transmits an extended advertising packet to the device (e.g., Figure 1 remote device 106).

[0163] exist Figure 6C In the BLE extended advertisement data format 670, the preamble 612 has a data size in the range of 1-2 bytes. Figure 6C In the BLE extended advertisement data format 670, the PDU 616 has a data size in the range of 2-257 bytes. Figure 6C In the extended announcement data format 670, the payload 622 has a data size in the range of 1-255 bytes. Alternatively, one or more of the preamble 612, the PDU 616, or the payload 622 may have a different data size and / or range.

[0164] exist Figure 6C In the example shown, the payload 622 includes announcement data 626, an exemplary extended header length (Ext.Header Len) 672, an exemplary announcement mode 674, and an exemplary extended header (Ext.Header) 676. Figure 6C In FIG. 6 , the extended header length 672 indicates the length of the extended header 676 and has a data size of 6 bits. Figure 6C The notification mode 674 defines Figure 1-Figure 3 The advertising mode 674 corresponds to a mode of the BLE bridge 104 and has a data size of 2 bits. For example, the advertising mode 674 may correspond to a non-connectable and non-scannable mode, a connectable and non-scannable mode, or a non-connectable and scannable mode. Figure 6C The extended header 676 defines the attributes of the extended notification event and has a data size in the range of 0 to 63 bytes. Figure 6C The announcement data 626 represents and / or otherwise includes announcement data to be transmitted to a device (eg, remote device 106 ). Figure 6C The announcement data 626 has a data size in the range of 0-254 bytes. Alternatively, one or more of the announcement data 626, the extended header length 672, the announcement mode 674, or the extended header 676 may have a different data size and / or range.

[0165] exist Figure 6C In the example, the notification data 626 can be one of three exemplary extended notification data formats AD data 1 678, 680, 682, including a first exemplary extended notification data format 678, a second exemplary extended notification data format 680, and a third exemplary notification data format 682. The notification data field 626 is composed of Figure 3 The field device MCU 350 will be based on Figure 3 The first extended notification data format 678 corresponds to an authenticated encryption security protocol. The second extended notification data format 680 corresponds to an authenticated plaintext security protocol. The third extended notification data format 682 corresponds to a plaintext security protocol.

[0166] exist Figure 6C In the embodiment, AD data 1 678, 680, 682 may correspond to manufacturer specific data. AD data 1 678, 680, 682 each include a data header, which includes Figure 6B The length data field 648, the type data field 650 and the manufacturer identifier (Mfg. ID) data field 652. Figure 6C In the first extended announcement data format 678, AD data 1 includes an exemplary extended ciphertext data field 684, Figure 6B The message authentication code (MAC) data field 656 and Figure 6B The random number data field 658. Figure 6C In the example, the extended ciphertext data field 684 may correspond to the encrypted data represented by the ciphertext. Figure 6C In the embodiment, the extended ciphertext data field 684 has a data size in the range of 0-244 bytes. Alternatively, the extended ciphertext data field 684 may have a different data size and / or range.

[0167] exist Figure 6C In the second extended notification data format 680, AD data 1 includes a first exemplary extended plaintext data field 686, Figure 6B The MAC data field 656 and Figure 6B The first placeholder data field 662 of the first extended plaintext data field 686 may correspond to plaintext data having a data size in the range of 0-247 bytes. Alternatively, the first extended plaintext data field 686 may have a different data size and / or range.

[0168] exist Figure 6C In the third extended notification data format 682, AD data 1 includes a second example extended plaintext data field 686, Figure 6B The second placeholder data field 666 and Figure 6B The third placeholder data field 668 of the second extended plaintext data field 686 may correspond to plaintext data having a data size in the range of 0-248 bytes. Alternatively, the second extended plaintext data field 686 may have a different data size and / or range.

[0169] Fig. 7A700 is a block diagram depicting an exemplary implementation of an exemplary BLE scan response data format 700. The BLE scan response data format 700 describes a format used by a device (e.g., an advertising device) to generate a BLE packet in response to receiving a scan request packet (e.g., a device scan packet). For example, Figure 1 The remote device 106 may respond to receiving the announcement packet (e.g., based on Figure 6B BLE advertising data format 610, Figure 6C The remote device 106 can generate a device scan packet via a BLE extended advertising format 670, etc. Figure 1 The BLE connection 108 of the field device 102 transmits the device scan packet to the field device 102. In response to receiving the device scan packet, the field device 102 can generate a scan response packet based on the BLE scan response data format 700. The field device 102 can transmit the scan response packet to the remote device 106 and / or otherwise facilitate the transmission of data corresponding to the scan response packet to the remote device 106 via the BLE connection 108. Fig. 7A In the example, the advertisement scan response (ADSR) data is concatenated with a total length R. In some examples, the BLE scan response data format 700 supports extended advertisements and traditional advertisements. For example, for extended advertisements, the maximum length of R is 247 bytes. In other examples, for traditional advertisements, the maximum length is 27 bytes.

[0170] Figure 7B is a block diagram of an exemplary data packet 711 based on an exemplary BLE scan response data format 710. Fig. 7A The BLE scan response data format is 700. For example, Figure 7B The data packet 711 may be a scan response data packet. The BLE scan response data format 710 describes the format of a device generating a BLE data packet, which is used to respond to a device scan packet in a BLE connection. For example, Figure 1 The field device 102 may generate a scan response data packet based on the BLE scan response data format 710 and transmit the scan response data packet to the BLE device 102 via Figure 1 The BLE connection 108 transmits a scan response data packet to the device (e.g., Figure 1 remote device 106).

[0171] exist Figure 7B In the example shown, the BLE scan response data format 710 includes the preamble 612, access address 614, PDU 616, and CRC 618 of FIG. Figure 7B In the PDU 616, Figure 6B header 620 and payload 622. Figure 7B , payload 622 includes Figure 6B notification address 624 and notification data 626.

[0172] exist Figure 7B In the example shown, the announcement data 626 may be one of three exemplary scan response data formats AD data 1 712 , 714 , 716 , including a first exemplary scan response data format AD data 1 712 , a second exemplary scan response data format AD data 1 714 , and a third exemplary scan response data format AD data 1 716 . Figure 3 The field device MCU 350 selects the announcement data field 626 based on the security protocol to be employed by the security manager 332. The first scan response data format 712 corresponds to an authenticated cryptographic security protocol. The second scan response data format 714 corresponds to an authenticated plaintext security protocol. The third scan response data format 716 corresponds to a plaintext security protocol.

[0173] exist Figure 7B In the example shown, AD data 1 712, 714, 716 may correspond to manufacturer specific data. AD data 1 712, 714, 716 each includes a data header including Figure 6B The length data field 648, the type data field 650 and the manufacturer identifier (Mfg. ID) data field 652. Figure 7B In the first scan response data format 712, AD data 1 includes Figure 6B The exemplary ciphertext data field 718 and message authentication code (MAC) data field 656 of FIG. Figure 7B In the embodiment of the present invention, the ciphertext data field 718 may correspond to encrypted data represented by the ciphertext and have a data size ranging from 0 to 25 bytes. Alternatively, the ciphertext data field 718 may have a different data size and / or range.

[0174] exist Figure 7B In the example shown, the AD data 1 of the second scan response data format 714 includes Figure 6B The first exemplary plaintext data field 720 and the MAC data field 656. The first plaintext data field 720 may correspond to plaintext data having a data size in the range of 0 to 25 bytes. Alternatively, the first plaintext data field 720 may have a different data size and / or range. Figure 6C , AD data 1 of the third scan response data format 716 includes a second exemplary plaintext data field 722. The second plaintext data field 722 may correspond to plaintext data having a data size in the range of 0 to 27 bytes. Alternatively, the second plaintext data field 722 may have a different data size and / or range.

[0175] Fig. 8A is a block diagram of an exemplary data packet 801 based on the BLE data channel packet format 800. For example, Fig. 8A The data packet 801 may be a BLE data channel packet, a data channel packet, etc. The BLE data channel packet format 800 describes the format used by a device to generate a BLE packet in response to establishing a connection via a BLE connection. For example, Figure 1 The field device 102 may generate a BLE data packet based on the BLE data channel packet format 800 and transmit the BLE data packet to the Figure 1 The BLE connection 108 transmits the BLE data packet to the device (e.g., Figure 1 In such an example, the field device 102 and the remote device 106 have established a communication connection via the BLE connection 108.

[0176] exist Fig. 8A In the example shown, the BLE data channel packet format 800 includes Figure 6B preamble 612, access address 614, PDU 616 and CRC 618. Fig. 8A The PDU 616 has a data size in the range of 2 to 257 bytes. Alternatively, Fig. 8A The PDUs 616 may have different data sizes and / or ranges. Fig. 8A 8, the PDU 616 includes an exemplary PDU header 802, an exemplary L2CAP header 804, an exemplary ATT opcode 806, an exemplary ATT handle 808, and an exemplary data channel payload 810. The PDU header 802 has a data size of 2 bytes, the L2CAP header 804 has a data size of 4 bytes, the ATT opcode 806 has a data size of 1 byte, the ATT handle 808 has a data size of 2 bytes, and the data channel payload 810 has a data size ranging from 0 to 244 bytes. Alternatively, one or more of the PDU header 802, the L2CAP header 804, the ATT opcode 806, the ATT handle 808, or the data channel payload 810 may have different data sizes and / or ranges.

[0177] exist Fig. 8A In the example shown, the data channel payload 810 can be one of three exemplary data channel payload formats 812, 814, 816, including a first exemplary data channel payload format 812, a second exemplary data channel payload format 814, and a third exemplary data channel payload format 816. The format of the data channel payload 810 is represented by Figure 3 The field device MCU 350 is based on Figure 3The first data channel payload format 812 corresponds to an authenticated cryptographic security protocol. The second data channel payload format 814 corresponds to an authenticated plaintext security protocol. The third data channel payload format 816 corresponds to a plaintext security protocol.

[0178] exist Fig. 8A In the example shown, the data channel payload formats 812, 814, 816 each include an exemplary opcode data field 818, an exemplary counter data field 820, and an exemplary data field 822. The opcode data field 818 has a data size of 1 byte and may correspond to a BLE opcode. The counter data field 820 has a data size of 2 bytes and may correspond to a message index used to track the number of messages received or transmitted. For example, the counter data field 820 may be Figure 1-3 The BLE bridge 104 is used to prevent replay attacks during an active BLE connection. An exemplary replay attack may occur when an encrypted message is intercepted and later replayed because the original encrypted message is valid and therefore does not need to be decrypted. In some examples, Figure 1 The BLE bridge 104 and / or the remote device 106 may reject messages with previous indexes based on analyzing the value of the counter data field 820. For example, when the BLE bridge 104 receives and accepts a valid message, the BLE bridge 104 may increment an internal counter. As a result, the BLE bridge 104 will only accept messages with current or future index values. In some examples, allowing for future indexes accommodates situations where a message is discarded and resent using an incremented index.

[0179] exist Fig. 8A In the example shown, the data field 822 has a data size in the range of 0 to 235 bytes. Alternatively, one or more of the opcode data field 818, the counter data field 820, or the data field 822 may have a different data size and / or range. Fig. 8A The opcode data field 818, counter data field 820, and data field 822 of the first data channel payload format 812 are transmitted using ciphertext. For example, Figure 3 The security manager 332 can be used by using the Figure 6B The values ​​in the MAC data field 656 and the random number data field 658 are used to decrypt the ciphertext representation of the opcode data field 818, the counter data field 820, and the data field 822.

[0180] Fig. 8AThe second data channel payload format 814 includes the opcode data field 818 and the counter data field 820 of the first data channel payload format 812. The second data channel payload format 814 includes a first exemplary plaintext data field 824 having a data size in the range of 0 to 238 bytes. Alternatively, the first plaintext data field 824 may have a different data size and / or range. Fig. 8A The operation code data field 818, the counter data field 820, and the first plaintext data field 824 of the second data channel payload format 814 are transmitted using authenticated plaintext. For example, Figure 3 The security manager 332 can be used by using the Figure 6B The plaintext representation of the opcode data field 818 , the counter data field 820 , and the first plaintext data field 824 are processed based on the values ​​in the MAC data field 656 and the first placeholder data field 662 .

[0181] Fig. 8A The third data channel payload format 816 includes the opcode data field 818 and the counter data field 820 of the first data channel payload format 812. The third data channel payload format 816 includes a second exemplary plaintext data field 826 having a data size in the range of 0 to 239 bytes. Alternatively, the second plaintext data field 826 may have a different data size and / or range. Fig. 8A The opcode data field 818, the counter data field 820, and the second plaintext data field 826 of the third data channel payload format 816 are transmitted using plaintext. For example, Figure 3 The security manager 332 can be used by using the Figure 6B The plaintext representation of the opcode data field 818 , the counter data field 820 , and the first plaintext data field 824 are processed using the values ​​in the second placeholder data field 666 and the third placeholder data field 668 .

[0182] Figure 8B Describes the Figure 3 830 , 832 , 834 , 836 processed by the field device MCU 350 . Figure 8B The industrial protocol data packets 830 , 832 , 834 , 836 depicted in include an exemplary request data packet 830 , an exemplary response success / warning data packet 832 , an exemplary error response data packet 834 , and an exemplary communication error response data packet 836 .

[0183] exist Figure 8B In the example shown, the request data packet 830 may correspond to Figure 1 The remote device 106 transmits to Figure 1 The remote device 106 may request and / or otherwise attempt to retrieve data associated with the field device 102. For example, the remote device 106 may encapsulate the request data packet 830 in a BLE data packet and transmit the request data packet 830 to the remote device 106 via the BLE data packet. Figure 1 The BLE data packet is transmitted via the BLE connection 108. The request data packet 830 includes an exemplary command number field 838, an exemplary byte count field 840, and an exemplary request data payload 842. The command number field 838 has a data size of 2 bytes and may correspond to a HART protocol command. The byte count field 840 has a data size of 1 byte and may correspond to a Fig. 8A The request data payload 842 has a counter data field 820. The request data payload 842 has a counter data field 820 based on whether the request data packet 830 uses an authenticated encryption security protocol, an authenticated plain text security protocol, or a combination of the authentication and plain text security protocols. Fig. 8A The size of data generated by the plaintext security protocol.

[0184] exist Figure 8B In the example shown, the response success / warning data packet 832 may correspond to a response success / warning data packet transmitted by the field device 102 to the Figure 1 For example, the field device 102 may encapsulate the response success / warning data packet 832 in a BLE data packet and transmit the response success / warning data packet 832 to the remote device 106 via the BLE data packet. Figure 1 The BLE data packet is transmitted on the BLE connection 108 of the BLE connection. The response success / warning data packet 832 includes an exemplary device status field 843, a command number field 838, a byte count field 840, an exemplary response code field 844, and an exemplary response data payload 846. The device status field 842 has a data size of 1 byte and can correspond to a HART device status value. The response code 844 has a data size of 1 byte and can correspond to a HART response code. The response data payload 846 has a data size based on whether the response success / warning data packet 832 uses an authenticated encryption security protocol, an authenticated plaintext security protocol, or a combination of Fig. 8A The size of data generated by the plaintext security protocol.

[0185] exist Figure 8B In the example shown, when a HART-related error is generated by receiving the response success / warning data packet 832, the error response data packet 834 may correspond to data transmitted by the field device 102 to the remote device 106. The error response data packet 834 includes a device status field 843, a command number field 838, a byte count field 840, and an exemplary response error code field 848. The response error code field 848 has a data size of 1 byte and may correspond to a HART response error code.

[0186] exist Figure 8B In the example shown, when receiving the response success / warning data packet 832 generates a HART-related error (e.g., a HART communication error), the communication error response data packet 836 may correspond to data transmitted by the field device 102 to the remote device 106. The communication error response data packet 836 includes a device status field 843, a command number field 838, a byte count field 840, and an exemplary communication (Comm) error field 850. The communication error field 850 has a data size of 1 byte and may correspond to a HART communication error code.

[0187] Figure 8C Depicted are exemplary concatenated HART frame sets 860, 870, including a first exemplary set 860 of concatenated HART request frames and a second exemplary set 870 of concatenated HART response frames. Figure 8C In FIG. 8 , the first set 860 represents three exemplary command request data packets 862, 864, 866. For example, the command request data packets 862, 864, 866 may correspond to Figure 8B Each of the command request data packets 862, 864, 866 includes Figure 8B The command number field 838, the byte count field 840, and the request data payload 842. For example, the remote device 106 can aggregate multiple command request data packets and generate a BLE packet based on the aggregation. In such an example, the remote device 106 can generate a BLE packet based on the command number field 838, the byte count field 840, and the request data payload 842. Fig. 8A The BLE data channel packet format 800 generates a BLE packet, wherein the BLE packet includes Figure 8C For example, the remote device 106 may be operable to increment the command request data packet 862, 864, 866 each time the command request data packet 862, 864, 866 is processed. Fig. 8A The counter data field 820 of the command request data packets 862, 864, 866 is used to concatenate and / or otherwise aggregate the command request data packets 862, 864, 866.

[0188] exist Figure 8C In the example shown, the second set 870 shows three exemplary response success / warning data packets 872, 874, 876. Each of the response success / warning data packets 872, 874, 876 includes Figure 8B The device status field 843, Figure 8B The command number field 838, the byte count field 840, the response code field 844, and the response data payload 846 of the field device 102. For example, the field device 102 can aggregate multiple response success / warning data packets 872, 874, 876 and generate a BLE packet based on the aggregation. In such an example, the field device 102 can generate a BLE packet based on the command number field 838, the byte count field 840, the response code field 844, and the response data payload 846. Fig. 8A The BLE data channel packet format 800 generates a BLE packet, wherein the BLE packet includes Figure 8C 8. For example, the field device 102 may be operable to concatenate and / or otherwise aggregate the response success / warning data packets 872, 874, 876 by incrementing the counter data field 820 of FIG. 8 each time the byte count field 840 of one of the response success / warning data packets 872, 874, 876 is processed.

[0189] Fig. 9A 900 and an exemplary implementation of an exemplary manufacturer command configuration file 910. The manufacturer command configuration file 900 represents an exemplary implementation of an exemplary manufacturer command service 910. Figure 4 The GATT layer 420 and the ATT layer 425 protocol layers use the basic functions of the modes and access procedures. For example, the manufacturer command profile 900 may process the following in conjunction with Figures 13A-13B For example, the manufacturer command profile 900 may include a predefined or predetermined set of services such as the manufacturer command service 910. The manufacturer command service 910 represents the functionality of executing commands using the BLE protocol. BLE is organized around reading and writing parameters or characteristics. For example, the manufacturer command profile 900 and the manufacturer command service 910 include parameter groupings. In some examples, the manufacturer command service 910 restricts access to information or external changes (e.g., from a Figure 1 For example, the field device 102 may implement a security feature that limits read and write capabilities when the field device 102 is in a secure operating mode.

[0190] Fig. 9A The manufacturer command service 910 of the illustrated example includes exemplary industrial protocol characteristics 920 (e.g., industrial protocol TX characteristics, industrial protocol RX characteristics, etc.). The industrial protocol characteristics 920 use opcodes and payloads to support industrial communication protocols such as HART, FOUNDATION Fieldbus, etc. via OTA over a BLE connection. Fig. 9A, an industrial protocol characteristic 920 includes an exemplary declaration structure 922, an exemplary value structure 924, and an exemplary descriptor structure 926. The declaration structure 922 of the illustrated example includes data about the characteristic (e.g., a universally unique identifier (UUID)). The value structure 924 of the illustrated example is a value of the characteristic including data of interest to be transmitted between devices (e.g., firmware data, a pressure value associated with the field device 102, a calibration version value of the field device 102, etc.). The descriptor structure 926 of the illustrated example is used to control the behavior of the industrial protocol characteristic 920 and / or provide additional information corresponding to the industrial protocol characteristic 920. For example, the descriptor structure 926 can be used when disabling or enabling notifications.

[0191] In some examples, commands from the remote device 106 to the field device 102 are sent to the industrial protocol characteristic 920 using a write with a response or a write without a response. In such an example, the field device 102 can respond to the remote device 106 using a notification. For example, a write with a response to the field device 102 is slower and consumes more of the available power budget than a write without a response. In some examples, writing to the field device 102 using a response can be used to evaluate, determine, etc. the BLE connection (e.g., Figure 1 Whether the BLE connection 108 is still active (e.g., operation Figure 1 The user of the remote device 106 does not exit Figure 1 range of the BLE bridge 104).

[0192] In some examples, Figure 1 The remote device 106 determines whether the BLE connection is still active. For example, to save Figure 1 In such an example, the remote device 106 may generate a BLE packet and set the ATT payload to 0 bytes (e.g., Figure 5 The remote device 106 may transmit a first command including a write with a response and a second command including no response. For example, the remote device 106 may transmit a first command including a write with a response and a second command including no response for a large data transfer such as a firmware download to the field device 102. For example, the remote device 106 may transmit a first command for every ten second commands to increase the data rate of the firmware download and reduce the amount of energy used in performing the firmware download.

[0193] Fig. 9A The manufacturer command service 910 includes an exemplary auxiliary command feature 930. The auxiliary command feature 930 uses an opcode and a payload to support auxiliary commands over a BLE connection. For example, an auxiliary command can be a password query (chanllege) for security authentication, device information query, etc. In other examples, the auxiliary command can be a BLE operation such as ping, reboot, restore factory defaults, set device name, turn off (kill) the radio, upload firmware, etc., as shown below in conjunction with Figures 13A-13B In Fig. 9A In FIG. 9 , the auxiliary command property 930 includes a declaration structure 922, a value structure 924, and a descriptor structure 926. Fig. 9A The separation of industrial protocol feature 920 and auxiliary command feature 930 enables fully encrypted messages to be sent directly to Figure 3 The convenience of BLE communication is improved by combining the industrial protocol feature 920 and the auxiliary command feature 930. Figure 3 The security manager 332 must decrypt the message, sort through multiple opcodes (e.g., determine whether the message is an industrial protocol related message or an auxiliary command), re-encrypt the message, and transmit the re-encrypted message to the field device MCU 350. By separating the industrial protocol feature 920 and the auxiliary command feature 930, the BLE bridge 104 can transmit the received encrypted message directly to the field device MCU 350.

[0194] exist Fig. 9A In the example shown, the manufacturer command service 910 includes example flow control characteristics 940 (e.g., RX flow control characteristics, TX flow control characteristics, etc.). In some examples, the flow control characteristics 940 are used to simulate a UART connection. Fig. 9A , the flow control characteristic 940 includes a declaration structure 922, a value structure 924, and a descriptor structure 926. Although the descriptor structure 926 is shown in the industrial protocol characteristic 920, the auxiliary command characteristic 930, and the flow control characteristic 940, the descriptor structure 926 may alternatively be removed from one or more of the industrial protocol characteristic 920, the auxiliary command characteristic 930, or the flow control characteristic 940.

[0195] In some examples, flow control characteristics 940 are used to facilitate communication of large data exchanges (e.g., 100KB, 400KB, etc.) between devices. For example, the RX flow control characteristics included in flow control characteristics 940 can be used to handle the reception of the large data exchange. In other examples, the TX flow control characteristics included in flow control characteristics 940 can be used to handle the transmission of the large data exchange. An exemplary embodiment of a large data exchange is used to transfer firmware information from Figure 1The remote device 106 downloads to Figure 1 For example, the flow control characteristic 940 may include a notification command to start or stop data transmission (e.g., transmit data transmission, receive data transmission, etc.). Figure 1 The field device 102 may use the RX flow control characteristics included in the flow control characteristics 940 to generate data packets and transmit the data packets to Figure 1 of the remote device 106 to begin receiving a data transmission from the remote device 106 at the field device 102 .

[0196] Fig. 9B yes Fig. 9A An exemplary table 950 of an exemplary implementation of the manufacturer command service 910 is shown. Fig. 9B The Table 950 includes Fig. 9A Industrial protocol features 920, auxiliary command features 930, and flow control features 940, wherein TX and RX data streams are combined and / or otherwise integrated. Fig. 9B Each of the industrial protocol characteristics 920, auxiliary command characteristics 930, and flow control characteristics 940 has a corresponding to the client device (e.g., Figure 1 The data flow from a remote device 106 of the field device (e.g., the field device 102) to a field device (e.g., the field device 102) or from a field device to a client device. Each of the characteristics 920, 930, 940 has a characteristic attribute of a write without response / notification. For example, the remote device 106 can transmit a message (e.g., one or more BLE data packets) including a write command to the field device 102, wherein the field device 102 does not respond to the remote device 106 but generates a notification to the remote device 106 that the field device 102 has received the message.

[0197] Fig. 9C yes Fig. 9A An exemplary table 960 of another exemplary implementation of the manufacturer command service 910 in which the TX and RX data streams are separated. Fig. 9C Table 960 includes an exemplary industrial protocol RX characteristic 962, an exemplary industrial protocol TX characteristic 964, an exemplary auxiliary command RX characteristic 966, an exemplary auxiliary command TX characteristic 968, an exemplary flow control RX characteristic 970, and an exemplary flow control TX characteristic 972. For example, Figures 9A-9B The industrial protocol characteristics of 920 can be divided into Fig. 9C Industrial protocol RX characteristics 962 and industrial protocol TX characteristics 964. In other examples, Figures 9A-9B The auxiliary command characteristics 930 can be divided into Fig. 9C Auxiliary command RX characteristics 966 and auxiliary command TX characteristics 968. In other examples, Figures 9A-9BThe flow control characteristics 940 can be divided into Fig. 9C Flow control RX characteristic 970 and flow control TX characteristic 972.

[0198] exist Fig. 9C In the example shown, the data flow is unidirectional. For example, Fig. 9C The characteristics 962, 964, 966, 968, 970, 972 can have client to field device data flow or field device to client data flow. Fig. 9C In the example, the characteristics 962, 964, 966, 968, 970, 972 can have the characteristics of write with response, write without response, or read / notify. For example, the industrial protocol RX characteristic 962 has the characteristics of client to field device data flow and write with response, write without response. In such an example, the industrial protocol RX characteristic 962 facilitates Figure 1 The remote device 106 transmits a message to the field device 102, wherein the message includes a write with a response command or a write without a response command. The write with a response command may correspond to the field device 102 generating a response message and transmitting it to the remote device 106 when the field device 102 receives the message. The write without a response command may correspond to the field device 102 not generating a response message when the field device 102 receives the message. Fig. 9C In the example, the read / notify characteristic attribute may correspond to the field device 102 sending Figure 1 The remote device 106 transmits a message including a read command, wherein the remote device 106 generates a notification message when the remote device 106 receives the message and transmits the notification message to the field device 102.

[0199] Fig.10 is an exemplary table 1000 depicting exemplary attributes (eg, data attributes) 1010, 1020, 1030 corresponding to characteristics of a manufacturer command service, wherein the characteristics include TX and RX characteristics. Fig.10 In the Bluetooth SIG, attributes 1010, 1020, and 1030 use the standard GATT format defined by the Bluetooth Special Interest Group. Fig.10 In Table 1000, Fig. 9A The declaration structure 922, value structure 924, and descriptor structure 926 of the embodiment of the present invention are shown in FIG. 9. In some examples, the declaration structure 922 and the value structure 924 are mandatory, while the descriptor structure 926 is optional.

[0200] exist Fig.10In table 1000 of , declaration structure 922 defines the attributes of value structure 924. Declaration structure 922 includes exemplary declaration attributes 1010, which include exemplary handle field 1012, exemplary type field 1014, exemplary permission field 1016, and exemplary attribute field 1018. For example, Fig. 9A The declaration structure 922 of the industrial protocol characteristic 920 may define the value structure 924 as a read-only permission with no response action based on the information included in the bytes corresponding to the permission field 1016 and the attribute field 1018. Fig.10 In the example shown, the value of the type field 1014 of the declaration structure 922 is 0x2803 (e.g., the first index [0] value 0x03 and the second index [1] value 0x28 are combined to form 0x2803). In such an example, the value of 0x2803 is in little endian format and corresponds to a characteristic declaration having a defined format. Alternatively, an exemplary value may be 0x2802 corresponding to an inclusion declaration, 0x2800 corresponding to a primary service declaration, or 0x2801 corresponding to a secondary service declaration.

[0201] exist Fig.10 In the example shown, the value structure 924 includes a handle field 1012, a type field 1014, a permission field 1016, and an example data field 1019. For example, the remote device 106 can generate a data packet to write to the field device 102 by including a GATT_PERMIT_WRITE_NO_RSP permission in the value structure 924 of the data packet. In such an example, the remote device 106 can write the data included in the data field 1019 to the field device 102. Fig.10 In the example shown, the descriptor structure 926 includes a handle field 1012, a type field 1014, a permission field 1016, and a data field 1019. For example, the remote device 106 can disable notifications on the field device 102 by including a GATT_PERMIT_READ permission in a data packet and including a value of 0x0000 (e.g., a value corresponding to disabling notifications) and transmitting the data packet to the field device 102.

[0202] Fig.11 is an exemplary table 1100 depicting declaration attributes 1010 and value attributes 1020 corresponding to characteristics of a manufacturer command service, where the characteristics separate TX and RX characteristics. Fig.11 Table 1100 may correspond to Fig. 9A The industrial protocol TX characteristics included in the industrial protocol characteristics 920 Fig. 9A The declaration structure 922 and value structure 924, Fig. 9A The auxiliary command TX characteristics included in the auxiliary command characteristics 930, and / or Fig. 9AThe flow control TX characteristics included in the flow control characteristics 940 of FIG. For example, table 1100 may correspond to Fig. 9A The declaration structure 922 and value structure 924 of the industrial protocol characteristic 920.

[0203] Fig.12 Describes the characteristics of the service corresponding to the manufacturer's command Fig.10 1000 of an exemplary table of declaration attributes 1010, value attributes 1020, and descriptor attributes 1030 for a property that separates TX and RX properties. Fig.12 Table 1200 may correspond to Fig. 9A The industrial protocol RX characteristics included in the industrial protocol characteristics 920, Fig. 9A The auxiliary command RX characteristics included in the auxiliary command characteristics 930 and / or Fig. 9A The flow control RX characteristics in the flow control characteristics. Fig.12 Table 1200 includes Fig. 9A The declaration structure 922, value structure 924 and descriptor structure 926 of . For example, table 1200 may correspond to Fig. 9A The declaration structure 922, value structure 924 and descriptor structure 926 of the industrial protocol characteristic 920.

[0204] Fig.13A 1 is an exemplary table 1300 depicting exemplary services 1310 corresponding to application program interface (API) commands. Table 1300 includes services 1310 arranged by category, such as system, GAP, hardware (HW) authentication, login, Diffie-Hellman (DH) key exchange, and over-the-air request (OTAR). Each service 1310 has a corresponding exemplary permission level 1320, 1330, 1340, such as an exemplary user permission level 1320, an exemplary cryptographic (encryption) officer permission level 1330, and an exemplary unauthenticated permission level 1340. For example, a ping service in a system category (e.g., SYSTEM_PING) requires a user permission level to be invoked and / or otherwise accessed.

[0205] In some examples, Fig. 9A The manufacturer command profile 900 can be used Fig.13A For example, the services 1310 listed in the table 1300 of the manufacturer command configuration file 900 are operated Figure 1-Figure 3 The BLE bridge 104 may map the value of the opcode included in the data packet to a permission setting such as a user permission level 1320, a cryptographic officer permission level 1330, and / or an unauthenticated permission level 1340. In some examples, by mapping the available services 1310 to the permission settings, security checks and protocols may be implemented to ensure that Figure 1Safe and reliable operation of the field device 102. Additionally or alternatively, there may be less than or more than Fig.13A The number of services 1310 depicted in Table 1300 .

[0206] Fig. 13B is an exemplary table 1350 depicting an exemplary format of an exemplary API command 1360 and an exemplary API response 1370. The API command 1360 and the API response 1370 may correspond to Fig.13A The check service included in the service 1310. Table 1350 includes a type field, a length field, and a payload field. The type field includes a command (CMD) action and a response (RSP) action. For example, a command action has a byte length of 0x00 and a response action has a byte length of 0x06. Fig. 13B In Table 1350, the payload field includes an opcode field, a byte index field, and a value field. For example, an API command 1360 corresponding to the SYSTEM_PING API includes an opcode value of 0x00, where byte indexes [0-3] correspond to unit32 values ​​corresponding to the number of seconds since the last restart, and byte indexes [4-5] correspond to unit16 values ​​corresponding to the fraction of seconds since the last restart (e.g., 1 / 32768 of the fraction of seconds). For example, the remote device 106 can send a SYSTEM_PING command of the RSP type to the field device 102. In such an example, the field device 102 can transmit a data packet to the remote device 106 that includes a time value corresponding to the seconds and fractions of seconds since the last restart of the field device 102. Fig. 13B In the embodiment, the payload is represented in plain text. Alternatively, the payload may be represented in an encrypted form (eg, cipher text).

[0207] Fig.14 Describe the corresponding Figure 1-3 1400 of a first exemplary timing diagram of a radio initialization task performed by the BLE MCU 104. For example, the first timing diagram 1400 may correspond to initialization Figure 3 The first timing diagram 1400 depicts an exemplary one-shot event 1402 with respect to when to execute. The first timing diagram 1400 depicts Figure 3 Power manager 326, Figure 3 The BLE stack handler 330 and / or Figure 3 When at least one of the command processor 322, protocol handler 324, or security manager 332 is executing one or more computing tasks. Fig.14, the single trigger event 1402 has a first highest priority (e.g., having a priority value of 5), the power manager 326 has a second highest priority (e.g., having a priority value of 4), the BLE stack handler 330 has a third highest priority (e.g., having a priority value of 3), and the command processor 322, the protocol handler 324 and / or the security manager 332 have a fourth highest priority (e.g., having a priority value of 2, less than 2, etc.).

[0208] exist Fig.14 In the example shown, the BLE MCU 104 is powered on and / or otherwise initialized at a first exemplary time (T1). At the first time, the power manager 326 has the second highest priority (e.g., a priority value of 5). At the first time, the power manager 326 sets all other modules of the BLE MCU 104 to idle (e.g., with a priority of -1). For example, the power manager 326 can set the priority of the command processor 322, the BLE stack handler 330, etc. to the lowest priority. After the power manager 326 sets the priority of the BLE MCU 104 module, the power manager 326 places the BLE MCU 104 in an exemplary sleep or idle mode 1404 from the second exemplary time (T2) until the third exemplary time (T3).

[0209] At a third time, a single-trigger event 1402 triggers an interrupt that calls the power manager 326 to become active. For example, assertion of one or both of the comparators 358a-b may generate a hardware interrupt to call the BLE MCU 104 to exit idle mode 1404. In some examples, the single-trigger event 1402 is a clock event (e.g., a rising edge of a clock signal generated by a clock of the BLE MCU 104). In some examples, the single-trigger event 1402 is a power assessment event, such as Figure 3 The state of one or both of the comparators 358a-b may change. For example, the first comparator 358a may change from generating a logic low signal to asserting a logic high signal. Figure 3 The input / output interface 310 may generate an interrupt to invoke the power manager 326 to transition from the sleep mode to the active mode in response to the output of the first comparator 358a transitioning from a logic low signal to a logic high signal.

[0210] In response to the call of the single trigger event 1402 at the third time, the power manager 326 runs from the fourth exemplary time (T4) to the fifth exemplary time (T5). During the time period from the fourth time to the fifth time, the power manager 326 performs one or more operations. For example, the power manager 326 can initialize the power evaluation timer. The power manager 326 can obtain a task queue from the database 335, wherein the task queue includes one or more computing tasks to be performed by the BLE stack handler 330, the security manager 332, etc. The task queue may include one or more initialization tasks to be performed by the BLE stack handler 330, the security manager 332, etc. In other examples, the power manager 326 can determine the power budget of the BLE MCU 104 by performing a power evaluation at the fourth time. For example, the power manager 326 can measure the voltage associated with the power supply 355 by obtaining a digital input signal from the comparator 358a-b to determine the available energy that can be consumed by one or more tasks in the task queue.

[0211] At the fifth exemplary time (T5), the power manager 326 calls the BLE stack handler 330 to initialize. For example, the BLE stack handler 330 may consume energy from the power budget to obtain parameters from the database 335, configure the BLE interface 340, etc. In the first timing diagram 1400, due to the limited power budget provided by the field device 102 to the BLE MCU, the BLE stack handler 330 is initialized after two or more control cycles, including the BLE MCU 104 entering the idle mode 1404 from the sixth exemplary time (T6) to the seventh exemplary time (T7), and completing the initialization at the end of the eighth exemplary time (T8). After the BLE stack handler 330 completes the initialization, the power manager 326 starts to initialize at least one of the command processor 322, the protocol handler 324, or the security manager 332 from the ninth time.

[0212] Fig.15 Depicts the corresponding Figure 1-3 A second exemplary timing diagram 1500 of a radio advertising task performed by the BLE MCU 104 of FIG. 1500 may correspond to Figure 3 BLE interface 340 calls Figure 3 The BLE stack handler 330 is based on Figure 6B The second timing diagram 1500 depicts a time interval during which the BLE stack handler 330, Figure 3 power manager 326, exemplary inter-processor communication (IPC) 1502, or Figure 3The security manager 332 utilizes energy from the power budget allocated to the BLE MCU 104 to perform one or more computing tasks. Fig.15 In the embodiment of the present invention, the IPC 1502 can correspond to the communication between the field device MCU 350 and the BLE MCU 104. For example, the IPC 1502 can correspond to the serial communication facilitated by the SPI bus, UART or I2C bus. Additionally or alternatively, the IPC 1502 can correspond to any other type of processor communication.

[0213] Fig.15 A first exemplary security task 1504 performed by the security manager 332 is further depicted in FIG, which corresponds to a DHE peer (PP) key generation task to update and / or otherwise modify the security key used by the BLE MCU 104. Fig.15 In the example, the first security task 1504 is based on an elliptic curve Diffie-Hellman (ECDH) key exchange using an ephemeral (ECDHE) or temporary key. Since ECDHE is an asymmetric key negotiation security scheme, the public and private keys used in ECDHE are updated periodically to improve security. In some examples, ECDHE is an expensive energy operation. In such an example, the security manager 332 can divide the calculation of the public-private key for updating the BLE MCU 104 into two or more smaller energy-consuming transactions. For example, the security manager 332 can consume 3000 μJ to perform calculations to update the ECDHE public-private key. In such an example, the security manager 332 can divide the 3000 μJ transaction into 100 30 μJ transactions and execute each of the 100 transactions when the power manager 326 determines that there is enough energy for the security manager 332 to execute such a transaction. For example, the security manager 332 can execute one or more of the 100 transactions once a day, once a week, etc. Thus, the security manager 332 may execute the first security task 1504 as a background process or task during an advertising operation or when the BLE interface 340 is disabled.

[0214] At a first exemplary time (T1), the BLE stack handler 330 directs the BLE interface 340 to perform one or more computing tasks. For example, the power manager 326 may identify a radio task (e.g., a radio announcement task) in a task queue and defer a different task in the task queue until the radio task has completed. In the second timing diagram 1500, corresponding to the time from Figure 1 Field equipment 102, Figure 2 The radio notification event of the remote device 200, 202, 204 waiting for the notification of the data of the remote device 106 occurs after the BLE stack handler 330 performs one or more computing tasks. Fig.15, the BLE stack handler 330 completes the notification event at the second exemplary time (T2), the ninth exemplary time (T9), and the sixteenth exemplary time (T16). After the notification event, the power manager 326 calls the BLE MCU 104 to enter the idle mode 1404. At the third exemplary time (T3), the power manager 326 performs one or more computing tasks, such as determining a power budget. For example, the power manager 326 can determine the power budget by (1) subtracting the energy consumed by the BLE stack handler 330 for the notification event from the first time to the second time and (2) adding the supplemental energy from the field device MCU 350 from the second time to the third time.

[0215] At a fourth exemplary time (T4), the power manager 326 invokes the security manager 332 to perform the first security task 1504. For example, the power manager 326 may determine an energy consumption value associated with the first security task 1504 (e.g., by obtaining a corresponding energy consumption value 335 from the database). The power manager 326 may determine that the power budget has sufficient energy that the security manager 332 may consume to perform the first security task 1504 without causing a power outage. Figure 3 The voltage associated with the power supply 355 of the safety task 1504 drops below the low voltage threshold. When the power manager 326 directs the safety manager 332 to execute the first safety task 1504, the power manager 326 commits energy corresponding to the energy consumption value from the power budget to the execution of the first safety task 1504. Therefore, the power manager 326 can subtract the energy consumption value associated with the first safety task 1504 from the power budget.

[0216] Fig.16 Depicts the corresponding Figure 1-3 The third exemplary timing diagram 1600 of the data transmission task performed by the BLE MCU 104 of FIG. The third timing diagram 1600 may correspond to Figure 3 The BLE stack handler 330 calls Figure 3 The BLE interface 340 is connected via Figure 1 The third timing diagram 1600 depicts a time interval during which the BLE stack handler 330, Figure 3 Power manager 326, Fig.15 IPC 1502 or Figure 3 At least one of the security managers 332 utilizes energy of the power budget allocated to the BLE MCU 104 to perform one or more computing tasks.

[0217] Fig.16 Further described in Fig.14 Idle mode 1404, Fig.15 The first safety task 1504 and the second exemplary safety task 1602 executed by the safety manager 332. Fig.15 In the example, the first security task 1504 corresponds to the DHE PP key generation task and the second security task 1602 corresponds to the firmware (FW) SHA-2 signature task. The second security task 1602 may correspond to Figure 3 The second security task 1602 may include at least a first operation and a second operation. In such an example, the first operation may be performed at a fourth exemplary time (T4) and may include downloading a firmware image (e.g., a firmware executable file) and verifying that the firmware image is valid, has not been modified, and is from a known source (e.g., from a known source). Figure 1 The security manager 332 may verify the firmware image by calculating a SHA-2 signature of the firmware image using an elliptic curve digital signature algorithm and verifying the SHA-2 signature using public key cryptography. If the downloaded firmware image is determined to be valid, the security manager 332 may flash the firmware image to a memory (e.g., Figure 3 database 335).

[0218] In some examples, the second operation of the second security task 1602 includes verifying the firmware image flashed when the BLE MCU 104 boots up to confirm that the firmware image has not been altered. Since the verification at boot time is a relatively low-risk security event (e.g., the firmware image is unlikely to change between boots), the security manager 332 can perform the second operation of the second security task 1602 as a background task while the BLE MCU 104 is running. For example, the security manager 332 can calculate a SHA-2 signature of the firmware image flashed to memory and compare the SHA-2 signature to a known SHA-2 signature (e.g., a SHA-2 signature stored in the database 335). In some examples, when the BLE MCU 104 is in the state described above in conjunction with Fig.15 When the second timing diagram 1500 is in the advertising mode, or when the BLE MCU 104 is in the following combination Fig.17 When in the RF disabled mode described by the fourth timing diagram 1700 , the security manager 332 can perform the second operation of the second security task 1602 .

[0219] exist Fig.16In the example shown, the second safety task 1602 is a single trigger event and the first safety task 1504 is a repetitive operation. Fig.16 In the third timing diagram 1600, the BLE stack handler 330 has the first highest priority (e.g., with a priority value of 5), the power manager 326 has the second highest priority, the IPC 1502 has the third highest priority, the second safety task 1602 has the fourth highest priority, and the first safety task 1504 has the fifth highest priority.

[0220] At a first exemplary time (T1), the BLE stack handler 330 directs the BLE interface 340 to perform one or more computing tasks. For example, the power manager 326 may identify radio frequency operations, such as generating and transmitting in a task queue. Figure 6C In such an example, the power manager 326 can postpone one or more different computing tasks in the task queue until after the BLE interface 340 performs the RF operation. In the third timing diagram 1600, the data transmission event occurs after the BLE stack handler 330 completes one or more computing tasks. Fig.16 , the BLE stack handler 330 completes the data transmission event at the second exemplary time (T2) and the tenth exemplary time (T10). At the third exemplary time (T3), the power manager 326 performs one or more computing tasks, such as determining a power budget. For example, the power manager 326 can (1) subtract the energy consumed by the BLE stack handler 330 and the BLE interface 340 for generating and transmitting, receiving one or more data packets, etc., and (2) add supplemental energy supplied to the power supply 355 during the idle mode 1404 from the second time to the third time.

[0221] At a fourth exemplary time (T4), the power manager 326 calls the security manager 332 to execute the second safety task 1602. For example, the power manager 326 may determine an energy consumption value associated with the second safety task 1602 (e.g., by obtaining the energy consumption value from a database). The power manager 326 may determine that the power budget has sufficient energy from which the security manager 332 may consume sufficient energy to execute the second safety task 1602 without powering down the BLE MCU 104. When the power manager 326 directs the security manager 332 to execute the second safety task 1602, the power manager 326 commits energy in the power budget corresponding to the energy consumption value to the execution of the second safety task 1602. Therefore, the power manager 326 may subtract the energy consumption value associated with the second safety task 1602 from the power budget.

[0222] Fig.17 Depicts the corresponding Figure 1-3The BLE MCU 104 in radio disabled mode, RF disabled mode, etc. Figure 3 1700 of a BLE interface 340, wherein the BLE interface 340 is inactive. The fourth timing diagram 1700 may correspond to the security manager 332 performing the first safety task 1504 or the second safety task 1602 when the BLE interface 340 is inactive. The fourth timing diagram 1700 depicts a time interval during which Figure 3 The power manager 326 or Figure 3 At least one of the security managers 332 utilizes energy from the power budget allocated to the BLE MCU 104 to perform one or more computing tasks. Fig.17 In the fourth timing diagram 1700, the BLE stack handler 330 has the first highest priority (e.g., with a priority value of 5), the power manager 326 has the second highest priority, the IPC 1502 has the third highest priority, the second safety task 1602 has the fourth highest priority, and the first safety task 1504 has the fifth highest priority.

[0223] At a second exemplary time (T2), the power manager 326 performs one or more computing tasks, such as determining a power budget. For example, the power manager 326 may determine that the task queue includes a first safety task 1504 and a second safety task 1602 to be executed. The power manager 326 may retrieve the associated energy consumption value from the database 335 and determine whether there is enough energy in the power budget to execute one or both of the safety tasks 1504, 1602.

[0224] At a third exemplary time (T3), the power manager 326 invokes the security manager 332 to execute the second safety task 1602. For example, the power manager 326 may determine that the power budget has sufficient energy that the security manager 332 may use to execute the second safety task 1602 without powering down the BLE MCU 104. When the power manager 326 directs the security manager 332 to execute the second safety task 1602, the power manager 326 uses energy corresponding to the energy consumption value from the power budget for execution of the second safety task 1602. Therefore, the power manager 326 may subtract the energy consumption value associated with the second safety task 1602 from the power budget.

[0225] From the fourth exemplary time (T4) to the fifth exemplary time (T5), the BLE MCU 104 is in the idle mode 1404, and therefore, the BLE MCU 104 does not perform any substantial tasks. Therefore, the supplementary energy provided to the power supply 355 by the constituent field device MCU 350 during this period can replenish the energy consumed by the BLE interface 340 (e.g., the energy consumed from the third time to the fourth time) more quickly because there is no substantial task being performed by the BLE MCU 104. Although the field device MCU 350 can use a constant current source of 0.25 mA, 0.5 mA, etc. to power the power supply 355 (e.g., continuously power it) from the first time to at least the sixteenth exemplary time (T16), the field device MCU 350 can recharge the power supply 355 more quickly when in the idle mode 1404 because there is no substantial task that consumes power.

[0226] At a tenth exemplary time (T10), the power manager 326 performs one or more computing tasks. For example, the power manager 326 may determine a power budget based on at least one of the assertions of the comparators 358a-b or the charging rate of the power source 355. At an eleventh exemplary time (T11), the power manager 326 invokes the security manager 332 to perform the first safety task 1504. For example, the power manager 326 may determine that the power budget has sufficient energy that the security manager 332 may use to perform the first safety task 1504 without causing a voltage associated with the first safety task 1504 to fall below a voltage associated with the first safety task 1504. Figure 3 When the power manager 326 directs the safety manager 332 to execute the first safety task 1504, the power manager 326 commits energy corresponding to the energy consumption value from the power budget to the execution of the first safety task 1504. Therefore, the power manager 326 can subtract the energy consumption value associated with the first safety task 1504 from the power budget.

[0227] Fig.18 It depicts Figure 3 An example table 1800 of example power states (eg, power conditions, power states, etc.) of the power supply 355. Fig.18 The table 1800 includes a first exemplary column 1810, a second exemplary column 1820, and a third exemplary column 1830. Fig.18 , first column 1810 corresponds to a first exemplary value of a first input / output (I / O) measurement of energy storage device 356. For example, Figure 3 The input / output interface 310 can be connected via Figure 3The first comparator 358a obtains the voltage associated with the energy storage device 356 to determine the value in the first column 1810. In such an example, the input / output interface 310 can determine the logic value (e.g., a logic low value, a logic high value, etc.) of an integrated circuit (IC) pin of the power supply 355. For example, the power supply 355 can be an IC having one or more electrical pins, and the input / output interface 310 can measure electrical characteristics, such as current, voltage, etc. from the electrical pins. In such an example, the first output of the first comparator 358a can be coupled to the first IC pin and the second output of the second comparator 358b can be coupled to a second IC pin different from the first IC pin. Fig.18 , second column 1820 corresponds to a second exemplary value of a second I / O measurement of energy storage device 356. For example, input / output interface 310 may be configured to receive a second I / O measurement from Figure 3 The second comparator 358b obtains the voltage associated with the energy storage device 356 to determine the value in the second column 1820.

[0228] exist Fig.18 In the example shown, the values ​​of the first column 1810 and the second column 1820 can be PIN_HIGH or PIN_LOW. For example, (1) the energy storage device 356 can have a first voltage, (2) the first comparator 358a can output a second voltage to the first IC pin based on a comparison of the first voltage with a high voltage threshold, and (3) a third voltage can be output to the second IC pin based on a comparison of the first voltage with a low voltage threshold. When the second voltage corresponds to a logical high, the input / output interface 310 can determine a first I / O measurement value of PIN_HIGH of the first IC pin. When the first voltage of the energy storage device 356 is greater than or equal to the high voltage threshold, the second voltage of the first IC pin can be a logical high, thereby satisfying the high voltage threshold. In other examples, when the first voltage of the energy storage device 356 is less than the high voltage threshold, the input / output interface 310 can determine that the first I / O measurement value is PIN_LOW, and therefore does not satisfy the high voltage threshold.

[0229] In some examples, when the third voltage corresponds to a logical high, the input / output interface 310 determines a second I / O measurement value of PIN_HIGH of the second IC pin. When the first voltage of the energy storage device 356 is greater than or equal to the low voltage threshold so as to meet the low voltage threshold, the third voltage of the second IC pin can be a logical high. In other examples, when the first voltage of the energy storage device 356 is less than the low voltage threshold and therefore does not meet the low voltage threshold, the input / output interface 310 can determine that the second I / O measurement value is PIN_LOW. Alternatively, other values ​​(e.g., current values, voltage values, etc.) and / or other representations of I / O measurement values ​​(e.g., 0, 1, high, low, etc.) can be used for the values ​​of the first column 1810 and / or the second column 1820.

[0230] exist Fig.18 In the example shown, the third column 1830 corresponds to a state of the power supply 355 based on at least one of the first or second I / O measurements of the energy storage device 356. Additionally or alternatively, the state in the third column 1830 may apply to the energy storage device 356. Fig.18 , power manager 326 may determine that power source 355 is in a first state of ENERGY_STATE_HIGH, a second state of ENERGY_STATE_INVALID, a third state of ENERGY_STATE_MEDIUM, or a fourth state of ENERGY_STATE_LOW. Figure 3 The power manager 326 can determine the power state based on measurements from the input / output interface 310 associated with the energy storage device 356. For example, the power manager 326 can determine the power state based on the measurements from the input / output interface 310 associated with the energy storage device 356. Figure 3 The power state is determined by the value generated or otherwise output by one of the first comparator 358a or the second comparator 358b. Alternatively, the third column 1830 and / or the power supply 355 may have a ratio Fig.18 Fewer or more states depicted in .

[0231] exist Fig.18 In the example shown, the power manager 326 may determine that the power state is ENERGY_STATE_HIGH when a first I / O measurement of the energy storage device 356 is PIN_HIGH and a second I / O measurement of the energy storage device 356 is PIN_HIGH. For example, the power manager 326 may determine that the energy storage device 356 is fully charged and / or otherwise fully charged. In such an example, the power manager 326 may determine that the energy storage device 356 is fully charged when the first comparator 358a determines that the voltage of the energy storage device 356 meets a high voltage threshold (e.g., an I / O measurement based on the output of the first comparator 358a is PIN_HIGH) and the voltage of the energy storage device 356 meets a low voltage threshold (e.g., an I / O measurement based on the output of the second comparator 358b is PIN_HIGH).

[0232] exist Fig.18In the example shown, the power manager 326 can determine that the power state is ENERGY_STATE_INVALID when the first I / O measurement of the energy storage device 356 is PIN_HIGH and the second I / O measurement of the energy storage device 356 is PIN_LOW. For example, the power manager 326 can determine that there may be a damaged or impaired component associated with the power supply 355 (e.g., one or both of the comparators 358a-b may be damaged), causing one or both of the comparators 358a-b to produce an incorrect output. In such an example, the power manager 326 can determine that the power supply 355 has an invalid state when the first comparator 358a determines that the voltage of the energy storage device 356 meets the high voltage threshold (e.g., the I / O measurement based on the output of the first comparator 258a is PIN_HIGH) and the voltage of the energy storage device 356 does not meet the low voltage threshold (e.g., the I / O measurement based on the output of the second comparator 358b is PIN_LOW). Therefore, the voltage of the energy storage device 356 cannot be greater than or equal to the high voltage threshold and less than the low voltage threshold, thereby invoking the power manager 326 to determine an invalid energy state or an invalid power state of the power supply 355.

[0233] exist Fig.18 In the example shown, when the first I / O measurement value of the energy storage device 356 is PIN_LOW and the second I / O measurement value of the energy storage device 356 is PIN_HIGH, the power manager 326 can determine that the power state is ENERGY_STATE_MEDIUM. For example, the power manager 326 can determine that the energy storage device 356 is not fully charged but can be charged sufficiently to perform one or more computing tasks. In such an example, when the first comparator 358a determines that the voltage of the energy storage device 356 does not meet the high voltage threshold (e.g., the I / O measurement value based on the output of the first comparator 358a is PIN_LOW) and the voltage of the energy storage device 356 meets the low voltage threshold (e.g., the I / O measurement value based on the output of the second comparator 358b is PIN_HIGH), the power manager 326 can determine that the energy storage device 356 is not fully charged but can be operated to provide sufficient power for one or more computing tasks.

[0234] exist Fig.18In the example shown, when the first I / O measurement value of the energy storage device 356 is PIN_LOW and the second I / O measurement value of the energy storage device 356 is PIN_LOW, the power manager 326 can determine that the power state is ENERGY_STATE_LOW. For example, the power manager 326 can determine that the energy storage device 356 is not fully charged and may not have enough power to perform at least one computing task. In such an example, when the first comparator 358a determines that the voltage of the energy storage device 356 does not meet the high voltage threshold (e.g., the I / O measurement value based on the output of the first comparator 358a is PIN_LOW) and the voltage of the energy storage device 356 does not meet the low voltage threshold (e.g., the I / O measurement value based on the output of the second comparator 358b is PIN_LOW), the power manager 326 can determine that the energy storage device 356 is not fully charged and may not be able to operate to provide enough power for the at least one computing task.

[0235] Fig.19 is a graph depicting the Figure 3 1900 of an exemplary voltage 1902 of a power supply 355. For example, the voltage 1902 may correspond to Figure 3 Alternatively, voltage 1902 may correspond to the output voltage of power supply 355 to BLE bridge 104. Fig.19 , voltage 1902 is described in conjunction with the voltage of energy storage device 356. Fig.19 The discussion of can also apply to the voltage of the output voltage of power supply 355. In some examples, the voltage of energy storage device 356 is the same as the output voltage of power supply 355.

[0236] exist Fig.19 In the illustrated example, at a first exemplary time (T1) 1904, the energy storage device 356 has a current corresponding to V 供应 (V supply ) of the first voltage, where V 供应 is a voltage associated with the power supply of the field device 102. For example, based on the power supply of the field device 102, the capacitance of the energy storage device 356, etc., the first voltage may correspond to the highest voltage value that the energy storage device 356 may have. Fig.19 The voltage V corresponding to 最小 (V min), below which the energy storage device 356 may not be able to provide sufficient power to the BLE bridge 104 to perform at least one computing task. At the first time 1904, based on the first voltage being greater than the high voltage threshold, the first voltage satisfies the high voltage threshold (V_High). At the first time 1904, based on the first voltage being greater than V_Low, the first voltage satisfies the low voltage threshold (V_Low). For example, at the first time 1904, the power manager 326 may determine that the state of the power supply 355 is ENERGY_STATE_HIGH based on the first comparator 358a outputting PIN_HIGH and the second comparator 358b outputting PIN_HIGH.

[0237] exist Fig.19 In the example shown, at a second exemplary time (T2) 1906, the energy storage device 356 has a second voltage that is less than the first voltage at the first time 1904. For example, the BLE bridge 104 may have performed one or more computing tasks corresponding to the amount of energy of the difference between the first voltage and the second voltage. At the second time 1906, based on the second voltage being less than V_High, the second voltage does not satisfy V_High. At the second time 1906, based on the second voltage being greater than V_Low, the second voltage satisfies V_Low. For example, at the second time 1906, the power manager 326 may determine that the state of the power supply 355 is ENERGY_STATE_MEDIUM based on the first comparator 358a outputting PIN_LOW and the second comparator 358b outputting PIN_HIGH.

[0238] exist Fig.19 In the illustrated example, at a third exemplary time (T3) 1908, the energy storage device 356 has a third voltage 1906 that is less than the first voltage at the first time 1904 and greater than the second voltage at the second time. For example, the power manager 326 may have commanded the BLE bridge 104 to enter a sleep mode, idle one or more processor threads, etc., thereby reducing the energy consumed by the BLE bridge 104 to substantially zero and / or otherwise approximately zero. By consuming substantially zero energy when the BLE bridge 104 is idle and / or otherwise substantially inactive, Figure 3 The field device MCU 350 may increase the voltage of the energy storage device 356 by providing power from the field device MCU 350 to the energy storage device 356. The amount of power provided by the field device MCU 350 is depicted as a difference between the second voltage at the second time 1906 and the third voltage at the third time 1908. At the third time 1908, the power manager 326 may determine that the state of the power source 355 is ENERGY_STATE_MEDIUM based on the first comparator 358a output PIN_LOW and the second comparator 358b output PIN_HIGH.

[0239] exist Fig.19 In the example shown, at a fourth exemplary time (T4) 1910, the energy storage device 356 has a fourth voltage that is less than the third voltage at the third time 1908. For example, the BLE bridge 104 may have performed one or more computing tasks that consume an amount of energy corresponding to the difference between the third voltage and the fourth voltage. At the fourth time 1910, based on the fourth voltage being less than V_High, the fourth voltage does not satisfy V_High. At the fourth time 1910, based on the fourth voltage being greater than V_Low, the fourth voltage does not satisfy V_Low. For example, at the fourth time 1910, the power manager 326 may determine that the state of the power supply 355 is ENERGY_STATE_LOW based on the first comparator 358a output signal PIN_LOW and the second comparator 358b output signal PIN_LOW. At the fourth time 1910, the power manager 326 may instruct the BLE bridge 104 to transition to a sleep mode to facilitate recharging of the energy storage device 356 by the field device MCU 350.

[0240] exist Fig.19 In the example shown, at a fifth exemplary time (T5) 1912, the energy storage device 356 has a fifth voltage that is greater than the fourth voltage at the fourth time 1910. For example, the power manager 326 may have the BLE bridge 104 placed in sleep mode, idle one or more processing threads, etc., to reduce the energy consumed by the BLE bridge 104 to substantially zero and / or otherwise approximate zero. In such an example, the field device MCU 350 may increase the voltage of the energy storage device 356 from the fourth voltage to the fifth voltage. The amount of power provided by the field device MCU 350 is described as the difference between the fourth voltage at the fourth time 1910 and the fifth voltage at the fifth time 1912. At the fifth time 1912, the power manager 326 may determine that the state of the power supply 355 is ENERGY_STATE_HIGH based on the first comparator 358a output PIN_HIGH and the second comparator 358b output PIN_HIGH.

[0241] In some examples, at the fifth time 1912, an event, an interrupt, etc. may be generated by one or more processors associated with the BLE bridge 104, which may call the power manager 326 to wake up, become active, resume execution of machine-readable instructions, etc. When the power manager 326 wakes up at the fifth time 1912, the power manager 326 may measure a fifth voltage associated with the energy storage device 356, determine that the fifth voltage satisfies V_High and V_Low, and reset energy parameters (e.g., energy accumulators, energy counters, energy trackers, etc.) to a predefined energy value associated with the power supply 355 in the ENERGY_STATE_HIGH state. Fig.19 In the figure, the predefined energy value is depicted as 380 μJ, which corresponds to a voltage V 最小 The first stored energy of the energy storage device 356 has a voltage V 供应 The energy difference between the second stored energy of the energy storage device 356.

[0242] Fig. 20 is depicted as Figure 3 The charging rate of the power supply 355 is a function of Figure 1-3 BLE Bridge 104 Figure 3 An exemplary diagram 2000 of the data rate of the BLE interface 340 is shown. Fig. 20 In the example of , the BLE bridge 104 allocates and / or otherwise sets the data rate (e.g., data transmission rate, data reception rate, etc.) at a minimum data rate (e.g., a fixed minimum data rate) when the field device MCU 350 charges the power source 355 at a rate of 0.1 mW or less. For example, the power manager 326 can direct Figure 3The BLE handler 330 of the BLE interface 340 reduces the data rate to a data rate of 1-2 messages per second (e.g., 1-2 data packets per second), where each message can correspond to 256 bytes when the charging rate is 0.1mW or less. In such an example, the power manager 326 can call the BLE stack handler 330 to reduce the data rate of the BLE interface 340 from a first data rate to a second data rate by adjusting at least one of the data interval or the number of data packets to be transmitted or received. For example, the BLE handler 330 can reduce the data interval from the first data interval to the second data interval to allow the field device MCU 350 to have more time to charge the power supply 355 between radio frequency operations, wherein the second data interval is longer than the first data interval. In other examples, the BLE handler 330 can split a first radio frequency operation (e.g., a first energy transaction) that transmits a first data packet into two or more radio frequency operations (e.g., at least a second energy transaction and a third energy transaction) to transmit at least a second data packet in a second radio frequency operation and at least a third data packet in a third radio frequency operation. For example, the size of the first data packet may be 10 bytes, while the size of the second data packet and the third data packet may be 5 bytes each. In such an example, the BLE handler 330 may reduce the data rate by splitting the first energy transaction into two or more smaller energy transactions based on an available power budget, which is based on the charging rate of the power source 355. Alternatively, the power manager 326 may call the BLE stack handler 330 to set the minimum data rate of the BLE interface 340 using any other charging rate.

[0243] exist Fig. 20In the example shown, when the charging rate of the power source 355 is 0.3 mW or greater, the BLE bridge 104 sets the data rate of the BLE interface 340 to a maximum data rate (e.g., a fixed maximum data rate). For example, the power manager 326 may direct the BLE handler 330 to increase the data rate of the BLE interface 340 to a data rate of 55-63 messages per second (e.g., a data rate in the range of 14-16 KB / s) by adjusting at least one of the data interval or the number of data packets to be transmitted or received. For example, the BLE handler 330 may increase the data interval from a first data interval to a second data interval to allow the field device MCU 350 more time to charge the power source 355 between RF operations, wherein the second data interval is shorter than the first data interval. In other examples, the BLE handler 330 may combine (1) at least a first RF operation and a second RF operation (e.g., at least a first energy transaction and a second energy transaction) that transmit two or more data packets into (2) a third RF operation (e.g., a third energy transaction) that transmits one data interval. For example, the size of two or more data packets may each be 5 bytes, and the size of the combined data packet may be 10 bytes. In such an example, the BLE handler 330 may increase the data rate by combining the first energy transaction and the second energy transaction into fewer energy transactions based on the available power budget, which is based on the charging rate of the power source 355. Alternatively, the power manager 326 may call the BLE stack handler 330 to set the maximum data rate of the BLE interface 340 using any other charging rate.

[0244] exist Fig. 20 In the example shown, when the charging rate of the power source 355 is within the range between 0.1 mW and 0.3 mW, the BLE bridge 104 adjusts the data rate of the BLE interface 340. For example, the power manager 326 can call the BLE stack handler 330 to modify and / or otherwise adjust the data rate of the BLE interface 340 based on the charging rate of the power source 355. Fig. 20 In the embodiment, the BLE bridge 104 does not increase the data rate of the BLE interface 340 when the charging rate of the power source 355 is greater than 0.3 mW to prevent the BLE bridge 104 from using Figure 3 The field device MCU 350 may require power to execute one or more process control functions of the field device 102. In other examples, the BLE bridge 104 does not increase the data rate to avoid or prevent depletion of all stored energy associated with the power source 355, and therefore, powers down the BLE bridge 104 and / or, more generally, the field device 102.

[0245] Indicates that it is used to implement Figure 1-3Flowcharts, data graphs, and / or state diagrams of exemplary hardware logic, machine-readable instructions, hardware-implemented state machines, and / or any combination thereof of the BLE bridge 104, and / or, more generally, Figure 1-3 The field device 102 is Figure 21-29 The machine-readable instructions may be executed by a computer processor (e.g., Fig.31 The exemplary processor platform 3100 discussed herein may be an executable program or a portion of an executable program executed by the processor 3112 shown in the exemplary processor platform 3100. The program may be embodied in a non-transitory computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with the processor 3112, but the entire program and / or its portion may alternatively be executed by a device other than the processor 3112 and / or embodied in firmware or dedicated hardware. In addition, although the exemplary program is referenced Figure 1-29 The flowcharts, data graphs, and / or state diagrams shown are described, but many other methods of implementing the exemplary BLE bridge 104 and / or more generally, the field device 102 may be used instead. For example, the order of execution of the blocks may be changed, and / or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be constructed by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) to perform the corresponding operations without executing software or firmware.

[0246] As mentioned above, Figure 21-29 The exemplary processes of may be implemented using executable instructions (e.g., computer and / or machine readable instructions) stored on a non-transitory computer and / or machine readable medium (e.g., a hard drive, flash memory, read-only memory, CD, DVD, cache, random access memory, and / or any other storage device or storage disk in which information is stored for any duration (e.g., for an extended period of time, permanently, for a transient instance, for temporary buffering, and / or for caching information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and / or storage disk and does not include propagating signals and does not include transmission media.

[0247] "Include" and "comprising" (and all their forms and tenses) are used herein as open-ended terms. Thus, whenever a claim adopts any form of "include" or "comprising" (e.g., includes, comprises, includes, including, having, etc.) as a preamble or in any type of claim recitation, it should be understood that additional elements, terms, etc. may be present without exceeding the scope of the corresponding claim or recitation. As used herein, when the phrase "at least" is used as a transitional term, such as in the preamble of a claim, it is open-ended in the same manner as the terms "include" and "comprising." The term "and / or" when used in the form of, for example, A, B, and / or C, refers to any combination or subset of A, B, C, such as (1) only A, (2) only B (3) only C, (4) A and B, (5) A and C, (6) B and C, and (7) A and B and C. As used herein in the context of describing structures, components, items, objects, and / or things, the phrase "at least one of A and B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects, and / or things, the phrase "at least one of A or B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the execution or performance of processes, instructions, actions, activities, and / or steps, the phrase "at least one of A and B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the execution or performance of processes, instructions, actions, activities, and / or steps, the phrase "at least one of A or B" is intended to refer to implementations that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.

[0248] Fig.21 It means that Figure 1-3 The BLE bridge 104 and / or more generally, Figure 1-3 An example data flow diagram of example machine readable instructions 2100 executed by a field device 102 to perform one or more power management tasks. Fig.21 The machine readable instructions 2100 include an exemplary main function 2110, one or more exemplary application tasks 2120, an exemplary BLES stack manager task 2130, and an exemplary power manager task 2140. Fig.21 In the embodiment, the main function 2110 includes one or more machine-readable functions, tasks, etc., which, when executed, can enable one or more processors to perform at least one or more computing tasks.

[0249] exist Fig.21 In the example shown, when the main function 2110 is executed, one or more tasks may be executed in sequence. For example, the main function 2110 may execute the function "BLEStackHandler_init();", which, when executed, causes one or more processors to create and / or otherwise start the BLE stack handler task 2130. For example, the BLE stack handler task 2130 may correspond to machine-readable instructions that, when executed, cause one or more processors to execute Figure 3 The BLE stack handler 330. Fig.21 , the BLE stack handler task 2130 is executed first and has a priority value of 5.

[0250] exist Fig.21 In the example shown, the main function 2110 may execute the function "PowerManager_createTask();", which, when executed, causes one or more processors to create and / or otherwise initiate a power manager task 2140. For example, the power manager task 2140 may correspond to machine-readable instructions, which, when executed, causes one or more processors to perform Figure 3 The power manager 326. Fig.21 , power manager task 2140 is executed a second time and has a priority value of 6.

[0251] exist Fig.21 In the example shown, the main function 2110 may execute one or more functions, including "SecurityManager_createTask();", "CommandProcessor_createTask();", and "ProtocolHandler_createTask();", which, when executed, cause one or more processors to start the application task 2120. In some examples, starting a software component, task, etc. may include loading variables (e.g., configuration, parameters, etc.) from a database 335 that may be used by the software component, task, etc. In some examples, "SecurityManager_createTask();" may correspond to machine-readable instructions, which, when executed, cause one or more processors to start and / or otherwise create Figure 3 In other examples, "CommandProcessor_createTask();" may correspond to machine-readable instructions that, when executed, cause one or more processors to start and / or otherwise create Figure 3In other examples, "ProtocolHandler_createTask();" may correspond to machine-readable instructions that, when executed, cause one or more processors to start and / or otherwise create a task. Figure 3 The protocol handler 324 of . Fig.21 Further depicted in the main function 2110 is a function "BIOS_start();", which, when executed, causes one or more processors to start, trigger and / or otherwise start a real-time operating system (RTOS). For example, the main function 2110 can execute the "BIOS_start();" function to instantiate the RTOS of the BLE bridge 104.

[0252] In operation, the field device 102 is powered on and calls the BLE bridge 104 to start operation. When the BLE bridge 104 is turned on, the main function 2110 can execute the "BLEStackHandler_init();" function to initialize the BLE stack handler 330, thereby starting to execute the functions of the BLEStackHandler task 2130, wherein the BLEStackHandler task 2130 may include one or more algorithms, functions, routines, etc. In response to initializing the BLEStackHandler task 2130, the main function 2110 can execute the "PowerManager_createTask();" function to initialize the power manager 326, thereby starting to execute the functions of the power manager task 2140, wherein the power manager task 2140 may include one or more algorithms, functions, routines, etc. In response to initializing the power manager task 2140, the main function 2110 may execute a “SecurityManager_createTask();” function to initialize the security manager 332, thereby starting to execute one or more application tasks 2120, wherein the application tasks 2120 may include one or more algorithms, functions, routines, etc. In response to initializing the security manager 332, the main function 2110 may execute a “CommandProcessor_createTask();” function to initialize the command processor 322, thereby starting to execute one or more application tasks 2120. In response to initializing the command processor 322, the main function 2110 may execute a “ProtocolHandler_createTask();” function to initialize the protocol handler 324, thereby starting to execute one or more application tasks 2120. In response to initializing the protocol handler 324, the main function 2110 may execute a “BIOS_start();” function to initialize the RTOS.

[0253] exist Fig.21In the example shown, the power manager task 2140 includes one or more exemplary functions, including an exemplary "PowerManager_init();" function, an exemplary "EventMsg_pend();" function, and an exemplary "PowerManager_processEventMsg();" function. Alternatively, the power manager task 2140 may include fewer or more functions. Fig.21 , the “PowerManager_init();” function may correspond to starting the power manager task 2140. In some examples, starting the power manager task 2140 may include loading variables (e.g., configurations, parameters, etc.) from the database 335, which the power manager 326 may use to execute one or more algorithms, functions, routines, etc.

[0254] exist Fig.21 In the example shown, the "EventMsg_pend();" function and "PowerManager_processEventMsg();" may be executed by the power manager task 2140 in the exemplary software loop 2150. Fig.21 In the example, the "EventMsg_pend();" function may correspond to a GPIO interrupt, a UART message, an SPI message, etc., to call the power manager 326 to perform one or more computing tasks. In some examples, the "EventMsg_pend();" function may be called when a power evaluation event occurs. Fig.21 In the example, the "PowerManager_processEventMsg();" function may correspond to the power manager 326 performing a power assessment in response to a power assessment event. For example, the power manager 326 may execute "PowerManager_processEventMsg();" to process a power assessment event. In response to processing the power assessment event, the power manager 326 may wait until another call to the "EventMsg_pend();" function is made, or another power assessment event occurs.

[0255] Fig. 22 Depicted Figure 3 The BLE interface 340 and / or more generally Figure 1-3 2200 is an exemplary state diagram of the BLE bridge 104. The state diagram 2200 represents exemplary machine-readable instructions that may be executed by the BLE interface 340 and / or more generally by the BLE bridge 104. Fig. 22In the example shown, the state diagram 2200 includes exemplary states 2210, 2220, 2230, 2240 of the BLE interface 340, including an exemplary initialization state 2210, an exemplary advertising state 2220, an exemplary data transmission state 2230, and an exemplary disabled state 2240. Each of the states 2210, 2220, 2230, 2240 includes a state Figure 3 The state of power supply 355 includes ENERGY_STATE_HIGH, ENERGY_STATE_MEDIUM and ENERGY_STATE_LOW.

[0256] exist Fig. 22 In the example shown, the BLE interface 340 begins in the initialization state 2210. For example, the initialization state 2210 may correspond to implementing Fig.14 In other examples, the initialization state 2210 may correspond to Fig.21 The main function 2110 of the machine readable instructions 2100 executes the "BLEStackHandler_init();" function to trigger Fig.21 The BLEStackHandler task 2130 is implemented Figure 3 The BLE stack handler 330 of the BLE interface 340 is instantiated and / or otherwise initialized. In some examples, the BLE stack handler 330 registers and activates the BLE interface 340 when in the initialization state 2210.

[0257] In some examples, the BLE interface 340 operates based on the state of the power source 355. For example, the BLE handler 330 may set the configuration, parameters, etc. of the BLE interface 340 based on the state. For example, when the state of the power source 355 is ENERGY_STATE_HIGH or high, the BLE handler 330 may set the first data rate of the BLE interface 340 to the maximum data rate.

[0258] exist Fig. 22 In the example shown, when the BLE interface 340 is enabled, the BLE interface 340 moves from the initialization state 2210 to the advertising state 2220. For example, when the power state is ENERGY_STATE_HIGH, the BLE handler 330 can enable the BLE interface 340. In some examples, the advertising state 2220 corresponds to implementing Fig.15 A second timing diagram 1500 is shown. Fig. 22In the embodiment, when the BLE interface 340 is disabled, the BLE interface 340 moves from the initialization state 2210 to the disabled state 2240. For example, when the state of the power source is ENERGY_STATE_LOW, the BLE handler 330 may disable the BLE interface 340.

[0259] exist Fig. 22 In the example shown, when the BLE interface 340 receives the connection request, the BLE interface 340 moves from the advertising state 2220 to the data transmission state 2230. For example, the data transmission state 2230 may correspond to implementing Fig.16 The third timing diagram 1600. Fig. 22 In the embodiment, when the BLE interface 340 is connected to a device (eg Figure 1 When the remote device 106) of the BLE interface 340 is disconnected, the BLE interface 340 moves from the data transmission state 2230 to the notification state 2220. Fig. 22 In the embodiment, when the OTA or OTW capability, operation, etc. of the BLE interface 340 is disabled, the BLE interface 340 moves from the data transmission state 2230 to the disabled state 2240.

[0260] In some examples, the BLE interface 340 and / or more generally the BLE MCU 104 defers one or more types of computing tasks (eg, RF operations, Fig.15 The first security mission 1504, Fig.16 The second security task 1602 of the BLE interface 340 may be executed until the BLE interface 340 moves from the first state to the second state, where the second state is different from the first state. For example, the BLE stack handler 330 and / or more generally the BLE MCU 104 may call and / or otherwise cause the BLE interface 340 to postpone the data transmission state when in the data transmission state. Fig.151504 until the BLE interface 340 transitions from the data transmission state 2230 to the notification state 2220. In some examples, the BLE interface 340 and / or more generally the BLE MCU 104 postpones execution of one or more computing tasks when the power supply 355 is in the first power state until the power supply 355 transitions from the first power state to the second power state, wherein the second power state is different from the first power state. For example, the BLE handler 330 and / or more generally the BLE MCU 104 may call and / or otherwise cause the BLE interface 340 to postpone execution of a radio frequency operation when the power supply 355 is in the ENERGY_STATE_LOW state until the power supply 355 moves from the ENERGY_STATE_LOW state to the ENERGY_STATE_HIGH state. In some examples, the BLE interface 340 and / or more generally the BLE MCU 104 defers execution of one or more computing tasks and / or one or more types of one or more computing tasks while in the first state and the first state until the BLE interface 340 transitions from the first state to the second state and / or from the first power state to the second power state.

[0261] exist Fig. 22 In the example shown, the BLE interface 340 transitions from the disabled state 2240 to the advertising state 2240 when the OTW capability, operation, etc. of the BLE interface 340 is enabled. For example, when the state of the power supply 355 moves from the ENERGY_STATE_LOW state to the ENERGY_STATE_HIGH state, the GPIO interrupt may call the power manager 326 to become active and determine that the state of the power supply 355 is ENERGY_STATE_HIGH. In such an example, the BLE handler 330 may call the BLE interface 340 to transmit one or more BLE data packets.

[0262] exist Fig. 22 , the BLE interface 340 transitions from the advertising state 2240 to the disabled state 2240 when the OTW capability, operation, etc. of the BLE interface 340 is disabled. For example, when the state of the power supply 355 moves from the ENERGY_STATE_HIGH state to the ENERGY_STATE_LOW state, the GPIO interrupt may call the power manager 326 to determine that the state of the power supply 355 is ENEGY_STATE_LOW. In such an example, the BLE handler 330 may shut down the BLE interface 340 and stop the transmission of BLE data packets.

[0263] Fig.23 is a flow chart representing exemplary machine readable instructions 2300 that may be executed by Figure 1-3The BLE bridge 104 performs the Figure 3 The machine-readable instructions 2300 begin at block 2302, where the BLE bridge 104 establishes a security agreement between the field device and the remote device. For example, the security manager 332 ( Figure 3 ) can authorize remote devices 360 ( Figure 3 ) and field device 102 ( Figure 1 ) of field device MCU 350( Figure 3 ) for communication.

[0264] At block 2304, the field device receives a request from the remote device for communication associated with the industrial protocol. For example, the BLE bridge 104 may receive a data packet from the remote device 360 ​​associated with a request from the remote device 360 ​​to obtain data formatted for the HART industrial communication protocol.

[0265] At block 2306, the BLE bridge 104 determines whether the field device supports the industrial protocol. For example, the command processor 322 ( Figure 3 ) can determine that the field device 102 does not support the HART industrial communication protocol. In other examples, the command processor 322 can determine that the field device 102 does support the HART industrial communication protocol.

[0266] If at block 2306, the BLE bridge 104 determines that the field device does not support the industrial protocol, then Fig.23 The machine-readable instructions 2300 of the embodiment of the present invention end. If at block 2306, the BLE bridge 104 determines that the field device supports the industrial protocol, then at block 2308, the field device receives information associated with the industrial protocol from the remote device. For example, the BLE interface 340 ( Figure 3 ) can receive a data packet from a remote device 360 ​​corresponding to an auxiliary command. In such an example, the auxiliary command can correspond to a data packet in a database 335 ( Figure 3 ) stores HART protocol information, such as HART protocol address, HART protocol header information, etc.

[0267] At block 2310 , the field device receives a data packet for processing. For example, the BLE interface 340 may receive a data packet from the remote device 360 ​​, wherein the data packet does not include a HART protocol address, HART protocol header information, and the like.

[0268] At block 2312, the BLE bridge 104 determines whether the data packet corresponds to a transmit (TX) request from the UART or a receive (RX) request from the BLE stack. For example, the command processor 322 may receive a data packet from the field device MCU 350 for transmission to the remote device 360. In such an example, the command processor 322 may determine that the data packet corresponds to a data packet received from the field device MCU 350 on the receiver transmitter to be transmitted to the remote device 360 ​​via the BLE interface 340. In such an example, the command processor 322 may determine that the data packet corresponds to a TX request from the UART. In other examples, the command processor 322 may determine that when the data packet corresponds to a data packet received by the BLE interface 340, the data packet corresponds to a data packet received from the BLE stack (e.g., the BLE handler 330 ( Figure 3 ))'s RX request.

[0269] If at block 2312, the BLE bridge 104 determines that the data packet corresponds to a TX request from the UART, control proceeds to block 2320 to call the protocol handler to process the data packet for the field device. If at block 2312, the BLE bridge 104 determines that the data packet corresponds to an RX request from the BLE stack (e.g., a data packet received at the BLE handler 330 via the BLE interface 340), then at block 2314, the BLE bridge 104 determines whether the opcode is authorized. For example, the command processor 322 can determine that the opcode 0x00 of the data packet is mapped to a permission level of the user, such as Fig.13A and 13B In such an example, the command processor 322 may compare the permission level of the opcode with the permission level of a user connected to the field device 102 (e.g., a user of the remote device 106, the remote device 360, etc.). For example, the command processor 322 may determine that the opcode is not authorized based on the UNAUTHENTICATED permission level of the user of the remote device 106 not matching the USER permission level required to perform the action corresponding to the opcode of the data packet.

[0270] If at block 2314, the BLE bridge 104 determines that the opcode is not authorized, then at block 2316, the BLE bridge 104 rejects the BLE RX reject. For example, the command processor 322 may discard the data packet received from the remote device 360 ​​via the BLE interface 340. In response to rejecting the BLE RX request at block 2316, the BLE bridge 104 transmits an error code to the remote device at block 2318. For example, the protocol handler 324 may generate an error code and transmit the error code to the remote device 360 ​​via the BLE interface 340. In such an example, the error code may indicate to the remote device 360 ​​that the opcode is not authorized, the permission level for processing data packets is not met, etc. In response to transmitting the error code to the remote device at block 2318, Fig.23 Machine readable instructions 2300 end.

[0271] If at block 2314, the BLE bridge 104 determines that the opcode is authorized, control passes to block 2320 to call the platform manager to process the data packet for the field device. An exemplary process that can be used to implement block 2320 is described below in conjunction with Fig.24 For example, the command processor 322 may call the platform manager 320 ( Figure 3 ) of the protocol handler 324 ( Figure 3 ) to generate a HART protocol data packet based on the received BLE data packet and transmit it to the field device MCU 350 using the HART protocol address, HART protocol header information, etc. stored in the database 335. In other examples, the command processor 322 may call the protocol handler 324 to remove the HART protocol address, HART protocol header information, etc. from the data packet received by the field device MCU 350 to generate a shortened industrial protocol data frame. The BLE handler 330 may generate a BLE data packet based on the shortened industrial protocol data frame. The BLE handler 330 may transmit the BLE data packet to the remote device 360 ​​via the BLE interface 340. Advantageously, the BLE bridge 104 can facilitate an increase in process control-related data throughput compared to previous BLE systems by replacing HART protocol information with process control-related data (e.g., pressure values, temperature values, status indicators, etc.). In response to calling the platform manager to process the data packet of the field device at block 2320, Fig.23 Machine readable instructions 2300 end.

[0272] Fig.24 is a flow chart representing exemplary machine readable instructions 2400 that may be executed by Figure 1-3 The BLE bridge 104 executes to call the platform manager to process the data packets of the field devices. Fig.24An exemplary process can be used to implement Fig.23 The machine-readable instructions 2400 begin at block 2402, where the BLE bridge 104 determines a flow path for a data packet. For example, the command processor 322 ( Figure 3 ) can determine whether the data packet corresponds to a TX request from the UART (field device to remote device) or an RX from the BLE stack (remote device to field device). For example, the command processor 322 can determine whether the data packet corresponds to a TX request from the UART (field device to remote device) or an RX from the BLE stack (remote device to field device). Figure 3 ) from the field device MCU350 ( Figure 3 ) received will be transmitted to the remote device 360 ​​( Figure 3 ). In such an example, the command processor 322 may determine that the data packet corresponds to a UART TX request. In other examples, the command processor 322 may determine that the data packet corresponds to a data packet received from the remote device 360 ​​at the BLE interface 340 to be transmitted to the field device MCU 350. In such an example, the command processor 322 may determine that the data packet corresponds to a BLE RX request.

[0273] If at block 2402, the BLE bridge 104 determines that the flow path of the data packet corresponds to an RX request from the BLE stack (e.g., remote device to field device), control proceeds to block 2404. At block 2404, the remote device constructs a shortened industrial protocol data frame without at least one of a protocol address, protocol header information, or protocol-specific data integrity check. For example, the remote device 360 ​​may be based on Fig. 8A BLE data channel packet format 800 is generated Fig. 8A Data packet 801.

[0274] At block 2406 , the remote device sends the shortened industrial protocol data frame to the field device radio. For example, the remote device 360 ​​may transmit the shortened industrial protocol data frame to the field device 102 via the BLE interface 340 .

[0275] At block 2408, the field device receives the shortened industrial protocol data frame and adds the protocol address, protocol header information, and calculates the protocol specific data integrity check. For example, the protocol handler 324 can use the payload from the received shortened industrial protocol data frame and the protocol header information stored in the database 335 ( Figure 3 ) to generate HART protocol data packets.

[0276] At block 2410, the field device BLE MCU sends a complete reconstructed message to the field device MCU. For example, the command processor 322 may send a HART protocol data packet to the field device MCU 350. Alternatively, the BLE bridge 104 may not perform the function of block 1508 and pass the BLE data packet (e.g., opcode, data payload, etc. and / or a combination thereof) to the field device. In response to sending a complete reconstructed message to the field device MCU at block 2410, Fig.24 The machine readable instructions 2400 end. For example, Fig.24 The machine readable instructions can be returned to Fig.23 Machine readable instructions 2300, which may then end.

[0277] If at block 2402, the BLE bridge 104 determines that the flow path of the data packet corresponds to a TX request from a UART (e.g., a field device to a remote device), control proceeds to block 2412. At block 2412, the field device constructs a shortened industrial protocol data frame without at least one of a protocol address, protocol header information, or protocol-specific data integrity check. For example, the protocol handler 324 may be based on Fig. 8A BLE data channel packet format 800 is generated Fig. 8A Data packet 801.

[0278] At block 2414 , the field device sends the shortened industrial protocol data frame to the remote device radio. For example, the BLE bridge 104 may transmit the shortened industrial protocol data frame to the remote device 360 ​​via the BLE interface 340 .

[0279] At block 2416, the remote device receives the shortened protocol data frame and adds the protocol address, protocol header information, and calculates the protocol specific data integrity check. For example, the remote device 360 ​​can use the payload from the received shortened industrial protocol data frame and the protocol address, protocol header information, etc. stored in a database and / or memory included in the remote device 360 ​​to generate a HART protocol data packet.

[0280] At block 2418, the remote device sends the complete reconstructed message to a client application operating and / or otherwise executing on the remote device 360. For example, the remote device 360 ​​may send a HART protocol data packet to an application running on the remote device 360. In response to sending the complete reconstructed message to the client application at block 2418, Fig.24 The machine readable instructions 2400 end. For example, Fig.24 The machine readable instructions 2400 may return to Fig.24 Machine readable instructions 2400, which may then end.

[0281] Fig.25 is a flow chart representing exemplary machine readable instructions 2500 that may be executed by Figure 1-3 The BLE bridge 104 of the machine readable instructions 2500 executes to identify a power assessment event. The machine readable instructions 2500 begin at block 2502, at which time the BLE bridge 104 determines the mode of the field device. For example, the power manager 326 ( Figure 3 ) can be determined Figure 1-2 The field device 102 is in maintenance mode. In such an example, the field device MCU 350 can disable one or more control functions of the BLE bridge 104. Fig.26 An example process that may be used to implement block 2502 is described.

[0282] At block 2504, the BLE bridge 104 determines the energy stored in the power supply of the BLE bridge. For example, the power manager 326 may obtain the energy from Figure 3 The outputs of the comparators 358a-b are used to determine whether the BLE bridge 104 or a component of the BLE bridge 104 (e.g., the BLE interface 340 ( Figure 3 ))Power supply 355( Figure 3 ) associated voltage.

[0283] At block 2506, the BLE bridge 104 determines whether the stored energy meets the high energy threshold. For example, the first comparator 358a can compare the voltage of the energy storage device 356 with a high voltage threshold corresponding to the high energy threshold, and determine that the voltage meets the high voltage threshold based on the voltage being greater than the high voltage threshold. In such an example, the first comparator 358a can generate a logic high signal and the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_HIGH based on the logic high signal. In other examples, the first comparator 358a can compare the voltage with the high voltage threshold and determine that the voltage does not meet the high voltage threshold based on the voltage being less than the high voltage threshold.

[0284] If at block 2506, the BLE bridge 104 determines that the stored energy meets the high energy threshold, control proceeds to block 2512 to identify a power assessment event. If at block 2506, the BLE bridge 104 determines that the stored energy does not meet the high energy threshold, then at block 2508, the BLE bridge 104 determines whether the stored energy meets the low energy threshold. For example, the second comparator 358b can compare the voltage of the energy storage device 356 with a low voltage threshold corresponding to the low energy threshold, and determine that the voltage meets the low voltage threshold based on the voltage being greater than the low voltage threshold. In such an example, the second comparator 358b can assert a logic high signal and the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_LOW based on the logic high signal. In other examples, the second comparator 358b can compare the voltage with the low voltage threshold and determine that the voltage does not meet the low voltage threshold based on the voltage being less than the low voltage threshold. In such an example, the second comparator 358b may generate a logic low signal and the power manager 326 may determine that the state of the power source 355 is ENERGY_STATE_LOW based on the logic low signal.

[0285] If at block 2508, the BLE bridge 104 determines that the stored energy meets the low energy threshold, control proceeds to block 2512 to identify a power assessment event. If at block 2508, the BLE bridge 104 determines that the stored energy does not meet the low energy threshold, at block 2510, the BLE bridge 104 determines whether the charging rate meets the charging rate threshold. For example, the power manager 326 can determine that the charging rate of the power source 355 by the field device MCU 350 is 0.2 mW based on the SPI message from the field device MCU 350. In such an example, the power manager 326 can compare the charging rate of 0.4 mW with the charging rate threshold of 0.3 mW, and determine that the charging rate meets the charging rate threshold based on the charging rate being greater than the charging rate threshold.

[0286] If at block 2510, the BLE bridge 104 determines that the charging rate does not meet the charging rate threshold, control proceeds to block 2516 to determine whether to continue monitoring the field device. If at block 2510, the BLE bridge 104 determines that the charging rate meets the charging rate threshold, at block 2512, the BLE bridge 104 identifies a power assessment event. For example, the power manager 326 can determine that the state of the power source 355 has changed.

[0287] At block 2514, the BLE bridge 104 performs a power assessment. For example, the power manager 326 may calculate the available power budget of the BLE bridge 104 and adjust the parameters of the BLE interface 340 based on the available power budget. An exemplary process that may be used to implement block 2514 is described below in conjunction with Fig.25 Give a description.

[0288] At block 2516, the BLE bridge 104 determines whether to continue monitoring the field device. For example, the power manager 326 may determine to continue monitoring the voltage of the power supply 355 of the field device 102. If at block 2516, the BLE bridge 104 determines to continue monitoring the field device, control returns to block 2502 to determine the mode of the field device, otherwise Fig.25 The machine readable instructions 2500 end.

[0289] Fig.26 is a flow chart representing example machine readable instructions 2600 that may be executed by Figure 1-3 The BLE bridge 104 executes to determine the mode of the field device. Fig.26 An exemplary process can be used to implement Fig.25 Operation of block 2502. Fig.26 The machine readable instructions 2600 of FIG. 26 begin at block 2602, where the BLE bridge 104 determines the energy stored in the power supply for the BLE bridge. For example, the power manager 326 may obtain the energy from Figure 3 The outputs of the comparators 358a-b are used to determine whether the BLE bridge 104 or a component of the BLE bridge 104 (e.g., the BLE interface 340 ( Figure 3 ))Power supply 355( Figure 3 ) associated voltage.

[0290] At block 2604, the BLE bridge 104 determines whether the field device is in maintenance mode. For example, the power manager 326 may query the database 335 ( Figure 3 ) to determine that the field device 102 is in maintenance mode. If at block 2604, the BLE bridge 104 determines that the field device is not in maintenance mode, control proceeds to block 2610 to determine whether the field device is in safety mode. If at block 2604, the BLE bridge 104 determines that the field device is in maintenance mode, then at block 2606, the BLE bridge 104 disables the radio transmission function. For example, the power manager 326 may direct the BLE handler 330 ( Figure 3 ) disable one or more functions of the BLE interface 340.

[0291] At block 2608, the BLE bridge 104 reallocates power from the disabled functions to the BLE bridge. For example, the power manager 326 may reallocate power corresponding to one or more disabled functions of the BLE interface 340 to the platform manager 320 ( Figure 3). For example, the BLE handler 330 may disable the data transmission capability of the BLE interface 340 and reallocate the power associated with the disabled capability to the command processor 322, the protocol handler 324, the security manager 332, and the like.

[0292] At block 2610, the BLE bridge 104 determines whether the field device is in a safe mode. For example, the power manager 326 may query the database 335 ( Figure 3 ) to determine that the field device 102 is in a secure mode. If at block 2610, the BLE bridge 104 determines that the field device is not in a secure mode, then Fig.26 The machine readable instructions 2600 end. For example, control may be returned to Fig.25 At block 2504, the BLE bridge 104 determines the power supply voltage to the BLE bridge. If at block 2610, the BLE bridge 104 determines that the field device is in a safe mode, then at block 2612, the BLE bridge 104 disables write access to selected field device parameters. For example, the power manager 326 may prohibit write access to one or more parameters (e.g., firmware version, calibration version, error log, BLE interface transmission power, etc., and / or combinations thereof) of the BLE bridge 104, the field device 102, etc. In response to disabling write access to selected field device parameters, Fig.26 The machine readable instructions 2600 end. For example, control may be returned to Fig.25 Block 2504 determines the supply voltage to the BLE bridge.

[0293] Fig. 27 is a flow chart representing example machine readable instructions 2700 that may be executed by Figure 1-3 The BLE bridge 104 of the embodiment executes to perform a power assessment event and adjust the BLE radio device (e.g., the BLE interface 340 ( Figure 3 ))'s parameters. Fig. 27 An exemplary process may be used to implement Fig.25 The machine-readable instructions 2700 begin at block 2702, where the BLE bridge 104 determines the energy stored in the power supply for the BLE bridge. For example, the power manager 326 may obtain the energy from Figure 3 The outputs of the comparators 358a-b are used to determine whether the BLE bridge 104 or a component of the BLE bridge 104 (e.g., the BLE interface 340 ( Figure 3 ))Power supply 355( Figure 3 ) associated voltage.

[0294] At block 2704, the BLE bridge 104 determines the radio transmission rate. For example, the power manager 326 may measure the radio transmission rate of the BLE interface 340 in bytes / second, kilobytes / second, etc. At block 2706, the BLE bridge 104 calculates the radio energy consumption. For example, the power manager 326 may calculate the radio energy consumption of the BLE interface 340 as described above according to equation (1) and / or equation (2).

[0295] At block 2708, the BLE bridge 104 measures the energy stored in the power source via the input / output interface or infers from the input power and the output power using a Kalman filter. For example, the power manager 326 may measure the energy stored in the power source via the input / output interface 310 ( Figure 3 ) determine the amount of energy stored in the power source 355 and / or based on Figure 1-2 The input power and output power of the field devices are inferred using a Kalman filter.

[0296] At block 2710, the BLE bridge 104 determines the requested amount of communication data and the data rate required to support the request. For example, the power manager 326 may determine that Figure 1-2 The amount of data transmitted by the remote device 106 to the field device 102 and the corresponding data rate to support the transmission.

[0297] At block 2712, the BLE bridge 104 calculates the maximum transmission rate for the existing power budget. For example, the power manager 326 can calculate the maximum data transmission rate for the available power budget allocated to the BLE interface 340. In such an example, the power manager 326 can determine the state of the power source 355 based on the voltage of the power source 355 and map the state to a data rate of the BLE interface 340, such as a minimum data rate, a maximum data rate, a data rate within a range from the minimum data rate to the maximum data rate, etc.

[0298] At block 2714, the BLE bridge 104 adjusts the RX / TX radio parameters. For example, the power manager 326 may increase the antenna power of the BLE interface 340 based on the maximum transmission rate, the available power budget, the amount of data to be transmitted, etc. and / or a combination thereof. In other examples, the power manager 326 may decrease the antenna power of the BLE interface 340 based on the minimum transmission rate, the available power budget, the amount of data to be transmitted, etc. and / or a combination thereof.

[0299] At block 2716, the BLE bridge 104 adjusts the power assessment event timer based on the existing power budget. For example, the power manager 326 may adjust the time between power assessment events as described above according to equation (5). In response to adjusting the power assessment event timer, Fig. 27The machine readable instructions 2700 end. For example, control may be returned to Fig.25 Block 2516 is used to determine whether to continue monitoring the field device.

[0300] Figures 28A-28B A flowchart representing exemplary machine readable instructions 2800 is depicted, which may be executed by Figure 1-3 The BLE bridge 104 performs to determine Figure 3 The state of the power supply 355 and adjust the BLE radio device (e.g., the BLE interface 340 ( Figure 3 ))'s parameters. Figures 28A-28B The machine-readable instructions 2800 of the embodiment of the present invention begin at block 2802, when the BLE bridge 104 obtains a first measurement value associated with the voltage of the power supply 355 to the BLE bridge 104 from the first comparator 358a. For example, the power manager 326 can call the input / output interface 310 to measure a first voltage at a first IC pin of the power supply 355. In such an example, the power manager 326 can determine that the first voltage at the first IC pin corresponds to a logic high signal, a logic low signal, etc., where the first voltage indicates the voltage of the energy storage device 356.

[0301] At block 2804, the BLE bridge 104 obtains a second measurement value associated with the voltage of the power supply 355 to the BLE bridge 104 from the second comparator 358b. For example, the power manager 326 may call the input / output interface 310 to measure a second voltage at a second IC pin of the power supply 355. In such an example, the power manager 326 may determine that the second voltage at the second IC pin corresponds to a logic high signal, a logic low signal, etc., wherein the second voltage indicates the voltage of the energy storage device 356.

[0302] At block 2806, the BLE bridge 104 determines whether the power supply voltage satisfies the high voltage threshold and does not satisfy the low voltage threshold. For example, the power manager 326 may determine that the first voltage corresponds to a logical high and therefore satisfies the high voltage threshold (e.g., the first comparator 358a asserts a logical high signal when the voltage of the energy storage device 356 is greater than the high voltage threshold). In such an example, the power manager 326 may determine that the second voltage corresponds to a logical low and therefore does not satisfy the low voltage threshold (e.g., the second comparator 358b is generating a logical low signal when the voltage of the energy storage device 356 is below the low voltage threshold). When the power manager 326 determines that the voltage of the energy storage device 356 satisfies the high voltage threshold but does not satisfy the low voltage threshold, the power manager 326 determines that the power supply 355 is in an invalid state.

[0303] If at block 2806, the BLE bridge 104 determines that the power supply voltage satisfies the high voltage threshold and does not satisfy the low voltage threshold, then at block 2808, the BLE bridge 104 determines that the power supply voltage state is ENERGY_STATE_INVALID. For example, the power manager 326 may determine that the state of the power supply 355 is invalid. In response to determining that the power supply state is ENERGY_STATE_INVALID at block 2808, then, at block 2810, the BLE bridge 104 determines whether the power supply voltage satisfies the high voltage threshold and the low voltage threshold.

[0304] If at block 2806, the BLE bridge 104 determines that the power supply voltage does not meet the high voltage threshold or meets the low voltage threshold, control proceeds to block 2810 to determine whether the power supply voltage meets the high voltage threshold and the low voltage threshold. For example, the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_HIGH when the voltage of the energy storage device 356 meets the high voltage threshold and the low voltage threshold.

[0305] If at block 2810, the BLE bridge 104 determines that the power supply voltage does not meet the high voltage threshold or the low voltage threshold, control proceeds to block 2816 to determine whether the power supply voltage does not meet the high voltage threshold and meets the low voltage threshold. If at block 2810, the BLE bridge 104 determines that the power supply voltage meets the high voltage threshold and the low voltage threshold, at block 2812, the BLE bridge 104 determines that the power state is ENERGY_STATE_HIGH. For example, the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_HIGH when the voltage of the energy storage device 356 meets the high voltage threshold and the low voltage threshold.

[0306] In response to determining that the power state is ENERGY_STATE_HIGH at block 2812, the BLE bridge 104 enables the BLE radio device at block 2814 to perform one or more data transmission tasks. For example, the power manager 326 can allocate a portion of the power budget to the BLE stack handler 330 to call the BLE interface 340 to transmit one or more BLE data packets, receive one or more BLE data packets, etc. In such an example, the power manager 326 can determine the amount of energy associated with each data transmission task. The power manager 326 can subtract the total amount of energy associated with one or more data transmission tasks from the power budget. In some examples, the power manager 326 can idle the BLE bridge 104 by transitioning the BLE bridge 104 to a sleep mode, an idle mode, etc. to recharge the power supply 355 and / or otherwise replenish the consumed energy. In other examples, the power manager 326 can determine that one or more computing tasks, data transmission tasks, etc. can be performed based on the remaining power budget.

[0307] In response to enabling the BLE radio to perform one or more data transmission tasks at block 2814, the BLE bridge 104 determines whether the power supply voltage does not satisfy the high voltage threshold and satisfies the low voltage threshold at block 2816. For example, the power manager 326 may determine that the state of the power supply 355 is ENERGY_STATE_MEDIUM when the voltage of the energy storage device 356 does not satisfy the high voltage threshold but satisfies the low voltage threshold.

[0308] If at block 2816, the BLE bridge 104 determines that the power supply voltage meets the high voltage threshold or does not meet the low voltage threshold, control proceeds to block 2822 to determine whether the power supply voltage does not meet the high voltage threshold or the low voltage threshold. If at block 2816, the BLE bridge 104 determines that the power supply voltage does not meet the high voltage threshold and meets the low voltage threshold, at block 2818, the BLE bridge 104 determines that the power state is ENERGY_STATE_MEDIUM. For example, the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_MEDIUM when the voltage of the energy storage device 356 does not meet the high voltage threshold but meets the low voltage threshold. In response to determining that the power state is ENERGY_STATE_MEDIUM at block 2818, the BLE bridge 104 disables the BLE radio device at block 2820. For example, the power manager 326 may idle the BLE bridge 104 to recharge the power source 355 by disabling the BLE interface 340 so that the voltage of the power source 355 meets the high voltage threshold.

[0309] At block 2822, the BLE bridge 104 determines whether the power supply voltage does not meet the high voltage threshold or the low voltage threshold. For example, the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_LOW when the voltage of the energy storage device 356 does not meet the high voltage threshold or the low voltage threshold. If at block 2822, the BLE bridge 104 determines that the power supply voltage meets at least one of the high voltage threshold or the low voltage threshold, control proceeds to block 2828 to continue monitoring the power supply. If at block 2822, the BLE bridge 104 determines that the power supply voltage does not meet the high voltage threshold or the low voltage threshold, then at block 2824, the BLE bridge 104 determines that the state of the power supply 355 is ENERGY_STATE_LOW. For example, the power manager 326 can determine that the state of the power supply 355 is ENERGY_STATE_LOW when the voltage of the energy storage device 356 does not meet the high voltage threshold or the low voltage threshold. In response to determining at block 2824 that the power state is ENERGY_STATE_LOW, the BLE bridge 104 disables the BLE radio at block 2826. For example, the power manager 326 may idle the BLE bridge 104 by disabling the BLE interface 340 to recharge the power source 355 so that the voltage of the power source 355 meets the high voltage threshold.

[0310] In response to disabling the BLE radio at block 2826, the BLE bridge 104 determines whether to continue monitoring the power supply at block 2828. For example, the power manager 326 may determine not to continue monitoring the power supply 355 by entering a sleep mode, an idle mode, etc., and resume monitoring the power supply when a power supply evaluation event occurs. In other examples, the power manager 326 may determine to continue monitoring the power supply 355 until entering a sleep mode, an idle mode, etc.

[0311] If at block 2828, the BLE bridge 104 determines to continue monitoring the power supply, control returns to block 2802 to obtain another measurement associated with the voltage of the power supply to the BLE bridge from the first comparator. If at block 2828, the BLE bridge 104 determines not to continue monitoring the power supply, then Figures 28A-28B The machine readable instructions 2800 end. For example, the power manager 326 can direct the BLE bridge 104 to enter a sleep mode, an idle mode, etc. until a power assessment event occurs.

[0312] Fig.29 A flowchart representing exemplary machine readable instructions 2900 is depicted, which may be executed by Figure 1-3 The BLE bridge 104 executes to process one or more computing tasks based on a power budget. Fig.29The machine readable instructions 2900 of FIG. 2904 begin at block 2902, where the BLE bridge 104 determines a power budget. For example, the power manager 326 ( Figure 3 ) can be based on the power stored in the power supply 355 ( Figure 3 ) in an energy associated with the BLE interface 340 or a charging rate of the power source 355 to determine the power budget.

[0313] At block 2904, the BLE bridge 104 identifies computing tasks in the task queues to be processed. For example, the power manager 326 may identify a first set of one or more computing tasks in a first task queue associated with a first priority and / or a second set of one or more computing tasks in a second task queue associated with a second priority, wherein the second priority is lower than the first priority.

[0314] At block 2906, the BLE bridge 104 determines whether to divide the computing task. For example, the power manager 326 can determine whether to divide the first computing task in the first set into at least a second computing task and a third computing task based on the power budget. In other examples, the power manager 326 can determine (1) not to divide the first computing task in the first set based on the first priority and / or (2) to divide the fourth computing task in the second set into at least a fifth computing task and a sixth computing task based on the second priority. In such an example, the power manager 326 can determine not to divide the first computing task because the first computing task has a higher priority than the fourth computing task.

[0315] If at block 2906, the BLE bridge 104 determines not to divide the computing tasks based on the power budget, control proceeds to block 2910 to perform one or more computing tasks. If at block 2906, the BLE bridge 104 determines to divide the computing tasks based on the power budget, the BLE bridge 104 divides the computing tasks at block 2908. For example, the power manager 326 can divide the fourth computing task in the second set into at least a fifth computing task and a sixth computing task based on the second priority.

[0316] At block 2910, the BLE bridge 104 performs a computing task. For example, the BLE handler 330 ( Figure 3 ) can call BLE interface 340( Figure 3 ) to perform radio frequency operations (e.g., transmitting BLE data packets, receiving BLE data packets, etc.). In other examples, the power manager 326 can generate a thread (e.g., a safety task processor thread) to call the security manager 332 ( Figure 3 ) to perform the fifth computing task. For example, the fifth computing task may correspond to Fig.15 The first security task is 1504.

[0317] At block 2912, the BLE bridge 104 calls the BLE radio to enter sleep mode. For example, the power manager 326 may call Figure 1-3 The BLE MCU 104 transitions from an operating mode to a sleep mode (e.g., Fig.14 In such an example, the energy storage device 356 ( Figure 3 ) can be charged while in sleep mode to meet high energy thresholds.

[0318] At block 2914, the BLE bridge 104 determines whether the measurement associated with the power source meets the threshold. For example, when the first comparator 358a asserts a logic high in response to meeting the high energy threshold, the input / output interface 310 ( Figure 3 ) may generate a hardware interrupt that invokes the power manager 326. In such an example, the power manager 326 may determine to invoke the BLE bridge 104 to transition from a sleep mode to an operational mode.

[0319] At block 2916, the BLE bridge 104 calls the BLE radio device to transition from the sleep mode to the operating mode. For example, the BLE handler 330 can call the BLE interface 340 to perform radio frequency operations (e.g., transmit BLE data packets, receive BLE data packets, etc.). In other examples, the power manager 326 can call the security manager 332 to perform the sixth computing task. For example, the sixth computing task can correspond to Fig.16 The second safety task 1602. In response to calling the BLE radio device to transition from the sleep mode to the operation mode, Fig.29 The machine readable instructions 2900 return to block 2902 to determine the power budget. For example, the power manager 326 may determine the power budget by subtracting the amount of first energy associated with one or more computing tasks being executed and by adding the amount of first energy associated with charging the power source 355 based on the charging rate of the field device MCU 350 ( Figure 3 ) is used to determine the power budget.

[0320] Fig.30 The diagram shows a method for implementing Figure 1 remote device 106, Figure 2 Remote devices 200, 202, 204 and / or Figure 3 106 of the remote device 106. The machine-readable instructions may be a flowchart of an exemplary hardware logic, machine-readable instructions, hardware-implemented state machine, and / or any combination thereof ... Fig.32The exemplary processor platform 3200 discussed herein may be an executable program or a portion of an executable program executed by the processor 3212 shown in the exemplary processor platform 3200. It may be embodied in software stored on a non-transitory computer-readable storage medium (e.g., a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with the processor 3212), but the entire program and / or its portions may alternatively be executed by a device other than the processor 3212 and / or embodied in firmware or dedicated hardware. In addition, although the exemplary program is referenced Fig.30 , but can be implemented using Figure 1 remote device 106, Figure 2 Remote devices 200, 202, 204 and / or Figure 3 Many other methods of remote device 360 ​​of the present invention may be described. For example, the order of execution of the blocks may be changed, and / or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be constructed by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) to perform the corresponding operations without executing software or firmware. As described above, Fig.30 The exemplary processes may be implemented using executable instructions (e.g., computer and / or machine readable instructions) stored on a non-transitory computer and / or machine readable medium (e.g., a hard drive, flash memory, read-only memory, CD, DVD, cache, random access memory, and / or any other storage device or storage disk), where information is stored for any duration (e.g., for an extended period of time, permanently, for a transient instance, for temporary buffering, and / or for caching information).

[0321] Fig.30 is a flow chart representing exemplary machine readable instructions 3000 that may be executed by Figure 1 remote device 106, Figure 2 Remote devices 1-3 200, 202, 204 and / or Figure 3 The remote device 360 ​​executes to use BLE to perform communication with the field device 102 Figure 1 , Figure 2 and / or Figure 3 Communication operations between at least one of the remote devices 106, 200, 202, 204, 360. Fig.30 The machine readable instructions 3000 of the embodiment of the present invention begin at block 3002, at which time the remote device establishes a security protocol between the field device and the remote device. For example, the security manager 332 ( Figure 3 ) can authorize remote devices 360 ( Figure 3 ) and field device 102 ( Figure 1 ) of field device MCU 350( Figure 3 ) for communication.

[0322] At block 3004, the remote device transmits a request to the field device for communications associated with the industrial protocol. For example, the remote device 360 ​​may transmit a data packet to the field device 102, wherein the data packet corresponds to a request by the remote device 360 ​​to obtain data formatted for the HART industrial communication protocol.

[0323] At block 3006, the remote device determines whether the field device supports the industrial protocol. For example, the remote device 360 ​​can obtain a data packet (e.g., an error message) from the field device 102 indicating that the field device 102 does not support the HART industrial communication protocol. In other examples, the remote device 360 ​​can obtain a data packet (e.g., a confirmation message) from the field device 102 indicating that the field device 102 supports the HART industrial communication protocol.

[0324] If at block 3006, the remote device determines that the field device does not support the industrial protocol, then the machine readable instructions 3000 of FIG. 3000 end. If at block 3006, the remote device determines that the field device supports the industrial protocol, then at block 3008, the remote device transmits information associated with the industrial protocol to the field device. For example, the remote device 360 ​​may send a BLE interface 340 ( Figure 3 ) transmits a data packet corresponding to the auxiliary command. In such an example, the auxiliary command may correspond to instructing the BLE bridge 104 to store HART protocol information such as a HART protocol address, HART protocol header information, etc. in the database 335 ( Figure 3 )middle.

[0325] At block 3010, the remote device opens a data channel (e.g., an encrypted and authenticated data channel) to facilitate communication using BLE data packets. For example, the remote device 360 ​​can generate a BLE data packet to transmit to the field device 102. In other examples, the remote device 360 ​​can receive a BLE data packet from the field device 102.

[0326] At block 3012, the remote device determines the flow path of the BLE data packet processed by the remote device. For example, the remote device 360 ​​can determine whether the data packet corresponds to an RX request from the field device 102 (field device to remote device) or a TX request from the remote device 360 ​​to the field device 102 (remote device to field device).

[0327] If at block 3012, the remote device determines that the flow path of the data packet corresponds to a TX request (e.g., remote device to field device), control proceeds to block 3014. At block 3014, the remote device constructs a shortened industrial protocol data frame without at least one of a protocol address, protocol header information, or protocol-specific data integrity check. For example, the remote device 360 ​​may be based on Fig. 8A BLE data channel packet format 800 is generated Fig. 8A Data packet 801.

[0328] At block 3016 , the remote device sends the shortened industrial protocol data frame to the field device radio. For example, the remote device 360 ​​may transmit the shortened industrial protocol data frame to the field device 102 via the BLE interface 340 .

[0329] At block 3018, the field device receives the shortened industrial protocol data frame and adds the protocol address, protocol header information, and calculates the protocol specific data integrity check. For example, the protocol handler 324 ( Figure 3 ) can use the payload from the received shortened industrial protocol data frame and the data stored in the database 335 ( Figure 3 ) to generate HART protocol data packets.

[0330] At block 3020, the field device BLE MCU sends the complete, reconstructed message to the field device MCU. For example, the command processor 322 may send a HART protocol data packet to the field device MCU 350. Alternatively, the BLE bridge 104 may not perform the functions of block 3018 and pass the BLE data packet (e.g., opcode, data payload, and / or a combination thereof) to the field device MCU 350. In response to sending the complete, reconstructed message to the field device MCU at block 3020, Fig.30 Alternatively, in response to sending a shortened industrial protocol data frame to the field device MCU 350, Fig.30 The machine readable instructions 3000 may end.

[0331] If at block 3012, the remote device determines that the flow path of the data packet processed by the remote device corresponds to the RX request (e.g., field device to remote device), control proceeds to block 3022. At block 3022, the remote device receives the shortened protocol data frame and adds the protocol address, protocol header information, and calculates the protocol specific data integrity check. For example, the remote device 360 ​​can generate a HART protocol data packet using the payload from the received shortened industrial protocol data frame and the protocol address, protocol header information, etc. stored in a database and / or a memory included in the remote device 360.

[0332] At block 3024, the remote device sends the complete, reconstructed message to a client application running on and / or otherwise executed by the remote device. For example, the remote device 360 ​​may send a HART protocol data packet to an application running on the remote device 360. In response to sending the complete, reconstructed message to the client application at block 3028, Fig.30 The machine readable instructions 3000 end.

[0333] Fig.31 is constructed to execute Figure 21-29 Instructions to achieve Figure 1-3 1 is a block diagram of an exemplary processor platform 3100 of the BLE bridge 104. The processor platform 3100 may be, for example, a field device controller, a controller, a valve positioner, or any other type of computing device and / or process control device.

[0334] The processor platform 3100 of the illustrated example includes a processor 3112. The processor 3112 of the illustrated example is hardware. For example, the processor 3112 may be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor-based (e.g., silicon-based) device. In this example, the processor 3112 implements Figure 3 The platform manager 320, command processor 322, protocol handler 324, power manager 326, RX / TX interface processor 328, BLE handler 330 and security manager 332 are provided.

[0335] The processor 3112 of the illustrated example includes a local memory 3113 (e.g., a cache). The processor 3112 of the illustrated example communicates with a main memory including a volatile memory 3114 and a non-volatile memory 3116 via a bus 3118. The volatile memory 3114 may be comprised of a synchronous dynamic random access memory (SDRAM), a dynamic random access memory (DRAM), Dynamic Random Access Memory And / or any other type of random access memory device. The non-volatile memory 3116 can be implemented by flash memory and / or any other desired type of memory device. Access to the main memory 3114, 3116 is controlled by a memory controller.

[0336] The processor platform 3100 of the illustrated example also includes an interface circuit 3120. The interface circuit 3120 may be implemented through any type of interface standard (e.g., an Ethernet interface, a universal serial bus (USB), interface, BLE radio interface, near field communication (NFC) interface, UART interface, GPIO interface and / or peripheral component interconnect (PCI) express interface). In this example, the interface circuit 3120 implements Figure 3 The receiver transmitter interface 300, the input / output interface 310 and the BLE interface 340 are provided.

[0337] In the example shown, one or more input devices 3122 are connected to the interface circuit 3120. The input devices 3122 allow a user to enter data and / or commands into the processor 3112. The input devices 3122 may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a trackpad, a trackball, an isopoint device, and / or a voice recognition system.

[0338] One or more output devices 3124 are also connected to the interface circuit 3120 of the illustrated example. The output device 3124 can be implemented, for example, by a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube (CRT) display, an in-place switching (IPS) display, a touch screen, etc.), a tactile output device, a printer, and / or a speaker. Therefore, the interface circuit 3120 of the illustrated example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0339] The interface circuitry 3120 of the illustrated example also includes communication devices, such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate data exchange with external machines (e.g., any type of computing device) via the network 3126. Communications may be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a field wireless system, a cellular telephone system, a Bluetooth network connection, a BLE network connection, etc.

[0340] The processor platform 3100 of the illustrated example also includes one or more mass storage devices 3128 for storing software and / or data. Examples of such mass storage devices 3128 include floppy disk drives, hard drive disks, CD drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and DVD drives. In this example, the mass storage device 3128 implements Figure 3 Database 335.

[0341] Figure 21-29The machine executable instructions 3132 may be stored in the mass storage device 3128, in the volatile memory 3114, in the non-volatile memory 3116, and / or on a removable, non-transitory computer-readable storage medium (eg, a CD or DVD).

[0342] Fig.32 is constructed to execute Fig.30 Instructions to achieve Figure 1 remote device 106, Figure 2 Remote devices 1-3200, 202, 204 and / or Figure 3 3200 of a remote device 360. The processor platform 3200 may be, for example, a personal computer, a mobile device (e.g., a cell phone, a smart phone, an iPad, etc.) TM such as a tablet computer, a personal digital assistant (PDA), or any other type of computing device.

[0343] The processor platform 3200 of the illustrated example includes a processor 3212. The processor 3212 of the illustrated example is hardware. For example, the processor 3212 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired series or manufacturer. The hardware processor can be a semiconductor-based (e.g., silicon-based) device.

[0344] The processor 3212 of the illustrated example includes a local memory 3213 (e.g., a cache). The processor 3212 of the illustrated example communicates with a main memory including a volatile memory 3214 and a non-volatile memory 3216 via a bus 3218. The volatile memory 3214 can be implemented by SDRAM, DRAM, RDRAM, and / or any other type of random access memory device. The non-volatile memory 3216 can be implemented by a flash memory and / or any other desired type of storage device. Access to the main memory 3214, 3216 is controlled by a memory controller.

[0345] The processor platform 3200 of the illustrated example also includes an interface circuit 3220. The interface circuit 3220 may be implemented by any type of interface standard (e.g. interface, Ethernet interface, USB, BLE radio interface, UART interface, GPIO interface and / or PCI express interface).

[0346] In the example shown, one or more input devices 3222 are connected to the interface circuit 3220. The input devices 3222 allow a user to enter data and / or commands into the processor 3212. The input devices may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a trackpad, a trackball, an isopoint device, and / or a voice recognition system.

[0347] One or more output devices 3224 are also connected to the interface circuit 3220 of the illustrated example. The output device 3224 can be implemented, for example, by a display device (e.g., LED, OLED, LCD, CRT display, IPS display, touch screen, etc.), a tactile output device, a printer, and / or a speaker. Therefore, the interface circuit 3220 of the illustrated example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0348] The interface circuitry 3220 of the illustrated example also includes communication devices such as transmitters, receivers, transceivers, modems, residential gateways, wireless access points, and / or network interfaces to facilitate data exchange with external machines (e.g., any type of computing device) via the network 3226. Communications may be via, for example, an Ethernet connection, a DSL connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-sight wireless system, a cellular telephone system, a Bluetooth network connection, a BLE network connection, etc.

[0349] The processor platform 3200 of the illustrated example also includes one or more mass storage devices 3228 for storing software and / or data. Examples of such mass storage devices 3228 include floppy disk drives, hard drive disks, CD drives, Blu-ray disk drives, RAID systems, and DVD drives.

[0350] Fig.32 The machine executable instructions 3232 may be stored in the mass storage device 3228, in the volatile memory 3214, in the non-volatile memory 3216, and / or on a removable, non-transitory computer-readable storage medium (eg, a CD or DVD).

[0351] As can be understood from the above, exemplary methods, apparatus, and articles for controlling the communication data rate of low-power devices such as BLE transceivers have been disclosed. The disclosed network bridge enables an exemplary remote device to form a peer-to-peer connection with a field device to calibrate or configure the field device and / or more generally to dock with the field device. The exemplary BLE bridge device performs communication operations based on the direction of the data stream. In response to acquiring a data packet from the field device MCU, the BLE bridge device removes protocol information from the acquired data packet and transmits the processed data packet to the remote device via BLE. In response to acquiring a data packet from the remote device, the BLE bridge device generates a protocol packet based on the protocol supported by the field device. By removing the protocol information from the data packet before submission, the field device can transmit and / or receive more data on a reduced power budget. In addition, the examples disclosed herein adjust one or more parameters of the BLE transceiver based on the input power of the field device to transmit and / or receive more data with a reduced power budget. In some examples disclosed herein, operation of a field device may be disabled and / or otherwise modified to reallocate power corresponding to the disabled and / or modified operation to a BLE transceiver to improve data throughput and / or efficiency of the BLE transceiver.

[0352] Disclosed herein are exemplary methods, apparatus, systems, and articles for controlling the communication data rate of a low energy device. Further examples and combinations thereof include the following:

[0353] Example 1 includes an apparatus for managing a power profile of a network bridge for field devices in a process control environment, the apparatus comprising a Bluetooth Low Energy (BLE) radio; and a power manager, the power manager for determining whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power supply associated with the BLE radio and (2) a charging rate of the power supply; and when the first computing task is executed by the BLE radio and the first computing task is divided based on the determination, performing the following operations: after executing the second computing task, directing the BLE radio to enter a sleep mode; and calling the BLE radio to transition from the sleep mode to an operating mode to perform the third computing task, the call being in response to a measurement value associated with the power supply satisfying an energy threshold.

[0354] Example 2 includes the device of Example 1, wherein the measurement value is a first measurement value and the energy threshold is a high energy threshold, and the device further includes: an input / output interface, the input / output interface performing the following operations: obtaining a first interrupt from a first comparator, the first comparator comparing the first measurement value with the high energy threshold; and obtaining a second interrupt from a second comparator, the second comparator comparing a second measurement value associated with the power supply with a low energy threshold; and the power manager is used to perform the following operations: when the first interrupt indicates that the first measurement value meets the high energy threshold, directing the BLE radio device to enter the operating mode; and when the second interrupt indicates that the second measurement value does not meet the low energy threshold, directing the BLE radio device to enter the sleep mode.

[0355] Example 3 includes the apparatus of Example 2, further including a BLE stack handler to perform the following operations: assigning a first data rate to a BLE radio device when the charging rate is a first charging rate; adjusting the first data rate to a second data rate for the BLE radio device when the first charging rate is changed to a second charging rate, the second charging rate being less than the first charging rate, and the second data rate being less than the first data rate; and facilitating data communication between the BLE radio device and a device separate from the field device based on the second data rate when the first computing task is to be performed by the BLE radio device.

[0356] Example 4 includes the device of Example 3, wherein the BLE stack handler adjusts the first data rate to the second data rate by at least one of: (1) adjusting a first data amount to a second data amount for transmission during radio frequency operation, or (2) adjusting a first data interval to a second data interval, the first data interval and the second data interval corresponding to a duration between radio frequency operations of the BLE radio device.

[0357] Example 5 includes the apparatus of Example 1, wherein the field device charges the power source, and the power manager is used to perform the following operations: determine a first charging rate of the power source based on first data in a data buffer, the field device writing the first data to the data buffer; determine a power budget associated with the BLE radio device based on the first charging rate; and adjust the power budget when the first charging rate is changed to a second charging rate when the field device writes second data to the data buffer, the second charging rate being different from the first charging rate, and the second data being different from the first data.

[0358] Example 6 includes the apparatus of Example 1, further comprising a BLE stack handler to perform the following operations: when the charging rate is a first charging rate, directing the BLE radio device to perform the second computing task by facilitating communication of a first amount of data between the BLE radio device and a device separated from the field device at a first data interval; and when the charging rate is a second charging rate, directing the BLE radio device to perform the second computing task by facilitating communication of a second amount of data between the BLE radio device and the device at a second data interval, the second amount of data being less than the first amount of data, the second data interval being longer than the first data interval, the second charging rate being less than the first charging rate, the first data interval and the second data interval corresponding to a duration between radio frequency operations of the BLE radio device.

[0359] Example 7 includes the apparatus of Example 1, wherein the energy threshold is a first energy threshold corresponding to an amount of first energy stored by the power source, the first computing task is not executed by the BLE radio device, and the power manager performs the following operations: determining that a first task queue with a first priority includes the first computing task; determining that a second task queue with a second priority includes a fourth computing task, the first priority being greater than the second priority; calculating an amount of second energy to execute the first computing task; calculating an amount of third energy to execute the fourth computing task; determining a difference between the amount of the first energy and the sum of the amount of the second energy and the amount of the third energy; and when the difference is greater than an amount of fourth energy associated with the second energy threshold, calling the platform manager to execute the first computing task and the fourth computing task, the first computing task being executed at a first time, the fourth computing task being executed at a second time after the first time, the amount of the fourth energy being less than the amount of the first energy.

[0360] Example 8 includes the apparatus of Example 7, wherein when the difference is not greater than the amount of the fourth energy, the power manager is configured to: divide the fourth computing task into at least a fifth computing task and a sixth computing task; instruct the platform manager to execute the first computing task and the fifth computing task, the first computing task to be executed at the first time, and the fifth computing task to be executed at the second time; and instruct the platform manager to execute the sixth computing task, the sixth computing task to be executed at a third time after the second time, the platform manager being in the sleep mode from the second time to the third time.

[0361] Example 9 includes the apparatus of Example 1, wherein the second computing task and the third computing task are radio frequency operations of the BLE radio device, and the power manager performs the following operations: identifying a fourth computing task to be executed, the fourth computing task not being executed by the BLE radio device; calling the platform manager to execute the fourth computing task when at least one of (i) the BLE radio device is in a first BLE state or (ii) the power source is in a first power state when the stored energy satisfies the energy threshold; and calling the platform manager to postpone execution of the fourth computing task when at least one of (iii) the BLE radio device is in a second BLE state different from the first BLE state or (iv) the power source is in a second power state when the stored energy does not satisfy the energy threshold, wherein the fourth computing task is postponed until at least one of the BLE radio device is in the first BLE state or the power source is in the first power state.

[0362] Example 10 includes a non-transitory computer-readable storage medium comprising instructions that, when executed, cause at least one processor of a network bridge of a field device in a process control environment to perform at least the following operations: determine whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power supply associated with a Bluetooth Low Energy (BLE) radio device of the network bridge and (2) a charging rate of the power supply; and when the first computing task is executed by the BLE radio device and the first computing task is divided based on the determination, perform the following operations: after executing the second computing task, direct the BLE radio device to enter a sleep mode; and call the BLE radio device to transition from the sleep mode to an operating mode to perform the third computing task, the call being in response to a measurement value associated with the power supply satisfying an energy t...

Claims

1. An apparatus for managing a power profile of a network bridge of field devices in a process control environment, the apparatus comprising: Bluetooth Low Energy (BLE) radio; as well as A power manager, wherein the power manager is used to perform the following operations; determining whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy associated with the BLE radio device stored in a power source and (2) a charging rate of the power source; as well as When the first computing task is performed by the BLE radio device and the first computing task is divided based on the determination, performing the following operations: After the second computing task is performed, directing the BLE radio device to enter a sleep mode; as well as The BLE radio is invoked to transition from the sleep mode to an operational mode to perform the third computing task, the invocation being responsive to a measurement associated with the power source satisfying an energy threshold.

2. The device according to claim 1, wherein: The measurement value is a first measurement value and the energy threshold is a high energy threshold, and the apparatus further comprises: An input / output interface, the input / output interface is used to perform the following operations: obtaining a first interrupt from a first comparator, the first comparator comparing the first measurement value to the high energy threshold; and obtaining a second interrupt from a second comparator that compares a second measurement associated with the power source to a low energy threshold; and The power manager is configured to perform the following operations: directing the BLE radio to enter the operating mode when the first interrupt indicates that the first measurement value meets the high energy threshold; and When the second interrupt indicates that the second measurement value does not meet the low energy threshold, directing the BLE radio device to enter the sleep mode.

3. The apparatus according to claim 1 , further comprising a BLE stack handler, the BLE stack handler being configured to perform the following operations: assigning a first data rate to the BLE radio when the charging rate is a first charging rate; When the first charging rate is changed to a second charging rate, adjusting the first data rate to a second data rate for the BLE radio device, the second charging rate being less than the first charging rate, the second data rate being less than the first data rate; and When the first computing task is to be performed by the BLE radio, data communication between the BLE radio and a device separate from the field device is facilitated based on the second data rate.

4. The device according to claim 3, wherein: The BLE stack handler adjusts the first data rate to the second data rate by at least one of: (1) adjusting a first data amount to a second data amount for transmission during RF operation, or (2) adjusting a first data interval to a second data interval, wherein the first data interval and the second data interval correspond to a duration between RF operations of the BLE radio device.

5. The device according to claim 1, wherein: The field device charges the power source, and the power manager is configured to: determining a first charging rate of the power source based on first data in a data buffer, the field device writing the first data into the data buffer; determining a power budget associated with the BLE radio based on the first charging rate; as well as The power budget is adjusted when the first charge rate is changed to the second charge rate when the field device writes second data to the data buffer, the second charge rate being different from the first charge rate, the second data being different from the first data.

6. The apparatus according to claim 1, further comprising a BLE stack handler, the BLE stack handler being configured to perform the following operations: when the charging rate is a first charging rate, directing the BLE radio to perform the second computing task by facilitating communication of a first amount of data between the BLE radio and a device separate from the field device at a first data interval; and When the charging rate is a second charging rate, instructing the BLE radio device to perform the second computing task by facilitating communication of a second data amount between the BLE radio device and the device at a second data interval, the second data amount is less than the first data amount, the second data interval is longer than the first data interval, the second charging rate is less than the first charging rate, and the first data interval and the second data interval correspond to a duration between radio frequency operations of the BLE radio device.

7. The device according to claim 1, wherein: The energy threshold is a first energy threshold corresponding to an amount of first energy stored by the power source, the first computing task is not performed by the BLE radio device, and the power manager is to perform the following operations: Determining that a first task queue having a first priority includes the first computing task; determining that a second task queue having a second priority includes a fourth computing task, the first priority being greater than the second priority; calculating an amount of a second energy to perform the first computing task; calculating an amount of a third energy to perform the fourth computing task; determining a difference between the first energy amount and the sum of the second energy amount and the third energy amount; as well as When the difference is greater than an amount of a fourth energy associated with the second energy threshold, the platform manager is called to execute the first computing task and the fourth computing task, the first computing task will be executed at a first time, the fourth computing task will be executed at a second time after the first time, and the amount of the fourth energy is less than the amount of the first energy.

8. The apparatus according to claim 7, when the difference is not greater than the amount of the fourth energy, the power manager is configured to perform the following operations: dividing the fourth computing task into at least a fifth computing task and a sixth computing task; Instructing the platform manager to execute the first computing task and the fifth computing task, wherein the first computing task will be executed at the first time and the fifth computing task will be executed at the second time; as well as The platform manager is directed to execute the sixth computing task, the sixth computing task to be executed at a third time after the second time, the platform manager being in the sleep mode from the second time to the third time.

9. The device according to claim 1, wherein: The second computing task and the third computing task are radio frequency operations of the BLE radio device, and the power manager is configured to perform the following operations: identifying a fourth computing task to be performed, the fourth computing task not being performed by the BLE radio; Invoking the platform manager to perform the fourth computing task when at least one of (i) the BLE radio device is in the first BLE state or (ii) the power source is in the first power state when the stored energy meets the energy threshold; as well as When at least one of (iii) the BLE radio device is in a second BLE state different from the first BLE state or (iv) the power source is in a second power state when the stored energy does not meet the energy threshold, calling the platform manager to postpone the execution of the fourth computing task, wherein the fourth computing task will be postponed until at least one of the BLE radio device is in the first BLE state or the power source is in the first power state.

10. A non-transitory computer-readable storage medium comprising instructions that, when executed, cause at least one processor of a network bridge for field devices in a process control environment to perform at least the following operations: determining whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power source associated with a Bluetooth Low Energy (BLE) radio of the network bridge and (2) a charging rate of the power source; as well as When the first computing task is performed by the BLE radio device and the first computing task is divided based on the determination, performing the following operations: After the second computing task is performed, directing the BLE radio device to enter a sleep mode; as well as The BLE radio is invoked to transition from the sleep mode to an operational mode to perform the third computing task, the invocation being responsive to a measurement associated with the power source satisfying an energy threshold.

11. The non-transitory computer-readable storage medium of claim 10, wherein: The measurement is a first measurement and the energy threshold is a high energy threshold, and the instructions, when executed, cause the at least one processor to: obtaining a first interrupt from a first comparator, the first comparator comparing the first measurement value to the high energy threshold; obtaining a second interrupt from a second comparator that compares a second measurement associated with the power source to a low energy threshold; directing the BLE radio to enter the operating mode when the first interrupt indicates that the first measurement value meets the high energy threshold; and When the second interrupt indicates that the second measurement value does not meet the low energy threshold, directing the BLE radio device to enter the sleep mode.

12. The non-transitory computer-readable storage medium of claim 10, wherein: When executed, the instructions cause the at least one processor to: assigning a first data rate to the BLE radio when the charging rate is a first charging rate; When the first charging rate is changed to a second charging rate, adjusting the first data rate to a second data rate for the BLE radio device, the second charging rate is less than the first charging rate, and the second data rate is less than the first data rate; as well as When the first computing task is performed by the BLE radio, data communication between the BLE radio and a device separate from the field device is facilitated based on the second data rate.

13. The non-transitory computer-readable storage medium of claim 12, wherein: When executed, the instructions cause the at least one processor to: The first data rate is adjusted to the second data rate by at least one of: (1) adjusting a first data amount to a second data amount for transmission during RF operation, or (2) adjusting a first data interval to a second data interval, wherein the first data interval and the second data interval correspond to a duration between RF operations of the BLE radio device.

14. The non-transitory computer-readable storage medium of claim 10, wherein: The field device charges the power source, and the instructions, when executed, cause the at least one processor to: determining a first charging rate of the power source based on first data in a data buffer, the field device writing the first data into the data buffer; determining a power budget associated with the BLE radio based on the first charging rate; as well as The power budget is adjusted when the first charge rate is changed to a second charge rate when the field device writes second data to the data buffer, the second charge rate being different from the first charge rate, the second data being different from the first data.

15. The non-transitory computer-readable storage medium of claim 10, wherein: When executed, the instructions cause the at least one processor to: when the charging rate is a first charging rate, directing the BLE radio to perform the second computing task by facilitating communication of a first amount of data between the BLE radio and a device separate from the field device at a first data interval; as well as When the charging rate is a second charging rate, instructing the BLE radio device to perform the second computing task by facilitating communication of a second data amount between the BLE radio device and the device at a second data interval, the second data amount is less than the first data amount, the second data interval is longer than the first data interval, the second charging rate is less than the first charging rate, and the first data interval and the second data interval correspond to a duration between radio frequency operations of the BLE radio device.

16. The non-transitory computer-readable storage medium of claim 10, wherein: The energy threshold is a first energy threshold corresponding to an amount of first energy stored by the power source, the first computing task is not performed by the BLE radio, and the instructions, when executed, cause the at least one processor to: Determining that a first task queue having a first priority includes the first computing task; determining that a second task queue having a second priority includes a fourth computing task, the first priority being greater than the second priority; calculating an amount of a second energy to perform the first computing task; calculating an amount of a third energy to perform the fourth computing task; determining a difference between the first energy amount and the sum of the second energy amount and the third energy amount; as well as When the difference is greater than the amount of a fourth energy associated with the second energy threshold, the first computing task and the fourth computing task are executed, the first computing task will be executed at a first time, the fourth computing task will be executed at a second time after the first time, and the amount of the fourth energy is less than the amount of the first energy.

17. The non-transitory computer-readable storage medium of claim 16, when the difference is not greater than the amount of the fourth energy, the instructions, when executed, cause the at least one processor to perform the following operations: dividing the fourth computing task into at least a fifth computing task and a sixth computing task; Execute the first computing task and the fifth computing task, wherein the first computing task will be executed at the first time, and the fifth computing task will be executed at the second time; as well as The sixth computing task is executed, and the sixth computing task is to be executed at a third time after the second time, and the at least one processor is in the sleep mode from the second time to the third time.

18. The non-transitory computer-readable storage medium of claim 10, wherein: The second computing task and the third computing task are radio frequency operations of the BLE radio device, and the instructions, when executed, cause the at least one processor to perform the following operations: identifying a fourth computing task to be performed, the fourth computing task not being performed by the BLE radio; performing the fourth computing task when at least one of (i) the BLE radio is in the first BLE state or (ii) the power source is in the first power state when the stored energy satisfies the energy threshold; as well as When at least one of (iii) the BLE radio device is in a second BLE state different from the first BLE state or (iv) the power supply is in a second power state when the stored energy does not meet the energy threshold, execution of the fourth computing task is postponed until at least one of the BLE radio device is in the first BLE state or the power supply is in the first power state.

19. A method for managing a power profile of a network bridge of field devices in a process control environment, the method comprising: determining whether to divide a first computing task into at least a second computing task and a third computing task based on (1) energy stored in a power source associated with a Bluetooth Low Energy (BLE) radio of the network bridge and (2) a charging rate of the power source; as well as When the first computing task is performed by the BLE radio device and the first computing task is divided based on the determination, performing the following operations: After the second computing task is performed, directing the BLE radio device to enter a sleep mode; as well as The BLE radio is invoked to transition from the sleep mode to an operational mode to perform the third computing task, the invocation being responsive to a measurement associated with the power source satisfying an energy threshold.

20. The method according to claim 19, wherein: The measurement is a first measurement and the energy threshold is a high energy threshold, and the method further comprises: obtaining a first interrupt from a first comparator, the first comparator comparing the first measurement value to the high energy threshold; obtaining a second interrupt from a second comparator that compares a second measurement associated with the power source to a low energy threshold; directing the BLE radio to enter the operating mode when the first interrupt indicates that the first measurement value meets the high energy threshold; and When the second interrupt indicates that the second measurement value does not meet a low energy threshold, directing the BLE radio device to enter the sleep mode.

21. The method of claim 19, further comprising: assigning a first data rate to the BLE radio when the charging rate is a first charging rate; When the first charging rate is changed to a second charging rate, adjusting the first data rate to a second data rate for the BLE radio device, the second charging rate is less than the first charging rate, and the second data rate is less than the first data rate; as well as When the first computing task is to be performed by the BLE radio, data communication between the BLE radio and a device separate from the field device is facilitated based on the second data rate.

22. The method according to claim 21, wherein: Adjusting the first data rate to the second data rate includes: Perform at least one of the following: (1) adjust a first data amount to a second data amount for transmission during radio frequency operation, or (2) adjust a first data interval to a second data interval, wherein the first data interval and the second data interval correspond to a duration between radio frequency operations of the BLE radio device.

23. The method according to claim 19, wherein: The field device charges the power source, and the method further comprises: determining a first charging rate of the power source based on first data in a data buffer, the field device writing the first data into the data buffer; determining a power budget associated with the BLE radio based on the first charging rate; and The power budget is adjusted when the first charge rate is changed to a second charge rate when the field device writes second data to the data buffer, the second charge rate being different from the first charge rate, the second data being different from the first data.

24. The method of claim 19, further comprising: when the charging rate is a first charging rate, directing the BLE radio to perform the second computing task by facilitating communication of a first amount of data between the BLE radio and a device separate from the field device at a first data interval; as well as When the charging rate is a second charging rate, instructing the BLE radio device to perform the second computing task by facilitating communication of a second data amount between the BLE radio device and the device at a second data interval, the second data amount is less than the first data amount, the second data interval is longer than the first data interval, the second charging rate is less than the first charging rate, and the first data interval and the second data interval correspond to a duration between radio frequency operations of the BLE radio device.

25. The method of claim 19, wherein: The energy threshold is a first energy threshold corresponding to an amount of first energy stored by the power source, the first computing task is not performed by the BLE radio device, and the method further includes: Determining that a first task queue having a first priority includes the first computing task; determining that a second task queue having a second priority includes a fourth computing task, the first priority being greater than the second priority; calculating an amount of a second energy to perform the first computing task; calculating an amount of a third energy to perform the fourth computing task; determining a difference between the first energy amount and the sum of the second energy amount and the third energy amount; and When the difference is greater than the amount of a fourth energy associated with the second energy threshold, the first computing task and the fourth computing task are executed, the first computing task will be executed at a first time, the fourth computing task will be executed at a second time after the first time, and the amount of the fourth energy is less than the amount of the first energy.

26. The method according to claim 25, when the difference is not greater than the amount of the fourth energy, the method further comprises: dividing the fourth computing task into at least a fifth computing task and a sixth computing task; Execute the first computing task and the fifth computing task, the first computing task will be executed at the first time, and the fifth computing task will be executed at the second time; as well as The sixth computing task is executed, and the sixth computing task is to be executed at a third time after the second time, and the at least one processor is in the sleep mode from the second time to the third time.

27. The method of claim 19, wherein: The second computing task and the third computing task are radio frequency operations of the BLE radio device, and the method further includes: identifying a fourth computing task to be performed, the fourth computing task not being performed by the BLE radio; performing the fourth computing task when at least one of (i) the BLE radio is in the first BLE state or (ii) the power source is in the first power state when the stored energy satisfies the energy threshold; and When at least one of (iii) the BLE radio device is in a second BLE state different from the first BLE state or (iv) the power supply is in a second power state when the stored energy does not meet the energy threshold, execution of the fourth computing task is postponed until at least one of the BLE radio device is in the first BLE state or the power supply is in the first power state.

Images