Inspection spacing system

Abstract

A system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. Operations include configuring a check interval protocol for an electronic control unit (ECU), initializing a check failure counter for the check interval protocol, and establishing a message queuing telemetry transfer (MQTT) session. The operations further include detecting a check state of the check interval protocol, automatically determining an optimal check interval for the check interval protocol based on the detected check state and a check failure counter, constructing a check interval topic for the MQTT session, and issuing the determined optimal check interval to the check interval topic.

Description

Technical Field

[0001] The present disclosure generally relates to an inspection interval system and an automatic determination of an optimal inspection interval. Background Art

[0002] The information provided in this section is for the purpose of presenting the background of the present disclosure generally. To the extent described in this section, the work of the presently named inventors, as well as aspects of the descriptions that may not qualify as prior art at the time of filing, are neither expressly nor implicitly admitted as prior art against the present disclosure.

[0003] Networks that can communicate with external devices typically use firewalls to prevent malicious connections. After a predetermined period of time in which the firewall does not receive a heartbeat connection with an external device, the firewall can automatically disconnect any connections. The heartbeat connection is used as a sign of an ongoing connection between the firewall and the external device. To avoid an accidental disconnection, the external device can perform heartbeat connections at an increased rate, which may ultimately reduce the overall efficiency of the external device. Additionally, the firewall may change and / or be updated over time, so the predetermined time for the heartbeat connection may change. Traditional systems require the external device to use some form of heartbeat connection to contact a network server and do not allow the server to initiate contact with the external device. Summary of the Invention

[0004] In some aspects, a computer-implemented method, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include configuring an inspection interval protocol for an electronic control unit (ECU), connecting the ECU to a data network including a packet firewall, establishing a Message Queuing Telemetry Transport (MQTT) session corresponding to the data network, and detecting an inspection status of the inspection interval protocol relative to the packet firewall. The operations also include automatically determining an optimal inspection interval of the inspection interval protocol based on the inspection status, constructing an inspection interval topic including the determined optimal inspection interval for the MQTT session, and publishing the determined optimal inspection interval to the inspection interval topic.

[0005] In some examples, detecting the inspection status can include detecting a failure. Optionally, automatically determining the optimal inspection interval can include decrementing an inspection interval value and monitoring whether the inspection status is successful. In some configurations, detecting the inspection status can include detecting a success, and automatically determining the optimal inspection interval can include incrementing the inspection interval value until a failure. The operations can also include decrementing the inspection interval value to the second-to-last interval value corresponding to the optimal inspection interval value. In some cases, configuring the inspection interval protocol can include using a default inspection interval and monitoring the inspection status of the default inspection interval. The operations can also include sharing the optimal inspection interval with a subscribing electronic control unit (ECU) for the inspection interval topic, wherein publishing the inspection interval topic includes notifying the subscribing ECU of the optimal inspection interval value.

[0006] In other aspects, a system includes data processing hardware and memory hardware communicatively coupled to the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include configuring an inspection interval protocol for an electronic control unit (ECU), initializing an inspection failure counter for the inspection interval protocol, and establishing a Message Queuing Telemetry Transport (MQTT) session. The operations also include detecting an inspection status of the inspection interval protocol, automatically determining an optimal inspection interval for the inspection interval protocol based on the detected inspection status and the inspection failure counter, constructing an inspection interval topic for the MQTT session, and publishing the determined optimal inspection interval to the inspection interval topic.

[0007] In some examples, detecting the inspection status can include detecting a failure. Optionally, detecting the inspection status can include detecting a failure, and automatically determining the optimal inspection interval can include decrementing an inspection interval value and monitoring whether the inspection status is successful. In some cases, detecting the inspection status can include detecting a success, and automatically determining the optimal inspection interval can include incrementing the inspection interval value until a failure. The operations can also include decrementing the inspection interval value to the second-to-last interval value corresponding to the optimal inspection interval value. In other examples, configuring the inspection interval protocol can include using a default inspection interval and monitoring the inspection status of the default inspection interval. In some configurations, establishing the MQTT session can include connecting the ECU to a data network configured with a packet firewall that is configured to receive inspections of the inspection interval protocol from the ECU.

[0008] In other aspects, a computer-implemented method causes data processing hardware to perform operations when executed by the data processing hardware. The operations include connecting an electronic control unit (ECU) to a data network, configuring an inspection interval protocol for the ECU, the inspection interval protocol including a default inspection interval configured to send an inspection to a firewall of the data network, and detecting an inspection status associated with an inspection interval value of the default inspection interval. The operations also include adjusting an interval value of the inspection interval protocol, monitoring the inspection status of the inspection interval value, and determining an optimal inspection interval based on the adjusted interval value and the inspection status of the monitored inspection interval value. Additionally, the operations include transmitting the optimal inspection interval to a subscribing electronic control unit (ECU) of the data network.

[0009] In some examples, connecting to a data network may include establishing a Message Queuing Telemetry Transport (MQTT) session and constructing an inspection interval topic, and transmitting an optimal inspection interval may include publishing an optimal inspection interval value notification on the inspection interval topic. Optionally, transmitting the optimal inspection interval may include having a subscribing ECU verify the optimal inspection interval received from the inspection interval topic. In some cases, adjusting the interval value may include increasing the inspection interval value, and monitoring the inspection status includes detecting a failure of the inspection status. In a further example, determining the optimal inspection interval may include reducing the inspection interval value to the penultimate interval value based on the adjusted interval value and the failure of the inspection status. In other examples, detecting the inspection status may include a failure of the inspection status, and adjusting the interval value includes reducing the inspection interval value. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings described herein are for illustrative purposes only of selected configurations and are not intended to limit the scope of the present disclosure.

[0011] Figure 1 is a schematic perspective view of a vehicle including an electronic control unit (ECU) configured with an inspection interval protocol in accordance with the present disclosure;

[0012] Figure 2 is a block diagram of an inspection interval system in accordance with the present disclosure;

[0013] Figure 3 is an example flowchart of an inspection interval system in accordance with the present disclosure;

[0014] Figure 4 is another example flowchart of an inspection interval system in accordance with the present disclosure;

[0015] Figure 5 is Figure 4 an example flowchart of the inspection interval system of;

[0016] Figure 6 is Figure 5 an example flowchart of the inspection interval system of; and

[0017] Figure 7 is Figure 4 an example flowchart of the inspection interval system of.

[0018] In all the drawings, corresponding reference numerals indicate corresponding parts. DETAILED DESCRIPTION

[0019] Example configurations will now be described more fully with reference to the accompanying drawings. The example configurations are provided so that this disclosure will be thorough and will fully convey the scope of the disclosure to those of ordinary skill in the art. Specific details are set forth, such as examples of specific components, devices, and methods, to provide a thorough understanding of the configurations of the disclosure. It will be apparent to those of ordinary skill in the art that specific details need not be employed, that the example configurations may be embodied in many different forms, and that the specific details and example configurations should not be construed as limiting the scope of the disclosure.

[0020] The terminology used herein is for the purpose of describing particular example configurations only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may also be intended to include the plural forms, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “includes,” and “having” are inclusive and therefore specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. Method steps, processes, and operations described herein should not be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. Additional or alternative steps may be employed.

[0021] When an element or layer is referred to as being “on,” “engaged to,” “connected to,” “attached to,” or “coupled to” another element or layer, it may be directly on, engaged, connected, attached, or coupled to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being “directly on,” “directly engaged to,” “directly connected to,” “directly attached to,” or “directly coupled to” another element or layer, there may be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted in a like manner (e.g., “between” versus “directly between,” “adjacent” versus “directly adjacent,” etc.). As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0022] The terms first, second, third, etc. may be used herein to describe various elements, components, regions, layers, and / or sections. These elements, components, regions, layers, and / or sections should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer, or section from another. Terms such as “first,” “second,” and other numerical terms do not imply an order or sequence unless the context clearly indicates otherwise. Thus, a first element, component, region, layer, or section discussed below may be referred to as a second element, component, region, layer, or section without departing from the teachings of the example configurations.

[0023] In this application, including the following definitions, the term module may be replaced by the term circuit. The term "module" may refer to an application specific integrated circuit (ASIC) or a part thereof, or include an application specific integrated circuit (ASIC); digital, analog or mixed analog / digital discrete circuits; digital, analog or mixed analog / digital integrated circuits; combinational logic circuits; field programmable gate arrays (FPGAs); processors (shared, dedicated or grouped) that execute code; memories (shared, dedicated or grouped) that store code executed by the processors; other suitable hardware components that provide the functions; or some or all of the above combinations, such as in a system on a chip.

[0024] The term code used above may include software, firmware and / or microcode, and may refer to programs, routines, functions, classes and / or objects. The term shared processor includes a single processor that executes some or all of the code from multiple modules. The term grouped processors includes a processor that, in combination with additional processors, executes some or all of the code from one or more modules. The term shared memory includes a single memory that stores some or all of the code from multiple modules. The term grouped memory includes a memory that, in combination with additional memories, stores some or all of the code from one or more modules. The term memory may be a subset of the term computer-readable medium. The term computer-readable medium does not include transient electrical and electromagnetic signals propagated through the medium, and thus may be considered tangible non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, including non-volatile memory, magnetic memory and optical memory.

[0025] The devices and methods described in this application may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer programs may also include and / or rely on stored data.

[0026] A software application (i.e., software resource) may refer to computer software that causes a computing device to perform tasks. In some examples, a software application may be referred to as an "application", "app" or "program". Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications and gaming applications.

[0027] A non-transitory memory can be a physical device for temporarily or permanently storing programs (e.g., sequences of instructions) or data (e.g., program state information) for use by a computing device. The non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as a boot program). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and magnetic disks or tapes.

[0028] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in a high-level procedural and / or object-oriented programming language and / or assembly / machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) that provides machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal that provides machine instructions and / or data to a programmable processor.

[0029] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed application-specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These different implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system including at least one programmable processor, at least one input device, and at least one output device, the programmable processor being either special-purpose or general-purpose and being coupled to receive data and instructions from, and to send data and instructions to, a storage system.

[0030] The processes and logical flows described in this specification can be performed by one or more programmable processors, also known as data processing hardware, executing one or more computer programs to perform functions by operating on input data and generating output. These processes and logical flows can also be performed by special-purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit). By way of example, processors suitable for the execution of a computer program include both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include or be operatively coupled to one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, to receive data from or transfer data to the mass storage device, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including by way of example semiconductor storage devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special-purpose logic circuitry.

[0031] For providing interaction with a user, one or more aspects of the present disclosure can be implemented on a computer having a display device for displaying information to the user, such as a CRT (Cathode Ray Tube), an LCD (Liquid Crystal Display) monitor, or a touch screen, and optionally a keyboard and a pointing device, such as a mouse or a trackball, by which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound, voice, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

[0032] Reference Figures 1-3, the inspection interval system 10 includes at least one electronic control unit (ECU) 12 configured to execute an inspection interval protocol 14. The inspection interval system 10 further includes a data network 100 communicatively coupled to the ECU 12. The data network 100 includes a packet firewall 102 and a Message Queuing Telemetry Transport (MQTT) session 104. The data network 100 may include, but is not limited to, an Access Point Name (APN) and / or a Data Network Name (DNN), which may include a cellular network. For example, the data network 100 is configured to switch an internet connection to the ECU 12. As described herein, the ECU 12 is configured to be part of a vehicle 200. However, the ECU 12 may be part of any viable device configured to communicate with the data network 100. Additionally or alternatively, the inspection interval protocol 14 may utilize and / or be configured with software of any viable device. The ECU 12 includes data processing hardware 16 configured to perform operations and memory hardware 18 communicatively coupled to the data processing hardware 16. The memory hardware 18 stores instructions that, when executed by the data processing hardware 16, cause the data processing hardware 16 to perform the operations set forth herein.

[0033] In some examples described herein, the inspection interval system 10 may further include a subscribing ECU 300. The subscribing ECU 300 may be a third-party ECU subscribed to an inspection interval topic 106 of the MQTT session 104, which will be described in more detail below, and thus may be communicatively coupled to the data network 100. Although described as a single subscribing ECU 300, it is contemplated that there may be multiple third-party ECUs 300 subscribed to the inspection interval topic 106. Similar to the ECU 12, the subscribing ECU 300 is configured with data processing hardware 302 and memory hardware 304. The data processing hardware 302 is configured to execute an inspection interval protocol 306, which includes performing an optimal inspection interval value verification 308, which will be described in more detail below.

[0034] Continuing to refer Figures 1-3 , the data processing hardware 16 of the ECU 12 executes the inspection interval protocol 14, which sends an inspection 20 to the packet firewall 102 of the data network 100 at a predetermined interval. The memory hardware 18 stores an inspection interval value 20a, which typically corresponds to the duration between each issued inspection 20. The inspection 20 is configured to establish and maintain a connection between the ECU 12 and the data network 100 by communicating via a connection to the packet firewall 102. As described in more detail below, the inspection interval protocol 14 may be used to determine an optimal inspection interval 22.

[0035] The optimal check interval 22 is defined as the checks 20 issued at a time interval that minimizes the operating load of the ECU 12 while maintaining a connection to the data network 100. For example, the optimal check interval 22 can optimize the efficiency of the ECU 12 by issuing checks 20 at a time period short enough to maintain a connection to the packet firewall 102 and long enough to conserve the battery life of the ECU 12 and / or the vehicle 200. The packet firewall 102 is configured to periodically monitor the checks 20 and can disconnect the input connection based on a delayed check 20. Accordingly, the connection between the ECU 12 and the data network 100 is monitored and protected via the packet firewall 102 and the checks 20. The check interval value 20a determines the rate at which the check interval protocol 14 issues the checks 20. The ECU 12 can receive an acknowledgement 112 from the packet firewall 102 in response to the check 20, which will be described in more detail below.

[0036] The data processing hardware 16 can configure the check interval protocol 14 with a check failure counter 24. The check failure counter 24 is configured to cooperate with the check status 26 for each respective check 20 of the data network 100. For example, the check status 26 includes a failure status or failure 28 and a success status or success 30. As described above, the checks 20 are used to maintain an active connection to the packet firewall 102 of the data network 100. The checks 20 provide feedback to keep the connection active and fresh to the packet firewall 102, which in turn can provide access to the gateway 110 to the ECU 12.

[0037] The packet firewall 102 is configured with a predetermined time period during which the connection between the ECU 12 and the data network 100 can be maintained without the packet firewall 102 receiving a check 20. Accordingly, the configuration of the check interval protocol 14 is designed to match the predetermined time period of the packet firewall 102. As described below, it is envisioned that the predetermined time period can change over time or otherwise vary. Accordingly, the check interval protocol 14 can be continuously updated and configured to accommodate the packet firewall 102 connection and identify the optimal check interval 22. The data processing hardware 16 can configure the check interval protocol 14 with an interval adjustment 32, which helps to adjust or otherwise change the check interval value 20a based on the packet firewall 102, which will be described in more detail below.

[0038] In some examples, the initial configuration of the verification interval protocol 14 can establish a connection between the ECU 12 and the data network 100 using a default verification interval 34. The default verification interval 34 can be pre-determined within the ECU 12. The verification interval protocol 14 can run the default verification interval 34 and monitor the verification status 26 to determine whether the default verification interval 34 is successful. If the ECU 12 detects a successful status 30, the ECU 12 can maintain the connection with the data network 100 through the default verification interval 34. The ECU 12 can also utilize an interval adjustment 32 to increment the verification interval value 20a. Incrementing or increasing the verification interval value 20a may be beneficial for improving the overall efficiency of the ECU 12 by freeing up capacity that could otherwise be used to perform the verification 20. For example, increasing the duration between the verification 20 with the packet firewall 102 can provide energy savings and efficiency for the ECU 12 during operation while maintaining the connection with the data network 100. The interval adjustment 32 of the verification interval protocol 14 will be described in more detail below.

[0039] In some examples, the verification failure counter 24 is initialized before establishing a connection with the data network 100. The verification failure counter 24 includes a verification failure counter limit 24a, which can be used to attempt to establish a connection to the MQTT session 104 with the data network 100. For example, the ECU 12 can detect a failure status 28 of the verification 20 such that the number of failures 28 of the verification 20 can correspond to the verification failure counter limit 24a. In this example, the data processing hardware 16 performs operations to automatically determine the optimal verification interval 22 of the verification interval protocol 14 based on the detected verification status 26. In some cases, the data processing hardware 16 can automatically determine the optimal verification interval 22 based on the verification status 26 and the verification failure counter 24.

[0040] Still referring to Figures 1-3 , as a result of the authorized connection with the data network 100 via the packet firewall 102, the ECU 12 establishes an MQTT session 104 corresponding to the data network 100. The MQTT session 104 provides a lightweight long-link connection between the data network 100 and the ECU 12. It is generally contemplated that the data network 100 can correspond to a carrier server and / or a backend server. In either example, the packet firewall 102 can include a gateway 110 and an acknowledgement 112. The gateway 110 provides an interface to the Internet service. Thus, the connection established between the ECU 12 and the data network 100 provides access to the gateway 110 and the ability to share information through the gateway 110, as described in more detail below.

[0041] As a method of communicating with the ECU 12, an acknowledgement 112 is sent from the data network 100. For example, once a connection is established, the data processing hardware 16 may set a verification flag 36 corresponding to the connection established between the data network 100 and the ECU 12. The acknowledgement 112 can be used to verify the verification flag 36. The acknowledgement 112 can also be used in conjunction with a verification failure counter 24. For example, if the ECU 12 does not receive the acknowledgement 112 from the packet firewall 102, the verification failure counter 24 can be incremented. The verification interval protocol 14 determines whether the incremented verification failure counter 24 exceeds a verification failure counter limit 24a. In some examples, due to the lack of the acknowledgement 112 and the last verification state 26 corresponding to the failure 28, the verification failure counter 24 may exceed the limit 20a. In this example, the ECU 12 can then decrement the verification interval value 20a so that the verification 20 is sent to the packet firewall 102 more frequently.

[0042] Although the ECU 12 is configured to communicate with the data network 100, it is also contemplated that the data network 100 can communicate with the ECU 12. Once the verification failure counter limit 24a is obtained, the data processing hardware 16 can be reset to automatically determine an optimal verification interval 22 using the process described herein. The acknowledgement 112 from the data network 100 for the verification 20 is one example of communication from the data network 100 to the ECU 12 and / or the subscription ECU 300. Other examples of communication from the data network 100 to the ECU 12 and / or the subscription ECU 300 will be described in more detail below.

[0043] The data processing hardware 16 is configured to ultimately determine the optimal verification interval 22 based on the verification state 26 relative to the packet firewall 102. The optimal verification interval 22 can be automatically determined by performing an interval adjustment 32. For example, the data processing hardware 16 can automatically monitor the verification state 26 and increment or decrement the verification interval value 20a. Ultimately, the optimal verification interval 22 is defined by the longest duration of maintaining a connection with the packet firewall 102 between verifications 20. Although the data processing hardware 16 can determine the optimal verification interval 22 for a given time frame, it is contemplated that the packet firewall 102 can be updated periodically such that the verification state 26 may change accordingly. Therefore, the verification interval protocol 14 is configured to continuously monitor whether the verification state 26 fails 28. If there are multiple failures 28, the verification interval value 20a is decreased or decremented because the packet firewall 102 does not maintain the connection. For example, when the failure 28 is repeatedly detected, the packet firewall 102 does not receive the verification 20 frequently enough, and thus the packet firewall 102 disconnects from the ECU 12.

[0044] When automatically determining the optimal verification interval 22, the verification interval value 20a is incremented or decremented according to the initial verification state 26. For example, if the verification state 26 is a failure 28, the verification interval value 20a is decremented or reduced until the verification state 26 is a success 30. In other examples, if the initial verification state 26 is a success 30, the verification interval value 20a may be incremented or increased until the verification state 26 is a failure 28. Once the verification interval value 20a has been incremented to a failure 28, based on the adjusted interval value 20a and the failure 28 of the verification state 26, the verification interval value 20a is reduced to the penultimate interval value 20b.

[0045] The penultimate interval value 20b may correspond to the optimal verification interval 22. For example, the penultimate interval value 20b is the last successful verification 20 before a failure 28 is detected. Thus, the penultimate interval value 20b is the longest duration between verifications 20 that maintain the connection to the packet firewall 102. As part of the verification interval protocol 14, the process of determining the optimal verification interval 22 is automatically performed by the data processing hardware 16 to continuously improve the connection efficiency between the ECU 12 and the data network 100. Once a success 30 is repeatedly detected, the data processing hardware 16 may set a verification flag 36 associated with the optimal verification interval 22.

[0046] Further reference Figures 1-3 As such, the ECU 12 may share the optimal verification interval 22 with the data network 100. For example, the ECU 12 may construct a verification interval topic 106 including the optimal verification interval 22 for the MQTT session 104. The verification interval topic 106 may also include an optimal verification interval value notification 108, which may be shared with any potential subscribing ECU 300. The data processing hardware 16 may perform a publish event 40. The publish event 40 provides the optimal verification interval 22 to the verification interval topic 106 and thus to any subscribing ECU 300 to the verification interval topic 106 for the MQTT session 104. The data network 100 may transmit the published optimal verification interval 22 to the ECU 300 subscribing to the verification interval topic 106.

[0047] The subscribing ECU 300 may also connect to the MQTT session 104 in a similar manner as described herein for the ECU 12. However, the subscribing ECU 300 may receive the optimal verification interval value notification 108 from the verification interval topic 106, which may minimize the duration spent by the data processing hardware 302 of the subscribing ECU 300 to determine the optimal verification interval 22. Once the subscribing ECU 300 receives the optimal verification interval value notification 108, the subscribing ECU 300 performs an optimal verification interval value verification 308. Thus, the subscribing ECU 300 receives the optimal verification interval 22 as a result of subscribing to the verification interval topic 106, but verifies the optimal verification interval 22 through the optimal verification interval value verification 308.

[0048] For example, a subscribing ECU 300 connects to the data network 100 and subscribes to the inspection interval topic 106 as part of the established MQTT session 104. The subscribing ECU 300 requests any messages related to the inspection interval topic 106. If the subscribing ECU 300 receives the optimal inspection interval value notification 108, the subscribing ECU 300 will verify the optimal inspection interval 22. The optimal inspection interval value verification 308 is a process similar to the determination of the optimal inspection interval 22 described above. If the optimal inspection interval value notification 108 is not available, the subscribing ECU 300 will perform the process for automatically determining the optimal inspection interval 22 described above. For example, the subscribing ECU 300 starts with the default inspection interval 34 and continues to increment and / or decrement until the optimal inspection interval 22 is determined.

[0049] Still referring to Figures 1-3 , Figure 3 FIG. shows an example flow chart of the inspection interval system 10. In the initial step 500, the ignition of the vehicle 200 is activated to the "on" state, and at 502, the ECU 12 is connected to the data network 100. The ECU 12 can then establish an MQTT session 104 at 504 and subscribe to the inspection interval topic 106 at 506. At 508, the ECU 12 determines whether the optimal inspection interval 22 of the data network 100 has been obtained. If the optimal inspection interval 22 has been obtained, the process of determining the optimal inspection interval 22 can end. If the optimal inspection interval 22 has not been obtained, the ECU 12 uses the default inspection interval 34 at 510. Then at 512, the ECU 12 determines whether the default inspection interval 34 is successful. If the default inspection interval 34 results in success 30, the ECU 12 increments the inspection interval value 20a at 514 until failure 28. In response to the failure 28, the ECU 12 decrements the inspection interval value 20a by one increment at 516. Then at 518, the ECU 12 determines that the optimal inspection interval 22 has been found. If the default inspection interval 34 is a failure 28, the ECU 12 decrements the inspection interval value 20a at 520 until success 30, and then continues to step 518. Then at 522, the ECU 12 can publish the optimal inspection interval 22 to the inspection interval topic 106.

[0050] Now referring to Figures 4-7, shows another example flowchart of the inspection interval system 10. In the initial step 600, the ignition of the vehicle 200 is activated to the "on" state, and at 602, the ECU 12 connects to the data network 100. Then, the ECU 12 can initialize the inspection failure counter 24 at 604, and subsequently establish the MQTT session 104 at 606. The ECU 12 determines at 608 whether the MQTT session 104 is established. If the MQTT session 104 is not established, the ECU 12 continues to attempt to establish the MQTT session 104. If the MQTT session 104 is established, the ECU 12 determines at 610 whether the inspection flag 36 has been adjusted. If the inspection flag 36 has not been adjusted, the ECU 12 subscribes to the inspection interval topic 106 at 612. The ECU 12 can then determine at 614 whether there is an inspection interval value 20a received from the inspection interval topic 106. If the inspection interval value 20a is received, the ECU 12 sets the inspection interval value 20a to the received value at 616. If the inspection interval value 20a is not received, the ECU 12 sets the inspection interval value 20a to the default inspection interval 34 at 618.

[0051] The ECU 12 then performs the inspection 20 at 620 and determines at 622 whether an acknowledgement 112 is received. If the acknowledgement 112 is not received, the ECU 12 increments the inspection failure counter 24 at 624. The ECU 12 determines at 626 whether the inspection failure counter 24 exceeds the inspection failure counter limit 24a. If the inspection failure counter 24 does not exceed the inspection failure counter limit 24a, the ECU 12 increments the inspection failure counter 24 at 628 and disconnects the MQTT session 104 at 630.

[0052] If the inspection failure counter 24 does indeed exceed the inspection failure counter limit 24a, the ECU 12 determines the last inspection status 26 at 632. If the inspection status 26 is a failure 28, the ECU 12 decrements the inspection interval value 20a at 634 and sets the inspection flag 36 at 636. Once the inspection flag 36 is set, the ECU 12 can disconnect the MQTT session 104. Returning to step 622, if the acknowledgement 112 is received, the ECU 12 determines at 640 whether the inspection flag 36 is set based on the optimal inspection interval 22. If not, the ECU 12 sets the last inspection status 26 to a success 30 at 642. The ECU 12 can then store the last successful inspection interval value 20a at 644 and determines at 646 that the optimal inspection interval 22 has been found. In response, the ECU 12 sets the inspection flag 36 corresponding to the optimal inspection interval 22 at 648. The ECU 12 can then disconnect from the MQTT session 104 at 650 and at 606 ( Figure 4 ) continue to re - establish the MQTT session 104 to continue with subsequent steps and processes.

[0053] If the last verification status 26 is successful 30, the ECU 12 can set the verification interval value 20a to the last successful verification interval value 20a at 652. The ECU 12 then sets the optimal verification interval 22 at 654. The ECU 12 determines at 656 whether the verification flag 36 has been adjusted. If the verification flag 36 has not been adjusted, the process ends. If the verification flag 36 has been adjusted, the ECU 12 publishes the optimal verification interval 22 to the verification interval topic 106 at 658.

[0054] Referring again to Figures 1-7 , the verification interval system 10 is used to maximize the overall energy efficiency of the vehicle 200 while minimizing data usage and potential costs incurred due to repeated verifications utilizing the data network 100. The verification interval protocol 14 is configured to automatically adjust the verification interval value 20a by incrementing and / or decrementing the verification interval value 20a until the optimal verification interval 22 is determined. The ECU 12 can publish the optimal verification interval 22 to the verification interval topic 106 of the MQTT session 104 of the data network 100 for use by other third - party ECUs 300. The third - party ECU 300 can receive the optimal verification interval 22 by subscribing to the verification interval topic 106. Although the subscribing ECU 300 can receive and utilize the optimal verification interval 22, the subscribing ECU 300 is configured to perform an optimal verification interval value verification 308 to verify that the received optimal verification interval 22 is still optimal for the packet firewall 102. As described herein, the optimal verification interval 22 can change over time based on updates and changes to the packet firewall 102.

[0055] Numerous embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of the present disclosure. Accordingly, other embodiments are also within the scope of the following claims.

[0056] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but are interchangeable where applicable and can be used in a selected configuration. This can vary in many ways. Such variations should not be regarded as a departure from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

Claims

1. A computer-implemented method that, when executed by data processing hardware, causes the data processing hardware to perform operations including the following: Configure an inspection interval protocol for an electronic control unit (ECU); Connect the ECU to a data network including a packet firewall; Establish a Message Queuing Telemetry Transport (MQTT) session corresponding to the data network; Detect the inspection status of the inspection interval protocol relative to the packet firewall; Automatically determine an optimal inspection interval for the inspection interval protocol based on the inspection status; Construct an inspection interval topic for the MQTT session including the determined optimal inspection interval; and Publish the determined optimal inspection interval to the inspection interval topic.

2. The method according to claim 1, wherein, Detecting the inspection status includes detecting a failure.

3. The method according to claim 2, wherein, Automatically determining the optimal inspection interval includes decrementing an inspection interval value and monitoring whether the inspection status is successful.

4. The method according to claim 1, wherein, Detecting the inspection status includes detecting success, and automatically determining the optimal inspection interval includes incrementing the inspection interval value until failure.

5. The method according to claim 4, further comprising decrementing the inspection interval value to the second-to-last interval value corresponding to the optimal inspection interval value.

6. The method according to claim 1, wherein, Configuring the inspection interval protocol includes using a default inspection interval and monitoring the inspection status of the default inspection interval.

7. The method according to claim 1, further comprising sharing the optimal inspection interval with a subscription electronic control unit (ECU) for the inspection interval subject, wherein, Publishing the inspection interval topic includes notifying a subscribing ECU of the optimal inspection interval value.

8. The method according to claim 1, wherein The packet firewall is configured to receive an inspection of the inspection interval protocol from the ECU.

9. The method according to claim 7, wherein, Announcing the optimal inspection interval includes verifying, by the subscribing ECU, the optimal inspection interval received from the inspection interval topic.

10. The method according to claim 1, further comprising incrementing the inspection interval value and monitoring the inspection status for failure.

Images