Device health management for edge devices

Abstract

Methods and systems for communication between edge devices in vehicles. The method involves determining a connection failure between the edge device and a cloud server, broadcasting a beacon upon vehicle ignition power-off or at other times when it may be likely that a wireless connection can be established with a nearby edge device that may act an intermediate device for communication with the cloud server, and receiving responses from intermediate devices. The system then establishes a short-range wireless connection with an intermediate device, through which health data of the edge device is uploaded to the cloud server.

Description

DEVICE HEALTH MANAGEMENT FOR EDGE DEVICESCROSS-REFERENCE TO RELATED APPLICATION

[0001] The present application claims the benefit of Indian Provisional Patent Application No. 202311051735 filed on 1stof August 2023, and titled, “DEVICE HEALTH MANAGEMENT FOR EDGE DEVICES”, the disclosure of which is expressly incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure relates to systems and methods for management of devices, particularly, determining faulty behavior in an edge device and methods to report and / or remotely correct the faulty behavior.BACKGROUND

[0003] loT devices are used for sensing and reporting data related to measurements made. Some loT devices may frequently communicate with their designated server to upload the measurement data. The loT devices can malfunction at any time and fail to upload the measurement data. Therefore, there is a need for detecting and diagnosing the device health issues related to the loT devices.SUMMARYCertain aspects of the present disclosure provide methods and systems for communication between edge devices. The method includes determining, by at least one processor of an edge device installed in a vehicle, that the edge device has failed to connect to a cloud server; detecting, by the at least one processor, that the ignition of the vehicle is powered off; upon detecting that the ignition of the vehicle is powered off, broadcasting, by the at least one processor, a beacon comprising an identifier of the edge device; receiving, by the at least one processor, a response message from one or more intermediate devices; establishing, by the at least one processor, a short-range wireless connection with an intermediate device of the one or more intermediate devices; and uploading, by the at least one processor, health data of the edge device to the cloud server using the short-range wireless connection.BRIEF DESCRIPTION OF FIGURES

[0004] FIG. 1 illustrates an environment depicting one or more edge devices in communication with a cloud server, according to an embodiment of the disclosure.

[0005] FIG. 2 illustrates a block diagram of an edge device, according to an embodiment of the disclosure.

[0006] FIG. 3 illustrates an environment depicting one edge device disconnected from a network and cloud server, according to an embodiment of the disclosure.

[0007] FIG. 4 depicts a scenario in which one or more edge devices are involved in intercommunication, according to an embodiment of the disclosure.

[0008] FIG.5 illustrates a process flow of a method for establishing a connection to the cloud server, according to an embodiment of the disclosure.

[0009] FIG.6 illustrates a process flow of a method for uploading health data to the cloud server, according to an embodiment of the disclosure.DETAILED DESCRIPTION

[0010] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0011] Based on the teachings, one skilled in the art should appreciate that the scope of the disclosure is intended to cover any aspect of the disclosure, whether implemented independently of or combined with any other aspect of the disclosure. For example, an apparatus may be implemented, or a method may be practiced using any number of the aspects set forth. In addition, the scope of the disclosure is intended to cover such an apparatus or method practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the disclosure set forth. Any aspect of the disclosure disclosed may be embodied by one or more elements of a claim.

[0012] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

[0013] Although particular aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to particular benefits, uses or objectives. Rather, aspects of the disclosure are intended to be broadly applicable to different technologies, and system configurations, some of which are illustrated by way of example in the figures and in the following description of the preferred aspects. The detailed description and drawings are merely illustrative of the disclosure rather than limiting, the scope of the disclosure being defined by the appended claims and equivalents thereof.

[0014] Driving behavior is monitored by an edge device installed in the cabin of the vehicle. The edge device is a computing device that includes a processor, one or more sensors, a communication module, memory, etc. The edge device may communicate with a cloud server to upload driver behavior data and to receive instructions from the cloud server. Instructions received from the cloud server may include instructions to update firmware or software on an edge device, to upload specified video data that has been recorded on the device, and the like. As disclosed herein, instructions communicated from the cloud server may include instructions that aid in device health management for one or more edge devices. Such instructions may include instructions to update a driver on an edge device, to reboot an edge device, to stop sending health data until the vehicle in which an edge device has been installed has moved or a certain period of time has elapsed, and the like. The edge device is configured to communicate with the cloud server using a cellular network. The edge device may stop communicating to the cloud server if the communication module is faulty or if the edge device is in a cellular shadow zone. To facilitate remote monitoring of driving behavior, vehicle asset tracking, and the like, there is a need to establish an alternative connection with the cloud server in case the edge device stops communicating with the cloud server. In addition, by establishing an alternate communication channel to a cloud server, processing on the cloud server may distinguish between various causes of the lack of direct cellular communication between an edge device and the cloud server. Thismay enable the remote server to remotely address the cause of the lack of cellular communication, thus restoring functionality to the edge device. It may also enable more efficient use of physical device support resources by limiting the deployment of resources to devices that cannot be improved remotely.

[0015] FIG. 1 illustrates environment 100 that depicts edge devices 101a, 101b, 101c and the cloud server 105. The edge devices 101 a- 101c may communicate with the cloud server 105 via the network 103. To that effect, the edge device 101 may include communication modules for establishing a connection with the cloud server 105. The communication module may include one or more modules that operate on cellular (e.g. LTE), NFC, Wi-Fi, Bluetooth (BT), BT-LE, and other communication protocols.

[0016] The edge device 101 is configured to communicate with the cloud server at regular intervals to upload data and receive instructions. The edge device may capture visual content and upload the visual content to the cloud server at regular intervals. In some embodiments, the edge device may generate inferences based on the visual data and upload information related to the inferences to the cloud server. Further, the edge device generates and uploads health data of various components to the cloud server. The health data is generated at regular intervals and this health data needs to be communicated to the cloud server to monitor the working status of the edge device. Reception of health data by the cloud server is a necessary first step for monitoring the performance of the edge device from the cloud server side.

[0017] The network 103 can be radio access networks such as GSM, LTE, 5G or the like. In one embodiment, the network 103 can be Wi-Fi or other wireless broadband networks.

[0018] The cloud server 105 provides configuration settings and software related services to the edge devices. The cloud server 105 may store the data received from the edge devices. Further, the cloud server 105 may provide alerts to a fleet operator, which my be accomplished by transmitting the alerts to a smartphone or similar device that is used by the fleet operator.

[0019] FIG. 2 depicts a block diagram of the edge device 200 (similar to edge devices 104a, 106a) including various components. The edge device 200 includes a processor 202, a communication module 204, input / output (I / O) module 206, memory 208, a camera module 210 and a sensor module 212. In one embodiment, the edge device 200may not include a camera module 210 and in those scenarios, the camera module 210 may be connected to edge device 200 through wired or wireless connection. The edge device 200 may include input sensors (which may include a forward-facing camera, a driver facing camera, connections to other cameras that are not physically mounted to the device, inertial sensors, car OBD-II port sensor data (which may be obtained through a Bluetooth connection), and the like) and compute capability. The compute capability may be a CPU or an integrated System-on-a-chip (SOC), which may include a CPU and other specialized compute cores, such as a graphics processor (GPU), gesture recognition processor, and the like. In some embodiments, the edge device 200 for determining, transmitting, and / or providing alerts to an operator of a vehicle and / or a device of a remote driver monitoring system may include wireless communication to cloud services, such as with Long Term Evolution (LTE) or Bluetooth communication to other devices nearby. For example, the cloud server 105 may provide real-time analytics assistance. In an embodiment involving cloud services, the cloud server 105 may facilitate aggregation and processing of data for offline analytics. The edge device 200 may also include a global positioning system (GPS) either as a separate module or integrated within a system-on-a-chip (e.g., included in sensor module 212).

[0020] Under certain circumstances, an edge device may stop uploading information to the cloud server as shown in FIG. 3 (i.e., edge device 101b is disconnected from the network 103 and the cloud server 105). This can be due to malfunctioning of a communication module, disconnection of power supply to the edge device, cellular connection signal strength, etc. In some cases, the edge device may fail to upload the health data (or any other data) to the cloud server, and it is difficult to accurately diagnose the reason for failure from the cloud server side without health data, thereby leading to schedule of a manual inspection of the edge device for any failure, even failures that could have been fixed or mitigated remotely if health data and a communication channel had been available (in such instances manual interaction with the device could be avoided altogether), and even failures that would be understood to be beyond repair (in such instances, manual inspection could be skipped and the device replaced instead).

[0021] In order to obtain recent health data from the edge device 101b and to reduce the number of manual inspections scheduled, the edge device 101b may be configured to establish an alternative communication link to the cloud server 105 forcommunicating the health data. The edge device 101b may monitor its components and generate health data for each component at regular intervals. The health data may include multiple data fields and a corresponding value for each data field, where the value can indicate the working status of the component. In some scenarios, the value may indicate whether any component has become faulty.

[0022] In one example, the health data for wireless communication components can be in a format as shown below:“network_info”: {“version”: x,“primary wifi”: [{“ts”: 123456789,“ipv4s”: [“12.34.567.89”],“ipv6s”: [“1234:xy5:3333:4444:5555:6666:7777:8888”],“routes”: [“12.34.567.89”],“mac_id”: “xx:yy:zz:nn:mm:pp”,“ssid”: “XYZ”,“status”: true,“signal_strength”: -55}],“LTE”: [{“ts”: 1622496267217,“service_uptime”: 2,“online”: true,“ipv4s”: [“12.34.567.890”],“ipv6s”: [“1234:dbl:2222:3333:CCCC:4444:5555:6666”],“routes”: [“12.34.567.890”],“mac_id”: “la:2b:3c:45:6e:f7”,“sim_sno”: “1234567890123”,“imei_no”: “1234567890”,“rssi”: -58,“rsrq”: -16, “rsrp”: -91, “sinr”: 66,“rat”: 8,“reg_state”: 1, “band”: 124, “mode”:0, “no_of_di sconnects” : 0, “home_network”: “XYZ”, “eell id”: “1234567”, “roaming”: 0 }],“ secondary _wifi”: [{“ts”: 123456789,“ipv4s”: [“12.34.567.89”],“ipv6s”: [“1234:xy5:3333:4444:5555:6666:7777:8888”],“routes”: [“12.34.567.89”],“mac_id”: “xx:yy:zz:nn:mm:pp”,“ssid”: “XYZ”, “signal_strength”: -55, where ‘ts’ is timestamp, ‘ipv4s and ipv6s’ are IP addresses of communication interfaces of the edge device, ‘mac id’ is mac address of the edge device, ‘SSID’ is a wireless network name of the edge device, ‘sim sno’ is the SIM serial number, ‘imei no’ / IMEI (International Mobile Equipment Identity) is a unique 15-digit serial number given to every sim which can then be used to check information such as the sim’s Country of Origin, the Manufacturer and it's Model Number, ‘rssi’ is received signal strength indication, ‘rsrq’ is average power received from a single reference signal, ‘rsrp’ indicates quality of received signal, ‘sinr’ is signal to noise ratio of a signal, ‘rat’ / Radio Access Technology is the underlying physical connection method for a radio based communication network, ‘reg state’ is registered state of the edge device, ‘band’ is the frequency band of the radio communication network, ‘home network’ is the name of home cellular network and ‘eell id’ is an identifier of a cell at physical layer. However, one or more other formats of the health data can also be used including some or all of the above data fields.

[0023] The health data may include health information of other components of the edge device as well (e.g., hard disk, battery, processor, and one or more sensors of the edgedevice).For example, the power health data of the edge device may include data fields or parameters such as ‘ts’ - timestamp of when the health data was created, ‘Service Uptime’ - uptime of power monitor service, ‘Current Ignition Status’ - current status of ignition , 1 - ignition on and 0 - ignition off, ‘Low Power Count’ - count of low power wakeups of the edge device, ‘Device Wake Up Reason’ - reason of why device woke up, ‘Battery Voltage Detected’ - battery voltage detected by edge device, ‘Current Voltage’ - current voltage detected by edge device, ‘Temperature’ - current temperature of edge device, ‘ Speed’ - speed of edge device, ‘ Supercap Toggle Count’ - number of times super capacitor has toggled, ‘Shut Down Reason’ - previous shutdown reason, ‘Fan Speed’ - current speed of fan in rpm, ‘Chip State’ - state of the chip.

[0024] The health data of memory of the edge device may include parameters such as ‘version’ - indicates the version of the health data, ‘Timestamp’ - indicates when the health data is created, ‘System Uptime’ - indicates the number of minutes the system is running, ‘Service Uptime’ - indicates the number of minutes the service is running, ‘CB’ - Circular Buffer, ‘DS’ -Diagnostics Service, ‘Ignition Off Mins’ - indicates the number of minutes the device was in ignition off state, ‘Memory Mounted’ - indicates whether the device is able to detect SD Card or EMMC i.e., whether is it mounted, ‘Memory Size (AM / TM)(MB)’ - AM- Available Memory , TM - Total Memory in MBs, ‘Available Storage Hours’ - integer which indicates how many more hours of videos can be stored, ‘Oldest Video Details’ - timestamp of the oldest video available, Latitude and Longitude when it was recorded and UDID, ‘No Of Observation Files’ - NF - Total number of observation files present, TS - Total Size of all observation files, ‘No Of Partial Files(NF / TS(MB))’ NF - Total number of partial files present, TS - Total Size of all partial files, ‘No Of HQ Videos’ NF - Total number of HQ (High Quality) videos present, TS - Total Size of all HQ Video files, ‘No Of LQ Videos’ NF - Total number of LQ (Low Quality) videos present, TS - Total Size of all LQ Video files, ‘No Of Audio Files’ NF - Total number of Audio files present, TS - Total Size of all Audio files, ‘No Of Files Added’ - Number of files added to the video list as indicated by circular buffer, ‘No Of Files Deleted’ - Number of files deleted from the video list as indicated by circular buffer, ‘Bad Blocks’ - Total number of bad blocks in SD / Internal EMMC / Extemal EMMC, ‘Write Access’ - Indicates whether data can be written into the memory, ‘R / W Performance’ - CT - Copy Time, DT - Delete Time, Read and Write Performance of the memory indicates the slowness of memory, ‘Remaining Lifespan’ -For EMMC, it is specified as remaining PZE cycles. For SD cards, it is specified as remaining percentage (%), ‘WAF’ - Write Amplification Factor affects lifespan of the memory, ‘Highest Memory Usage Folder’ - indicates the child folder in the device which is using the highest memory, ‘Manufacturer Info’ - provides details about the manufacturer (Product Number , Vendor ID, Serial Number), and ‘Last Action Performed’ - provides the last action performed on the memory with timestamp.

[0025] In one embodiment, the edge device is configured to detect that the mobile communication module does not have an active cellular connection with the cloud server. To that effect, the edge device may determine that its mobile communication module has become faulty by processing the health data. For example, device module driver version information for components of the edge device may indicate that the lack of direct cellular communication may be due to an out-of-date device driver or mismatch in access point name (APN) configuration settings. Such issues could be remotely fixed by transmitting a new driver or new APN settings to the device and instructing the device to update to the new driver or new APN settings. In a second example, the health data may reveal that an input power supply to the device is disconnected, which is an issue that cannot be fixed remotely. Additional device health scenarios are described below. To establish a connection with the cloud server, the edge device utilizes other near field communication protocols such as Bluetooth, Wi-Fi, and NFC, etc. Upon detecting that the mobile communication module has become faulty, the edge device may monitor the vehicle to check whether the ignition of the vehicle turned off to initiate the process of connecting with the cloud server via alternate means of communication.

[0026] In one embodiment, the edge device is configured to perform self-diagnosis to monitor and maintain proper functionality of the components. The edge device may verify connection with the cloud server based on status of calls made to the cloud server. If the calls made to cloud server are unsuccessful, the edge device may determine that the edge device is may need to seek alternative ways of connecting to the cloud server, in accordance with certain aspects of the present disclosure. In FIG. 3, the edge device 101b have lost connection to the network 103 leading to disconnection with the cloud server 105. The disconnection of an edge device from the cloud server can be problematic for several reasons. Some of the reasons are listed below:• Data Loss: Edge devices collect useful data from their environment. If they are disconnected from the cloud server, the edge devices may be unable to upload the data, leading to potential data loss.• Loss of Configurability: Edge devices are controlled or configured remotely through the cloud server. If the edge devices are disconnected, it can be difficult or impossible to change the device settings or behavior.• Reduced Functionality: In some examples, edge devices rely on the cloud server for processing power, data storage, or other functionalities. If the edge devices are disconnected, the edge devices may not be able to function properly or perform some of the tasks that utilize the cloud server.• Security Risks: Cloud servers often provide security updates to edge devices. If an edge device is disconnected, it may not receive these updates and could become vulnerable to attacks.• Maintenance and Troubleshooting: In accordance with certain aspects of the present disclosure, cloud servers may perform remote maintenance and troubleshooting tasks on edge devices that are expected to travel in and out of cellular coverage zones and / or that have multiple communication channels, some of which may be faulty at a given time. If an edge device is disconnected, identifying and resolving issues can become more difficult.Therefore, maintaining a reliable connection between edge devices and the cloud server may enable or improve data integrity, device functionality, operational efficiency, and security. The edge device 101b is configured to communicate the health data to indicate to the cloud server 105 the health status of the edge device 101b, including whether it is experiencing trouble with data communication. Communication of the health data of the edge device 101b to the cloud server 105 via an alternative link may enable diagnossis of the reasons of the edge device 101b not otherwise communicating with the cloud server 105. In accordance with certain aspects of the present disclosure, the edge device 101b is configured to establish an alternative communication link to the network 103 to communicate the health data to the cloud server 105.Wi-Fi Hotspot

[0027] In one embodiment, to establish an alternative communication link, the edge device 101b is configured to use Wi-Fi Hotspot tethering. The edge device 101b can be part of multiple edge devices 101 installed in vehicles of a fleet, and the edge devices101 may be of similar make that have similar hardware and software. The edge device 101b is configured to establish the alternative communication link to the network 103 through Wi-Fi Hotspot of edge devices in the same fleet or different fleet. To use the Wi-Fi hotspot of other edge devices, the edge device 101b may have to be in proximity of the other edge devices for a predefined time to establish the connection with the cloud server 105. The edge device 101b may have to wait for the vehicle to stop in which the edge device 101b is installed, to start the process of establishing an alternative communication link with cloud server 105 via network 103 by using Wi-Fi hotspot of other edge devices. In one embodiment, the edge device 101b is configured to monitor the vehicle and the edge device 101b is configured to determine the vehicle has remained stationary for a time period greater than a threshold. Further, the edge device 101b may check the vehicle remained stationary for the threshold time period upon detecting that the ignition of the vehicle is turned off. Alternatively, the edge device 101b may check that the vehicle is stationary and is likely to remain stationary for at least a threshold period of time. For example, the edge device 101b may trigger the broadcasting of a beacon in response to detecting that the ignition of the vehicle has turned off, because this event indicates that the device that is installed in the vehicle is likely to remain stationary for at least a threshold period of time. The threshold period of time may be configured so that there is enough time to successfully communicate health data of the edge device 101b via an alternative communication channel if one is available, as described below.

[0028] In one embodiment, the edge device 101b may broadcast a beacon signal to identify the presence of any nearby devices of similar type (e.g., devices with same manufacturer), upon detecting the ignition of the vehicle is turned off. In another embodiment, the edge device 101b may check for the presence of a mobile device of a driver of the vehicle. The mobile device can be pre-installed with an application associated with the provider of the edge device, where the application allows the mobile device to participate as a nearby device of similar type. For example, the beacon signal is broadcast using a Bluetooth communication module or any other NFC communication module with suitable range. The beacon is configured to seek responses from certain compatible edge devices, such as from those made by the same manufacturer. The beacon is configured to include:• a unique Identifier (UID) associated with the specific manufacturer or a specific set of devices (e.g., edge devices of a fleet). The UID can be a code or a sequence thatis unique to the manufacturer’s edge devices. The UID may be useful in mapping an edge device to a record in external storage. The UID may include two parts, a first part of the UID may be used to group a particular set of beacons, while the second part of the ID identifies individual devices in the group.• a broadcast Protocol that is understood and can be responded to by the desired edge devices. The broadcast protocol may include specific data formats, encryption standards, or communication norms that are unique to the manufacturer’s edge devices.

[0029] The edge devices 101a, 101c, 101 d, and lOle (shown in FIG. 4) may be configured to recognize a beacon based on the UID, the beacon being transmitted from the edge device 101b that may be from the same fleet or from the same manufacturer. The edge devices lOla-e are configured to implement a network protocol for near-field communication. In one example, the protocol is the Eddystone protocol that defines a Bluetooth low energy (BLE) message format for proximity beacon messages.

[0030] The beacon may include a data field (e.g., unique device identifier (UID)) that indicates the type of devices that can respond to the beacon. In one scenario, the UID may have a value that can be recognized by a group of edge devices from the same fleet. In some scenarios, the UID may have value that can be recognized by edge devices of the same model or same manufacturer. In one embodiment, the beacon may be recognized by a mobile device of a driver of the vehicle if the mobile device runs a mobile application associated with the same manufacturer of the edge devices or otherwise participates in the same device health communication protocol.

[0031] A group of intermediate edge devices 101a, 101c, 101 d, and lOle (as shown in FIG. 3) may respond to the beacon with their response. The edge devices lOla-lOle are configured to receive beacons from other edge devices. However, the edge devices lOla-lOle may identify the UID of beacons that indicates an identity of a group to which the edge devices lOla-lOle are associated. The group can be based on a fleet or a sub-group in the fleet, a device model, a manufacturer, an operating system version, and the like. The entire UID can be unique to a group type or a part of UID can be unique to the group type.

[0032] In one embodiment, the edge device 101b may receive responses from any device that can understand and respond to the beacon. The edge device 101b may beconfigured to identify edge devices 101a, 101c, 101 d, lOle are from the same group of the edge device 101b based on the device identifiers included in the responses of the edge device 101a, 101c, lOld, lOle.

[0033] The edge device 101b is configured to process the response signals from the intermediate edge devices 101a, 101c, 101 d, lOle and identify a response signal having the highest signal strength among the received responses. The edge device 101b selects the intermediate edge device 101c with the highest signal strength and sends a command signal to the intermediate edge device 101c to create a secured Wi-Fi hotspot.

[0034] In one embodiment, the intermediate edge device 101c creates the secured WiFi hotspot and sends the SSID and password of the hotspot to the edge device 101b. In this case, the password is encrypted such that edge device 101b can decrypt the password. In another embodiment, the intermediate edge device sends a reply message to the edge device upon creation of the hotspot. The reply message may include encrypted information that corresponds to the SSID and password of the hotspot. The edge device 101b may extract the SSID and the password of the hotspot from the reply message by decrypting the information in the reply message.

[0035] The edge device 101b establishes a connection with the cloud server using the secured Wi-Fi hotspot. Further, the edge device 101b is configured to upload the health data to the cloud server 105 via the Wi-Fi hotspot. In one embodiment, the edge device may upload the health data to the intermediate edge device 101c and the intermediate edge device 101c later uploads the health data along with an identifier of the edge device 101b to the cloud server 105. This embodiment may be preferable when the cellular signal quality for both the edge device 101b and the intermediate edge device 101c is presently poor, indicating that both vehicles may be in an area with poor cellular coverage. In such cases, device health data may be communicated in both directions, so that the first vehicle to leave the cellular denied environment may be enabled to transmit health data about the other vehicles and devices that may still be experiencing poor cellular coverage.

[0036] In one embodiment, the edge device 101b may check whether the intermediate edge device 101c has an active cellular data connection prior to sending the command signal. The edge device 101b may request the cellular data connection status of the edge devices in the broadcasted beacon. The intermediate edge devices 101a, 101c, 101 d,lOle may indicate the status of their cellular connection in the response signals. The selection of an intermediate edge device to which the command signal has to be sent is also based on an active cellular data connection along with signal strength of the response to the beacon. For example, the edge device 101b may not send the command signal to intermediate edge device lOle with highest signal strength and no active cellular connection. However, the edge device 101b may send the command signal to intermediate edge device 101c with adequate signal strength and active cellular connection.Bluetooth Tethering

[0037] In one embodiment, the edge device 101b may diagnose that the edge device 101b failed to make calls to the cloud server 105. The edge device 101b may diagnose that the mobile communication module is malfunctioning. The edge device 101b is configured to upload the health data of the edge device 101b to the cloud server at regular intervals. In addition to other issues noted above, the cloud server 105 may lose control of the edge device 101b if the edge device 101b is disconnected from the cloud server 105.

[0038] Upon disconnection from the cloud server 105, the cloud server 105 may not be able to diagnose the reasons for malfunction of the mobile communication module of the edge device 101b. Therefore, communication of the health data to the cloud server is important to control and manage edge devices.

[0039] The edge device 101b may be configured to establish an alternative communication link to the cloud server 105. The edge device 101b may detect that the vehicle has stopped, which leads to process initiation by the edge device 101b to establish the communication link to the cloud server 105. The edge device 101b may broadcast a beacon to determine the presence of nearby edge devices. The beacon may include a device identifier that may be recognized by members of a group of edge devices. For example, the device identifier may have a prefix data field that is detected by members of a group of edge devices. More than one of the nearby edge devices that are members of the same group may identify the beacon and respond to the beacon. The group of edge devices may be from a fleet, a subgroup of a fleet, a single manufacturer, running the same version of operating system, and the like.

[0040] The edge device 101b receives responses from the nearby edge devices. The responses are sent by the devices of the same group. The edge device 101b may verify the authenticity of the responses based on device identifiers included in the responses. The edge device 101b may further request the nearby edge devices to indicate their cellular connection status in the responses. The edge device 101b may select a nearby edge device based on signal strength of the response and the cellular connection status. In FIG.3, the edge device 101c is selected by the edge device 101b for communicating health data to the cloud server 105.

[0041] Upon selection of the edge device 101c, the edge device 101b may send a command signal to activate Bluetooth tethering on edge device 101c. The edge device 101b may pair with the edge device 101c and the edge device 101b may establish a connection to the network 103 using the Bluetooth tethering of the edge device 101c. In one embodiment, the edge device 101b may upload the health data to the cloud server 105. The health data being the health data generated from the time the edge device 101b failed to upload to the cloud server 105. In another embodiment, the edge device 101b may upload its health data to the edge device 101c with an indication to the edge device 101c to later upload the health data of the edge device 101b to the cloud server 105 along with the device identifier of edge device 101b. The edge device 101b may upload health data to the edge device 101c when none of the nearby edge devices (e.g., edge devices 101a, 101c, 101 d, 101 e) have an active cellular connection at the time of reception of beacon from the edge device 101b. The selection of edge device 101c may be at least based on the call history of the edge devices 101a, 101c, lOld, lOle (i.e., calls made to the cloud server by the edge devices).Cloud Server

[0042] The cloud server 105 is configured to process the health data received from the edge devices to detect any irregularities in the functioning of the edge devices. The health data from the edge device can include specific parameters and logs that can help in diagnosing the issues associated with the edge devices. The health data may include one or more of:• Software or Firmware Version indicating the current software version of the edge device.• Network Configuration Data indicating information about the device's current network settings. If these settings are incorrect, the cloud server can identify the problem and correct the configuration by sending new network settings to the edge device.• Connection Status Logs indicating connection status, including any disconnections or failed connection attempts. This can help the cloud server to identify issues associated with the network connection.• Error Codes for different types of issues occurring at the edge device.• Signal Strength indicating signal strength of the mobile connection of the edge device. If the signal strength is consistently low, the cloud server may determine that there is an issue with the device’s antenna or the network coverage.• GPS sensor signal strength over time, which may indicate poor positioning of a GPS antenna and / or interference with the GPS antenna.• Device Restart or Reset Logs indicating whether the edge device has been frequently restarted or reset. The cloud server 105 may determine that the edge device might be malfunctioning if there are frequent restarts at the edge device.

[0043] In one embodiment, the cloud server 105 can determine that a component of an edge device has become faulty based on the health data of the component. The health data may include data fields and the edge device generates values for each data field based on measurements performed by the processor in the edge device. The value corresponding to a data field may indicate the working status and configurations of a component. The cloud server is configured to determine that a component of the edge device is malfunctioning based on the values in the health data. In FIG. 6, cloud server 105 receives health data from edge device 101b and identifies that edge device 101b has an issue with the mobile communication module. The cloud server 105 may determine one or more of the below issues associated with the mobile communication module:Software or Firmware Updates: If the issue is due to outdated software or firmware, the cloud server may push necessary updates to the edge device via the alternative communication link. In some embodiments a payload of recentdevice update code may be retained on each device so that the updated edge device may directly push the code update to an out-of-date neighboring device.• Configuration Issues: The cloud server may correct misconfigurations in the network settings of the edge device. The corrections may include changes to the Access Point Name (APN) settings, network selection mode, or preferred network type.• Network Reset: The cloud server may remotely trigger a network settings reset, providing resolutions to issues like incorrect network selection or problems caused by temporary software glitches.• Resetting Connection: If the mobile communication module is stuck or frozen, the cloud server may remotely command a reset of the LTE or 5G connection module, (e.g., a hard reboot).• Queue Flush: If there's congestion or a backlog in the data transmission queue, the cloud server could command the device to flush its queue.• Changing Transmission Rates: If the problem is related to data transmission rates, the cloud server could remotely adjust these rates.

[0044] In one embodiment, the cloud server 105 is configured to send instructions / updates to the edge device based on the malfunction detected for a component. For example, the cloud server may send a set of instructions that update the driver version of a component. In another example, the cloud server may send instructions to restart the edge device. The cloud server 105 may send the instructions upon checking whether the edge device is still connected to the cloud server via the secured Wi-Fi hotspot.

[0045] In another embodiment, the cloud server 105 may schedule a manual inspection of the edge device based on the malfunction detected for a component. For example, the cloud server schedules a field visit of the edge device if power components of the device are faulty (e.g., if input power supply is disconnected, if battery is not charging, if vehicle battery does not have an adequate charge, etc.). The manual inspection may be scheduled if edge device fails to respond to the updates sent upon detection of malfunction.

[0046] FIG.5 illustrates a process flow of a method for establishing a connection to the cloud server by an edge device installed in a vehicle, according to an embodiment ofthe disclosure. An edge device (e.g., edge device 101b) is configured to perform a selfdiagnosis and determine that the edge device has lost connection to a cloud server (e.g., cloud server 105). The edge device is configured to determine that it has lost connection to the cloud server if the edge device has failed to upload health data to the cloud server. To that effect, the edge device determines that a mobile communication module has become faulty which has led to failure of upload of the health data. The edge device is configured to perform the method 500 to establish a connection to the cloud server.

[0047] At step 502, the edge device is configured to broadcast a beacon. The beacon is broadcasted when the ignition of the vehicle is powered off. The method 500 is triggered upon detection of ignition off because the edge device is stationary to establish a reliable connection. The beacon includes an identifier of the edge device, where the identifier includes a first part that corresponds to a group identifier and the second part that corresponds to the edge device itself. The group identifier indicates a set of devices that belong to a group and the group identifier is recognized by devices that belong to the group. The beacon further requests working status of mobile communication module of the responding devices.

[0048] At step 504, the edge device receives response messages from one or more intermediate devices the belong to the group associated with the edge device. The response message includes an identifier of an intermediate device and the status of the mobile communication module. The edge device is configured to verify the authenticity of the one or more intermediate devices based on the group identifier included in the identifier of the one or more intermediate devices. The edge device is configured to select an intermediate device from the one or more intermediate device based at least on signal strength of the response and the status of mobile communication module of the intermediate device.

[0049] At step 506, the edge device is configured to send a command to enable a short- range wireless network at the intermediate device. The short-range wireless network can be one of Wi-Fi hotspot, Bluetooth tethering. Upon enabling the short-range wireless network, the intermediate device sends an acknowledgement message to the edge device.

[0050] At step 508, the edge device receives the acknowledgement message from the intermediate device, where the acknowledgement message includes an indication that an encrypted short-range wireless network is active. The acknowledgement message further includes credentials to join the short-range wireless network and the credentialscan be encrypted by the intermediate device which are decrypted at the edge device. The credentials are SSID and password of the short-range wireless network.

[0051] At step 510, the edge device is configured to establish a short-range wireless connection to the intermediate device through which the edge device establishes a connection to the cloud server. The edge device is configured to use the credentials to establish the short-range wireless connection.

[0052] At step 510, the edge device is configured to upload the health data to the cloud server through the short-range wireless connection.

[0053] FIG.6 illustrates a process flow of a method for uploading health data to the cloud server, according to an embodiment of the disclosure. The cloud server is configured to monitor and manage one or more edge devices. The cloud server is configured to track the one or more edge devices based on health data being uploaded by the one or more edge devices.

[0054] At step 602, the cloud server is configured to receive health data of the edge device. The health data includes information related to the components of the edge device.

[0055] At step 604, the cloud server is configured to process the health data of the edge device using one or more machine learning models, logical operations, or some combination thereof.

[0056] At step 606, the cloud server is configured to determine an issue related to a component of the edge device based on the processing of the health data.

[0057] At step 608, the cloud server is configured to perform an action based on the determined issue. The action can be one of: sending a software update, sending configuration settings, instructing a hard reboot of the edge device.

[0058] As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Additionally, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Furthermore, “determining” may include resolving, selecting, choosing, establishing and the like.

[0059] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

[0060] The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0061] The processing system may be configured as a general -purpose processing system with one or more microprocessors providing the processor functionality and external memory providing at least a portion of the machine-readable media, all linked together with other supporting circuitry through an external bus architecture. Alternatively, the processing system may comprise one or more specialized processors for implementing the neural networks, for example, as well as for other processing systems described herein.

[0062] Thus, certain aspects may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may comprise a computer-readable medium having instructions stored (and / or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. For certain aspects, the computer program product may include packaging material.

[0063] Further, it should be appreciated that modules and / or other appropriate means for performing the methods and techniques described herein can be downloaded and / or otherwise obtained by a user terminal and / or base station as applicable. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can be provided via storage means (e.g., RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.), such that a user terminal and / or base station can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

[0064] It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes and variations may be made in the arrangement, operation and details of the methods and apparatus described above without departing from the scope of the claims.

Claims

AMENDED CLAIMS received by the International Bureau on 10 January 2025 ( 10.01.2025)

1. A method for communication between edge devices, the method comprising: determining, by at least one processor of an edge device installed in a vehicle, that the edge device has failed to connect to a cloud server; detecting, by the at least one processor, that the vehicle is not moving and is likely to remain stationary for at least a threshold period of time; upon detecting that the vehicle is not moving and is likely to remain stationary for at least a threshold period of time, broadcasting, by the at least one processor, a beacon comprising an identifier of the edge device; upon receiving a response message from one or more intermediate devices of at least one other vehicle, establishing, by the at least one processor, a short-range wireless connection with an intermediate device of the one or more intermediate devices; and uploading, by the at least one processor, health data of the edge device to the cloud server using the short-range wireless connection via the intermediate device of the other vehicle.

2. The method of claim 1 , wherein determining that the edge device has failed to connect to the cloud server comprises determining that calls made to the cloud server have failed.

3. The method of claim 1 , wherein determining that the edge device has failed to connect to the cloud server comprises diagnosing a mobile communication module of the edge device as faulty.

4. The method of claim 1 , wherein the identifier of the edge device comprises a first portion indicating a group identifier and a second portion indicating identity of the edge device; wherein the group identifier indicates a set of intermediate devices that belong to a group associated with the edge device; and wherein the one or more intermediate devices are from the group associated with the edge device.

5. The method of claim 1 , wherein the response message comprises an identifier of an intermediate device; wherein the method further comprises: selecting, by the at least one processor, the intermediate device from the one or more intermediate devices based at least on a signal strength of the response message.

6. The method of claim 5, wherein each response message comprises a status of a mobile communication module of the intermediate device, and wherein the selection of the intermediate device is further based on an identifier of the intermediate device and the status of mobile communication module of the intermediate device.

7. The method of claim 1 , wherein establishing the short-range wireless connection comprises: sending, by the at least one processor, a first command to the intermediate device to create a private Wi-Fi network or to enable a Wi-Fi hotspot; receiving, by the at least one processor, an acknowledgement message from the intermediate device, the acknowledgment message indicating that the Wi-Fi network is active or the WiFi hotspot is enabled; and establishing, by the at least one processor, a Wi-Fi connection to the intermediate device.

8. The method of claim 7, wherein the acknowledgement message comprises an SSID and a password of the Wi-Fi hotspot; and wherein the Wi-Fi connection is established using the SSID and the password.

9. The method of claim 7, wherein the acknowledgement message comprises an SSID of the Wi-Fi hotspot; wherein the method further comprises, deriving, by the at least one processor, the password of the Wi-Fi hotspot based on the SSID using decoding algorithms; and wherein the Wi-Fi connection is established using the SSID and the derived password.

10. The method of claim 7, wherein uploading the health data to the cloud server comprises:transmitting, by the at least one processor, the health data to the intermediate device using the Wi-Fi hotspot of the intermediate device; and transmitting, by the at least one processor, a second command to the intermediate device to upload the health data of the edge device, the second command indicating the intermediate device to upload the health data to the cloud server using the identifier of the edge device.

11. The method of claim 7, wherein uploading the health data to the cloud server comprises transmitting, by the at least one processor, the health data to the cloud server using the Wi-Fi hotspot of the intermediate device.

12. The method of claim 1 , wherein establishing the short-range wireless connection comprises: sending, by the at least one processor, a command to the intermediate device to switch on Bluetooth tethering of the intermediate device; receiving, by the at least one processor, an acknowledgement message from the intermediate device, the acknowledgment message indicating that the Bluetooth tethering is enabled; and establishing, by the at least one processor, a Bluetooth connection to the intermediate device through Bluetooth tethering.

13. The method of claim 1 , further comprising: generating, by the at least one processor, the health data associated with one or more components of the edge device at regular time intervals.

14. The method of claim 13, wherein the health data comprises information related to a Wi-Fi communication module and a cellular communication module, and wherein the health data comprises IP addresses, signal strength, and time stamp of the health data.

15. The method of claim 1 , further comprising: receiving, by the at least one processor, at least one of: software or firmware updates, instructions to change the Access Point Name settings, network selection mode, orpreferred network type, instructions to trigger a network setting reset, and instructions to trigger a hard reboot.

16. The method of claim 1 , wherein detecting that the vehicle is not moving and is likely to remain stationary for at least a threshold period of time comprises detecting, by the at least one processor, that the ignition has turned off.

17. A computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors configured to carry out the method of any preceding claim.

Images