Adaptive diagnostic message routing

Abstract

In various embodiments, adaptive diagnostic message routing is provided. An HPC platform onboard a vehicle may comprise a unified diagnostic gateway that can process and route diagnostic messages between diagnostic clients that access a vehicle's diagnostic systems and the onboard resources (whether legacy ECU hardware devices or HPC ECU nodes) that provide diagnostics-related data. The adaptive HPC diagnostic message routing may be performed at least in part based on the protocol by which the diagnostic client makes its query to the unified diagnostic gateway, and / or the onboard destination resource to which the query is directed (e.g., the class of ECU (legacy or HPC)) providing the response data). Advantageously, the embodiments for adaptive diagnostic message routing described herein provide for intelligent routing of diagnostic information on HPC vehicles to support onboard diagnostic activities using either legacy or SOVD protocol diagnostic tools.

Description

ADAPTIVE DIAGNOSTIC MESSAGE ROUTINGBACKGROUND OF THE INVENTION

[0001] Unified Diagnostic Services (UDS) and Society of Automotive Engineers (SAE) J1939 are diagnostic communication protocols used in the automotive industry for vehicle maintenance and troubleshooting activities. UDS, defined in International Standards Organization (ISO) 14229, is a protocol used within onboard electronic control units (ECUs) of vehicles for diagnostics and communication. UDS allows for various diagnostic services, such as reading and clearing error codes, reprogramming, and interacting with the ECU hardware. UDS operates in conjunction with layers of the Open Systems Interconnection (OSI) model, providing a sophisticated means of communication between the diagnostics tool and vehicle ECUs. SAE J1939 is a protocol tailored for heavy-duty vehicles and is based on the Controller Area Network (CAN) bus. SAE JI 939 defines how ECUs communicate over a CAN bus, with respect to message format, prioritization, and data content. SAE JI 939 specifically deals with diagnostics for vehicle maintenance and troubleshooting, outlining the process for exchanging diagnostic information and defining messages for diagnostic purposes. Diagnostic information includes active and previously active diagnostics trouble codes (DTCs), freeze-frame parameters (e.g., engine RPM, vehicle speed, coolant temperature, throttle position, oxygen sensor reading, and the like), and / or other vehicle information, facilitating the maintenance and repair of vehicle systems. ISO 15031 specifies a set of standard diagnostic services and a protocol used for passenger car emissions related diagnostics to read emissions-relevant information from on board diagnostics (OBD). UDS, SAE J1939 and ISO 15031 each provide ways to facilitate efficient troubleshooting and maintenance, ensuring vehicle safety, and compliance with regulatory standards. High-Performance Compute (HPC) vehicles represent a next generation in automotive technology, providing an onboard computing architecture that provides a platform for managing numerous vehicle systems. The onboard compute is designed to handle complex processing of sensor data for advanced driver-assistance systems (ADASs), infotainment, and other connectivity features. The Service-Oriented Vehicle Diagnostics (SOVD) is a new diagnostic standard developed by the Association of Standardization of Automation and Measuring Systems (ASAM) for use on HPC-based vehicles. SOVD defines an application programming interface (API) based framework for diagnosing and communicating with software-based vehicles. A SOVD framework provides uniform access to the diagnostic content of HPC platforms and theirrelated applications, as well as of classic ECUs, so that diagnostics may be performed using both traditional ECU-based diagnostics and emerging software-based systems.SUMMARY OF THE INVENTION

[0002] This summary is intended to introduce a selection of concepts in a simplified form that are further described below in the detailed description section of this disclosure. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in isolation to determine the scope of the claimed subject matter.

[0003] In brief, and at a high level, this disclosure describes diagnostic message routing for on-board vehicle diagnostic systems. In contrast to currently available vehicle diagnostic technologies, the present disclosure describes a unified diagnostic interface framework based on adaptive HPC diagnostic message routing. An HPC platform onboard a vehicle may comprise a unified diagnostic gateway that can process and route diagnostic messages between diagnostic clients (diagnostic tools) that access a vehicle’s diagnostic systems and the onboard resources (whether legacy ECU hardware devices or HPC ECU nodes) that provide diagnostics-related data. The adaptive HPC diagnostic message routing may be performed at least in part based on the protocol by which the diagnostic client makes its query to the unified diagnostic gateway, and / or the onboard destination resource to which the query is directed (e.g., the class of ECU (legacy or HPC)) providing the response data). Advantageously, the embodiments for adaptive diagnostic message routing described herein provide for intelligent routing of diagnostic information on HPC vehicles to support onboard diagnostic activities using either legacy or SOVD protocol diagnostic tools. It should be understood that in various embodiments, a diagnostic client may interface with a unified diagnostic gateway via either wired or wireless diagnostic ports. Moreover, in some embodiments, a diagnostic client may include a remote diagnostic client and / or a cloud-based telematics platform, that may access the unified diagnostic gateway via a wireless communications network (e.g., a cellular and / or 5G telecommunications network).BRIEF DESCRIPTION OF THE DRAWING

[0004] The embodiments presented in this disclosure related to systems, methods, and technologies for adaptive diagnostic message routing are described in detail below withreference to the attached drawing figures, which illustrate non-limiting examples of the disclosed subject matter, wherein:

[0005] FIG. 1 is a block diagram illustrating an example onboard diagnostics system comprising a unified diagnostic gateway in accordance with embodiments of the present disclosure;

[0006] FIG. 2 is a block diagram illustrating an example process flow for a unified diagnostic gateway, in accordance with embodiments of the present disclosure;

[0007] FIG. 3 is a diagram illustrating an example data flow diagram for a universal common-protocol interface onboard diagnostics system, in accordance with embodiments of the present disclosure;

[0008] FIG. 4 is a block diagram illustrating an example data flow diagram for a split port onboard diagnostics system, in accordance with embodiments of the present disclosure;

[0009] FIG. 5 is a block diagram illustrating an example data flow diagram for an alternative unified diagnostic gateway where electronic control units are fully hosted by a high- performance compute platform, in accordance with embodiments of the present disclosure;

[0010] FIG. 6 is a diagram illustrating various interface examples for connecting a diagnostic client to a unified diagnostic gateway of an onboard diagnostics system, in accordance with embodiments of the present disclosure;

[0011] FIG. 7 is a flow chart illustrating a method for adaptive diagnostic message routing, in accordance with embodiments of the present disclosure;

[0012] FIG. 8 is a diagram illustrating an example computing environment suitable for supporting the operations and functions described herein, in accordance with embodiments of the present disclosure; and

[0013] FIG. 9 is a diagram illustrating an example cloud-based computing environment, in accordance with embodiments of the present disclosure.DETAILED DESCRIPTION OF THE INVENTION

[0014] This detailed description is provided in order to meet statutory requirements. However, this description is not intended to limit the scope of the disclosure described herein. Rather, the claimed subject matter may be embodied in different ways, to include different steps, combinations of steps, different elements, and / or different combinations of elements, similar to those described herein, and in conjunction with other present or future technologies.Moreover, although the terms “step” and “block” may be used herein to identify different elements of methods employed, the terms should not be interpreted as implying any particular order among or between different elements except when the order is explicitly described.

[0015] In general, this disclosure is directed to adaptive diagnostic message routing for on-board vehicle diagnostic systems. A challenge has emerged in providing on-board vehicle diagnostic system functions to vehicles manufactured during this time, as the automotive industry engages in a phased transition from traditional (legacy) diagnostic protocols (e.g., UDS, SAE J1939, and / or ISO 15031 protocols) to Service-Oriented Vehicle Diagnostics (SOVD)-based diagnostics. For example, many new vehicles may be equipped with prior technology electronic control units (ECUs) that use communications for diagnostic functions based on pre-SOVD standards, as well as having SOVD native ECUs that use SOVD-based communications for diagnostic functions. This can lead to complications in servicing vehicles, as many vehicle service facilities may have access to legacy diagnostic testing tools (e.g., compatible with UDS, SAE J1939 and / or ISO 15031 protocols) to interface with legacy technology ECUs, but may not have invested in tools compatible with SOVD native ECUs. For example, a vehicle emissions testing facility is a common limited service facility likely to have emission testing systems that are based on legacy pre-SOVD diagnostic testing tools. A newer high-performance compute (HPC) vehicle using SOVD-based diagnostics that does not support legacy pre-SOVD diagnostic testing tools would not be able to be tested at such a vehicle emissions testing facility to obtain a vehicle emissions compliance certification from that facility. Moreover, even newer HPC vehicles that implement SOVD-based diagnostics may continue to retain legacy technology ECU hardware for some vehicle systems (e.g., emissions system monitoring).

[0016] One approach to facilitating both legacy and SOVD standard diagnostics for an HPC vehicle would be to design the vehicle with parallel independent diagnostic paths. That is, a legacy diagnostic path may provide a communication bus for legacy diagnostic testing tools to access pre-SOVD ECUs, and a separate SOVD diagnostic path may connect SOVD diagnostic testing tools with SOVD ECUs. However, the duplicative nature of such a design with two independent diagnostic paths may increase the cost and complexity of the vehicles and service facilities that would be needed to maintain diagnostic tools for both SOVD and legacy (pre-SOVD) ECUs in order to obtain a comprehensive set of diagnostic information across a vehicle’s full complement of ECUs.

[0017] In contrast to currently available vehicle diagnostic technologies, the presentdisclosure describes a unified diagnostic interface framework based on adaptive HPC diagnostic message routing. In some embodiments, an HPC platform onboard a vehicle may comprise a unified diagnostic gateway that can process and route diagnostic messages between diagnostic clients (diagnostic tools) that access a vehicle’s diagnostic systems and the onboard resources (whether legacy ECU hardware devices or HPC ECU nodes) that provide diagnostics-related data. The adaptive HPC diagnostic message routing may be performed at least in part based on the protocol by which the diagnostic client makes its query to the unified diagnostic gateway, and / or the onboard destination resource to which the query is directed (e.g., the class of ECU (legacy or HPC)) providing the response data). Advantageously, the embodiments for adaptive diagnostic message routing described herein provide for intelligent routing of diagnostic information on HPC vehicles to support onboard diagnostic activities using either legacy or SOVD protocol diagnostic tools.

[0018] In some embodiments, when a diagnostic tool connects to the unified diagnostic gateway, the unified diagnostic gateway may determine whether the diagnostic tool is a legacy protocol diagnostic tool or an SOVD protocol tool. This determination may be made based on the message format of query data received from the diagnostic tool. For example, UDS diagnostic query and response messages are based on standard controller area network (CAN) hexadecimal message encoding. In contrast, SOVD protocol diagnostic query and response messages are based on Hypertext Transfer Protocol (HTTP) standards. As described in greater detail herein, a unified diagnostic gateway may detect that a diagnostic client is communicating using hexadecimal messages, and therefore are legacy protocol messages from a legacy diagnostic client. Conversely, a unified diagnostic gateway may detect that a diagnostic client is communicating using HTTP standard messages, and therefore communicating using SOVD protocol messages from an SOVD compatible diagnostic client.

[0019] In the case of diagnostic messages comprising legacy protocol messages from a legacy diagnostic client, the unified diagnostic gateway may enter a legacy client mode where diagnostic messages are routed to the legacy ECU devices (e.g., through a CAN, Ethernet, Flexray, Local Interconnect Network (LIN), or another network protocol) and responses from the legacy ECU devices are routed back to the legacy diagnostic client.

[0020] Because SOVD implements a substantially more advanced diagnostic protocol as compared to legacy diagnostic protocols, an SOVD protocol diagnostic client is able to query for diagnostic information from both legacy ECU hardware devices and HPC ECU nodes that may be deployed on the vehicle. As such, in the case of diagnostic messages comprising SOVDprotocol messages from an SOVD compatible diagnostic client, the unified diagnostic gateway may enter an SOVD client mode. The unified diagnostic gateway may evaluate each query message to determine if the message is directed to an HPC ECU node or a legacy ECU hardware device. For example, in some embodiments, the unified diagnostic gateway may determine from the query message if the message is directed to an HPC ECU node or a legacy ECU hardware device based on a network destination address, and / or similar destination information, embedded in the query message. When the query message is directed to an HPC ECU node, the unified diagnostic gateway may route the query message to an SOVD server (which may be referred to as a diagnostic server) hosting the HPC ECU node, and route resulting response data back to the SOVD protocol diagnostic client. When the query message is directed to a legacy ECU device, the unified diagnostic gateway may map (translate) the diagnostic information request from the query message into a request comprising the legacy hexadecimal message encoding corresponding to the diagnostic information request, and route the legacy hexadecimal query message to the designated destination legacy ECU device. When the legacy ECU device responds using legacy hexadecimal message encoding, the unified diagnostic gateway may map (translate) the diagnostic information response to an SOVD protocol HTTP response message, and route the response message to the SOVD protocol diagnostic client.

[0021] It should be understood that in various embodiments, a diagnostic client may interface with a unified diagnostic gateway via either wired or wireless diagnostic ports. Moreover, in some embodiments, a diagnostic client may include a remote diagnostic client and / or a cloud-based telematics platform, that may access the unified diagnostic gateway via a wireless communications network (e.g., a cellular and / or 5G telecommunications network).

[0022] Referring now to FIG. 1, FIG. 1 is a data flow diagram for a process for an example vehicle onboard diagnostics system 100 that provides adaptive diagnostic message routing in accordance with embodiments of this disclosure. Although one or more of the embodiments described herein present the onboard diagnostics system 100 in the context of an automotive vehicle, such as an electric vehicle and / or battery powered vehicle, it should be understood that these embodiments may provide for adaptive diagnostic message routing for various types of vehicles and / or systems having integrated diagnostic capabilities such as automobiles, trucks, trains, aircraft, watercraft, spacecraft, and / or machinery such as robots and / or industrial machines. In some embodiments, one or more features and / or elements of the onboard diagnostics system 100 described can be implemented, at least in part, using at leastone computing platform, such as computing device 800 described in connection to FIG. 8 or at least in part within a cloud computing environment 900 as further described with respect to FIG. 9, for example.

[0023] As illustrated in FIG. 1, the onboard diagnostics system 100 for a vehicle may include at least one high-performance compute platform (HPC) 120. The HPC platform 120 may comprise one or more processors comprising processing circuitry executing code to perform one or more of the functions of components of the HPC platform 120 described herein. In some embodiments, a vehicle may comprise multiple such HPC platforms 120. As shown in FIG. 1, the HPC platform 120 may include a unified diagnostic gateway 122 that exchanges diagnostic data 115 with one or more diagnostic client(s) 110 (e.g., diagnostics tools). In some embodiments, diagnostic client(s) 110 may comprise a computing device executing diagnostic software for accessing one or more services of the onboard diagnostics system 100 as described herein (e.g., a computing device 800). In some embodiments, a diagnostic client 110 may comprise a hand-held, tablet, laptop, workstation, and / or other computing hardware. The diagnostic client 110 may exchange diagnostic data 115 via a wired port connection (e.g., an On-Board Diagnostic (OBD2) protocol or SAE JI 962-based diagnostic connector) and / or a wireless data link connection (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.15, Bluetooth, ultra-wideband UWB, or IEEE 802.11 Wi-Fi data links) between the diagnostic client 110 and the HPC platform 120.

[0024] The unified diagnostic gateway 122 may be coupled to one or more HPC platforms 120, where each HPC comprises one or more ECU nodes 126 and an SOVD server 128. In some embodiments, one or more HPC hosted legacy ECUs 130 may also operate through the SOVD server 128. The unified diagnostic gateway 122 may be coupled to one or more legacy ECU devices 140 via a legacy vehicle gateway 150. In some embodiments, a first ECU domain 121 (e.g., an HPC ECU domain) comprises those ECUs that are accessed through an SOVD server 128, while a second ECU domain 141 (e.g., a legacy ECU domain) comprises those ECUs that are accessed through a legacy vehicle gateway 150.

[0025] ECUs such as HPC ECU nodes 126 and legacy ECU devices 140 may perform a variety of onboard functions, and individual ECUs are typically dedicated to a specific onboard system or set of functions. Example vehicle ECUs that may be implemented by HPC ECU nodes 126 and / or legacy ECU devices 140 include, but are not limited to, an Engine Control Module (ECM), Brake Control Module (BCM), Transmission Control Module (TCM), Suspension Control Module (SCM), and / or other ECUs to regulate and / or monitor subsystemsthat optimize fuel economy, operate safety features (e.g., stability control, lane departure features, airbag deployment, crash detection, warning lights, etc.), operate adaptive cruise control, operate body lighting, and / or process data from vehicle sensors (e.g., cameras, radar, etc.). Legacy ECU devices 140 are typically stand-alone specialized electronic devices embedded at various locations within a vehicle. The legacy ECU devices 140 may connect to a legacy network (LN) 142 (e.g., a CAN, Ethernet, Flexray, Local Interconnect Network (LIN), or another network protocol) through which they can communicate with each other. Access to the LN 142 and legacy ECU devices 140 may be obtained through the vehicle gateway, shown in FIG. 1 as legacy vehicle gateway 150. As such, with respect to communicating legacy protocol diagnostic information between unified diagnostic gateway 122 and the legacy ECU devices 140, the legacy hexadecimal query and response message are routed between the unified diagnostic gateway 122 and the legacy ECU devices 140 by legacy vehicle gateway 150.

[0026] In some embodiments, legacy diagnostic clients (shown at 112) may bypass the unified diagnostic gateway 122 and couple directly to the legacy vehicle gateway 150 (e.g., via an OBD2 port) to access legacy ECU devices 140t0send legacy hexadecimal query messages to the legacy ECU devices 140 and receive legacy hexadecimal response messages from the legacy ECU devices 140.

[0027] HPC ECU nodes 126 represent virtual ECUs that are implemented as software executed by the computing resources of the HPC platform 120. HPC ECU nodes 126 may be programmed to perform the specialized functions associated with one or more of the particular types of ECUs discussed above, and / or other functions. In some embodiments, an HPC ECU node 126 is coupled to the SOVD server 128, which is coupled to the unified diagnostic gateway 122. The SOVD server 128 represents a diagnostic endpoint on the HPC platform 120 for evaluating diagnostic data from the SOVD native HPC ECU nodes 126. That is, the SOVD server 128 can define an individually accessible data server that may obtain requested diagnostic information from HPC ECU nodes 126 (and / or HPC hosted legacy ECUs 130) and serve that diagnostic information back to the diagnostic client 110 as an SOVD diagnostic message.

[0028] As an example, the unified diagnostic gateway 122 may receive an SOVD native diagnostic request message from a diagnostic client 110 to obtain diagnostic data 115 from an HPC ECU node 126 in the HPC ECU domain 121. The SOVD native diagnostic request message may comprise an HTTP protocol message that is routed by the unifieddiagnostic gateway 122 to an SOVD server 128 of an HPC platform 120. In some embodiments comprising multiple HPC platforms 120, the unified diagnostic gateway 122 may determine which HPC platform 120 hosts the HPC ECU node 126 that can provide the requested information, and route the diagnostic request message to the SOVD server 128 for that HPC platform 120. For example, in some embodiments, each HPC platform 120 may be individually addressable for the purpose of routing diagnostic messages.

[0029] In some embodiments, an SOVD server 128 may be self-describing, meaning that it may be queried to provide a service report on the type of diagnostic information it can provide and / or the HPC ECU node 126 hosted by that HPC platform 120. A diagnostic client 110 and / or the unified diagnostic gateway 122 may thus direct diagnostic request queries to a particular HPC platform 120. In some embodiments, an SOVD native diagnostic request message may comprise a call to an application programming interface (API) hosted by an SOVD server 128, such as a representational state transfer (REST)- API, to request diagnostic data 115 from an HPC ECU node 126. The SOVD server 128 may read the requested information (e.g., from a memory register or sensor input, or from the output of a diagnostic algorithm) and send a reply with the information (e.g., an HTTP protocol response message) to the unified diagnostic gateway 122 for routing back to the diagnostic client 110. In some instances, an SOVD native diagnostic request message may comprise an SOVD native query requesting diagnostic data about the HPC platform 120 itself, or a component of the HPC platform 120 (e.g., an SOVD server 128, the unified diagnostic gateway 122, etc.). For such queries, the SOVD server 128 may similarly read the requested information (e.g., from a memory register or sensor input, or from the output of a diagnostic algorithm), and send a reply with the information (e.g., an HTTP protocol response message) to the unified diagnostic gateway 122 for routing to the diagnostic client 110.

[0030] A diagnostic client 110 coupled to the onboard diagnostics system 100 may send an SOVD native query that requests diagnostic data 115 from one or more legacy ECU device(s) 140. As previously discussed, SOVD native diagnostic messages are HTTP protocol messages, whereas diagnostic data communication with a legacy ECU device(s) is based on hexadecimal message encoding of diagnostic information requests and responses. Accordingly, in some embodiments, the unified diagnostic gateway 122 may route diagnostic information requests and responses through protocol mapping 124. Protocol mapping 124 may comprise a function executed by an HPC platform 120. The protocol mapping 124 may map an incoming SOVD native diagnostic query message into a legacy query message comprisinga hexadecimal code corresponding to the diagnostic information being requested by the SOVD native diagnostic message. For example, the protocol mapping 124 function may comprise a look-up table and / or diagnostic description file that cross-reference SOVD-based queries to the corresponding hexadecimal code readable by the legacy ECU device(s) 140. The unified diagnostic gateway 122 may then route the mapped query message to the legacy ECU device(s) 140 (e.g., via legacy vehicle gateway 150). When the hexadecimal code query response from the legacy ECU device 140 is received by the unified diagnostic gateway 122, the response message is processed by the protocol mapping 124 function and mapped to an SOVD native HTTP message. The SOVD native HTTP message may then be routed by the unified diagnostic gateway 122 back to the diagnostic client 110.

[0031] In some embodiments, an HPC platform 120 may comprise one or more HPC hosted legacy ECUs, such as shown at 130. In such instances, the HPC hosted legacy ECU(s) 130 are legacy ECU hardware devices (such as legacy ECU device(s) 140) that are coupled to and HPC, and exchange input / output (VO) with an HPC, rather than connect via the legacy vehicle gateway 150. In such embodiments the unified diagnostic gateway 122 may route the mapped query message to the HPC hosted legacy ECU(s) 130 (e.g., via an SOVD server 128) rather than via legacy vehicle gateway 150. When the hexadecimal code query response from the HPC hosted legacy ECU(s) 130 is received by the unified diagnostic gateway 122 (e.g., via an SOVD server 128) the response message is processed by the protocol mapping 124 function and mapped to an SOVD native HTTP message. The SOVD native HTTP message may then be routed by the unified diagnostic gateway 122 back to the diagnostic client 110.

[0032] FIG. 2 illustrates an example process flow 200 for adaptive diagnostic message routing according to some embodiments, which may be used in conjunction with the example unified diagnostic gateway 122 of onboard diagnostics system 100 of FIG. 1. As shown in FIG. 2 at block 210, a diagnostic query (e.g., a request message) may be received at unified diagnostic gateway 122. The unified diagnostic gateway 122 determines (at block 212) whether the diagnostic query comprises a legacy protocol request or an SOVD protocol request. When the diagnostic query does comprise a legacy protocol request, the process 200 proceeds to 214 where the diagnostic query is routed to the legacy vehicle gateway. The request may then be processed at block 216 by a legacy ECU device. As shown at block 218, the resulting response produced by the legacy ECU device may then be returned to the diagnostic client that initiated the diagnostic query.

[0033] When the diagnostic query instead comprises an SOVD protocol request, theprocess proceeds from block 212 to block 220 where the unified diagnostic gateway 122 determines whether the diagnostic query is directed to a legacy ECU device or an SOVD protocol device (e.g., an HPC ECU node 126). When the diagnostic query does comprise an SOVD protocol request directed to an SOVD protocol device, the process proceeds from 220 to 230, and the diagnostic query is routed to the corresponding SOVD server (e.g., an SOVD server hosting an HPC ECU node 126 that can respond to the query). At block 232, the resulting response message may then be returned to the diagnostic client that initiated the diagnostic query.

[0034] In some embodiments, when the diagnostic query does comprise an SOVD protocol request directed to a legacy ECU protocol device, the diagnostic request may be routed from 220 to protocol mapping at block 222 (e.g., the protocol mapping 124 function) where the query is translated from an SOVD protocol (e.g., HTTP) request to a hexadecimal code query. The unified diagnostic gateway 122 may determine (at block 224) whether the destination legacy ECU is a legacy ECU device coupled to the legacy vehicle gateway (e.g., the legacy ECU domain 141), or hosted by an HPC platform (e.g., the HPC ECU domain 121). When the destination legacy ECU is legacy ECU domain 141, the process proceeds to 214 to route the hexadecimal code query to the legacy vehicle gateway. The hexadecimal code query is processed at block 216 by a legacy ECU device and at block 218, and the resulting response message may then be returned via the protocol mapping 124 function where the response is translated from a hexadecimal code response to an SOVD protocol (e.g., HTTP) response. When the destination legacy ECU is in the HPC ECU domain 121, the process may proceed to 226 to route the hexadecimal code query to an HPC hosted legacy ECU (e.g., via an SOVD server 128). The hexadecimal code query is processed at block 228 by an HPC hosted legacy ECU device. At block 230, the resulting response message may then be returned to the diagnostic client via the protocol mapping 124 function where the response is translated from a hexadecimal code response to an SOVD protocol (e.g., HTTP) response.

[0035] FIG. 3 is a data flow diagram illustrating a universal common protocol interface onboard diagnostics system 300 for a unified diagnostic gateway 122 in accordance with embodiments of the present disclosure. In this embodiment, the diagnostic client 110 may comprise either an SOVD protocol device or a legacy protocol device, and may couple to the onboard diagnostics system 300 using a universal protocol interface 301. The unified diagnostic gateway 122 may comprise a diagnostic message router 310. When a diagnostic client 110 connects to the unified diagnostic gateway 122 via the universal protocol interface301, the diagnostic message router 310 may determine whether the diagnostic client 110 comprises a legacy protocol diagnostic tool or an SOVD protocol tool. This determination may be made based on the message format of the query data 302 received from the diagnostic client 110, or from other information such as is exchanged in a handshaking protocol.

[0036] When the query data 302 comprises a legacy protocol query message (e.g., a legacy hexadecimal encoded message), the diagnostic message router 310 may route the query message as a legacy query pass-through 318 to the legacy vehicle gateway 150. The legacy vehicle gateway 150 may pass the legacy protocol query message via the LN 142 to the one or more legacy ECU devices 140. The one or more legacy ECU devices 140 will generate diagnostic information (e.g., one or more legacy hexadecimal encoded messages) in response to the legacy protocol query message, which may be delivered via the LN 142 to the legacy vehicle gateway 150, and back to the diagnostic message router 310 as a legacy response 320. Since the diagnostic message router 310 is responding to a legacy protocol query message, the diagnostic message router 310 may pass the legacy response 320 as a legacy response pass- through 324 to generate the response data 304 that is transmitted via the universal protocol interface 301 to diagnostic client 110.

[0037] When the diagnostic message router 310 determines that the query data 302 comprises an SOVD protocol query message (e.g., HTTP protocol messages), the diagnostic message router 310 may determine whether the query is directed to an HPC ECU node 126 or a legacy ECU device 140.

[0038] If the diagnostic message router 310 determines that an SOVD protocol query message is directed to an HPC ECU node 126, the diagnostic message router 310 may route the query message as an SOVD native query 312 to an SOVD server 128 hosting the HPC ECU node 126. The HPC ECU node 126 generates the requested diagnostic information in response to the SOVD protocol query messages, and the response is delivered back to the diagnostic message router 310 as an SOVD native response 314. Since the diagnostic message router 310 is responding to SOVD protocol query messages, the diagnostic message router 310 may pass the SOVD native response 314 as an SOVD native response pass-through 326 to generate response data 304 that is transmitted via the universal protocol interface 301 to diagnostic client 110.

[0039] If the diagnostic message router 310 determines that an SOVD protocol query message is directed to a legacy ECU device 140, the diagnostic message router 310 may apply protocol mapping 124 to the query message to translate the SOVD protocol query to a legacyhexadecimal encoded message. The legacy hexadecimal encoded message may then be routed as mapped query 316 to the legacy vehicle gateway 150. The legacy vehicle gateway 150 may pass the legacy protocol query message via the LN 142 to the one or more legacy ECU devices 140. The one or more legacy ECU devices 140 will generate diagnostic information (e.g., one or more legacy hexadecimal encoded messages) in response to legacy protocol query message. The resulting response message may be delivered via the LN 142 to the legacy vehicle gateway 150, and back to the diagnostic message router 310 as legacy response 320. Since the diagnostic message router 310 is responding to SOVD protocol query messages, the diagnostic message router 310 may apply protocol mapping 124 to the response message to translate the legacy hexadecimal encoded response to an SOVD protocol response message. The diagnostic message router 310 may output the resulting SOVD protocol response message as a legacy mapped response 322 to generate response data 304 that is transmitted via the universal protocol interface 301 to diagnostic client 110. As previously discussed with respect to FIGs. 1 and 2, in some embodiments the SOVD protocol query message may be directed to an HPC hosted legacy ECU 130, in which case the diagnostic message router 310 and / or SOVD server 128 may apply protocol mapping 124 to the query and response messages.

[0040] FIG. 4 is a data flow diagram illustrating an split port example of the unified diagnostic gateway 122 of onboard diagnostics system 100 of FIG. 1. In this embodiment, the onboard diagnostics system 100 may comprise separate ports for SOVD protocol diagnostic clients and legacy protocol device diagnostic clients. More specifically, the onboard diagnostics system 100 comprises an SOVD protocol interface 401 for using SOVD protocol diagnostic clients, and a legacy protocol interface 402 for using legacy protocol device diagnostic clients.

[0041] As shown in FIG. 4, a legacy diagnostic client 411 connecting to the onboard diagnostics system 100 using the legacy protocol interface 402 may bypass the unified diagnostic gateway 122 and connect directly to the legacy vehicle gateway 150 to access legacy ECU devices 140. The legacy diagnostic client 411 may send legacy hexadecimal query messages to the legacy vehicle gateway 150 and the messages routed to the legacy ECU devices 140, and in response receive legacy hexadecimal response messages from the legacy ECU devices 140 via the legacy vehicle gateway 150.

[0042] As shown in FIG. 4, an SOVD diagnostic client 403 may connect to the onboard diagnostics system 100 using the SOVD protocol interface 401, which may couple the SOVD diagnostic client 403 to the unified diagnostic gateway 122. The unified diagnostic gateway122 may comprise a diagnostic message router 410. When a diagnostic client 403 connects to the unified diagnostic gateway 122 via the SOVD protocol interface 401, the diagnostic message router 410 may determine whether a query 405 is directed to an HPC ECU domain 121 ECU or a legacy domain 141 ECU.

[0043] If the diagnostic message router 410 determines that query data 405 is a message directed to an HPC ECU node 126, the diagnostic message router 410 may route the query message as an SOVD native query 412 to an SOVD server 128 hosting the HPC ECU node 126. The HPC ECU node 126 generates the requested diagnostic information in response to the SOVD protocol query messages, and the response is delivered back to the diagnostic message router 410 as an SOVD native response 414. Since the diagnostic message router 410 is responding to SOVD protocol query messages, the diagnostic message router 410 may pass the SOVD native response 414 as an SOVD native response pass-through 424 to generate response data 406 that is transmitted via the SOVD protocol interface 401 to SOVD diagnostic client 403.

[0044] If the diagnostic message router 410 determines that query data 405 is directed to a legacy ECU device 140, the diagnostic message router 410 may apply protocol mapping 124 to the query message to translate the SOVD protocol query to legacy hexadecimal encoded messages. The legacy hexadecimal encoded message may then be routed as mapped query 416 to the legacy vehicle gateway 150. The legacy vehicle gateway 150 may pass the legacy protocol query message via the LN 142 to the one or more legacy ECU devices 140. The one or more legacy ECU devices 140 will generate diagnostic information (e.g., one or more legacy hexadecimal encoded messages) in response to legacy protocol query messages. The resulting response message may be delivered via the LN 142 to the legacy vehicle gateway 150, and back to the diagnostic message router 410 as legacy response 420. The diagnostic message router 410 may apply protocol mapping 124 to the response message to translate the legacy hexadecimal encoded response to an SOVD protocol response message. The diagnostic message router 410 may output the resulting SOVD protocol response message as a legacy mapped response 422 to generate response data 406 that is transmitted via the SOVD protocol interface 401 to SOVD diagnostic client 403. As previously discussed with respect to FIGs. 1 and 2, in some embodiments query data 405 may comprise an SOVD protocol query message directed to an HPC hosted legacy ECU 130, in which case the diagnostic message router 410 and / or SOVD server 128 may apply protocol mapping 124 to the query and response messages.

[0045] FIG. 5 is a block diagram illustrating another example data flow diagram for analternative configuration of the unified diagnostic gateway 122 of FIG. 1 described herein, wherein the legacy vehicle gateway 150 may be omitted as the unified diagnostic gateway 122 may communicate directly with one or more legacy ECUs 540 coupled to the HPC platform 120. In this embodiment, the diagnostic client 503 may comprise either an SOVD protocol device or a legacy protocol device, and may couple to the onboard diagnostics system 100 using a universal protocol interface 501. The unified diagnostic gateway 122 may comprise a diagnostic message router 510. When a diagnostic client 503 connects to the unified diagnostic gateway 122 via the universal protocol interface 501, the diagnostic message router 510 may determine whether the diagnostic client 503 comprises a legacy protocol diagnostic tool or an SOVD protocol tool. This determination may be made based on the message format of the query data 505 received from the diagnostic client 503, or from other information such as is exchanged in a handshaking protocol. Moreover, when a diagnostic client 503 connects to the unified diagnostic gateway 122, the diagnostic message router 510 may determine whether a query 505 is directed to an HPC ECU domain 121 ECU or a legacy domain 141 ECU.

[0046] When the diagnostic message router 510 determines that query data 505 is a message directed to an HPC ECU node 126, the diagnostic message router 510 may route the query message as an SOVD native query 512 to an SOVD server 128 hosting the HPC ECU node 126. The HPC ECU node 126 generates the requested diagnostic information in response to the SOVD protocol query messages, and the response is delivered back to the diagnostic message router 510 as an SOVD native response 514. Since the diagnostic message router 510 is responding to SOVD protocol query messages, the diagnostic message router 510 may pass the SOVD native response 514 as an SOVD pass-through response 524 to generate response data 506 that is transmitted via the interface 501 to diagnostic client 503.

[0047] When the diagnostic message router 510 determines that query data 505 comprises legacy format messages (e.g., q hexadecimal encoded message) directed to a legacy ECU device 540, the diagnostic message router 510 may directly route the query as legacy query 552 to the one or more legacy ECUs 540 (e.g., bypassing protocol mapping 124). The one or more legacy ECU devices 540 will generate diagnostic information (e.g., one or more legacy hexadecimal encoded messages) in response to legacy query 552 message(s). The resulting legacy response 554 may be delivered back to the diagnostic message router 510 as legacy response 554 (e.g. again bypassing protocol mapping 124). The diagnostic message router 510 may output the resulting message as a legacy response 522 to generate response data 506 that is transmitted via the interface 501 to diagnostic client 503. In contrast, when thediagnostic message router 510 determines that query data 505 comprises SOVD messages directed to a legacy ECU device 540, the diagnostic message router 510 may apply protocol mapping 124 to the query message to translate the SOVD protocol query to legacy hexadecimal encoded messages used by the legacy ECU device 540. The legacy hexadecimal encoded message may then be routed as legacy query 552 to the to the one or more legacy ECUs 540. The one or more legacy ECU devices 540 will generate diagnostic information (e.g., one or more legacy hexadecimal encoded messages) in response to legacy query 552 message(s). The resulting legacy response 554 may be delivered back to the diagnostic message router 510 as legacy response 554 (e.g. again bypassing protocol mapping 124). The diagnostic message router 510 may apply protocol mapping 124 to the legacy response message 554 to translate the legacy hexadecimal encoded response to an SOVD protocol response message 524 and output the resulting SOVD protocol response message to generate response data 506 that is transmitted via the interface 501 to diagnostic client 503. It should be understood that additional embodiments may include HPC platform(s) 120 and / or unified diagnostic gateways 122 comprising combinations of the configurations illustrated in FIGs. 3, 4 and / or 5.

[0048] FIG. 6 is a diagram illustrating various interface examples for connecting a diagnostic client of diagnostic client 110 to a unified diagnostic gateway 122 of onboard diagnostics system 100 according to some embodiments of the present disclosure. As shown in FIG. 6, in some embodiments, a diagnostic client 110 may comprise a local diagnostic client 610 (e.g., a local hand-held tool, a tablet computer and / or smart device, a laptop computer, a workstation, etc.). In some embodiments, the local diagnostic client 610 may connect to a diagnostic interface 601 via a wired diagnostic port 612 (e.g., a plug or jack connector) or a wireless diagnostic port 614 (e.g., IEEE 802.15, Bluetooth, ultra-wideband UWB, IEEE 802.11 Wi-Fi data links, etc.). In some embodiments, the diagnostic client 110 may comprise a networked remote diagnostic client 616 that may remotely couple to the unified diagnostic gateway 122 via a network 605 (e.g., the Internet, and / or a cellular telecommunications network). That is, the networked diagnostic client 616 may comprise a server or other network computer platform (e.g., as shown in the computing device 800 of FIG. 8 or cloud computing platform 900 of FIG. 9) that comprises diagnostic software for accessing one or more services of the onboard diagnostics system 100 as described herein, and in the same manner as a diagnostic client 110 as described herein.

[0049] In some embodiments, the diagnostic client 110 may comprise a telematics platform 618 that may wirelessly couple to the unified diagnostic gateway 122 via a network605 (e.g., the Internet, and / or a cellular telecommunications network) while the vehicle is in service (e.g., transporting people and / or cargo). In some embodiments, the telematics platform 618 comprises a server or other network computer platform (e.g., as shown in the computing device 800 of FIG. 8 or cloud computing platform 900 of FIG. 9) that comprises one or more technologies to monitor and record vehicle data, such as speed, location tracking, and / or to dynamically monitor faults or errors generated by an ECU or other components of the onboard diagnostics system 100.

[0050] Referring now to FIG. 7, a flowchart illustrates a method 700 for adaptive diagnostic message routing, in accordance with embodiments of the present disclosure. It should be understood that the features and elements described herein with respect to the method 700 of FIG. 7 can be used in conjunction with, in combination with, or substituted for elements of any of the other embodiments discussed herein and vice versa. Further, it should be understood that the functions, structures, and other descriptions of elements for embodiments described in FIG. 7 can apply to like or similarly named or described elements across any of the figures and / or embodiments described herein and vice versa. In some embodiments, elements of method 700 are implemented utilizing elements of the onboard diagnostics system 100, HPC platform 120, and / or unified diagnostic gateway 122 disclosed herein, or another processing device implementing the present disclosure. The method 700 is not limited to this selection of elements shown in FIG. 7.

[0051] The method 700, at block B702, includes determining a diagnostic message classification associated with query data received at a vehicle diagnostic gateway. The vehicle diagnostic gateway may couple to a diagnostic client using at least one diagnostic port interface, wherein the query data and the response data are communicated via the diagnostic port interface. For example, as shown in FIG. 1, an HPC platform 120 of an onboard diagnostics system 100 may include a vehicle diagnostic gateway that comprises a unified diagnostic gateway 122. The vehicle diagnostic gateway may exchange diagnostic data 115 with one or more diagnostic client(s) 110 (e.g., diagnostic tools). The vehicle diagnostic gateway may be coupled to one or more HPC platforms 120, where each HPC comprises one or more ECU nodes 126 and an SOVD server 128. In some embodiments, one or more HPC hosted legacy ECUs 130 may also operate through the SOVD server 128. The vehicle diagnostic gateway may be coupled to one or more legacy ECU devices 140 via a legacy vehicle gateway 150. In some embodiments, a first ECU domain 121 (e.g., an HPC ECU domain) comprises those ECUs that are accessed through an SOVD server 128, while a secondECU domain 141 (e.g., a legacy ECU domain) comprises those ECUs that are accessed through a legacy vehicle gateway 150. The diagnostic port interface may comprise at least one of: a wired data link interface, a wireless data link interface, and / or a wireless network interface, such as illustrated and described with respect to FIG. 6. In some embodiments, the diagnostic message classification may include a classification that indicates that the query data is directed to the first set of one or more ECUs, or that the query data comprises a message format associated with the first protocol of the first set of one or more ECUs. In some embodiments, the diagnostic message classification may include a classification that indicates that the query data is directed to one or more virtualized ECUs instantiated by the on-vehicle computing platform, or that the query data comprises a message format associated with the second protocol of the second set of one or more ECUs. In some embodiments, the diagnostic message classification may include a classification that indicates that the query data is directed to one or more individual ECU devices coupled to the SOVD server, or that the query data comprises a message format associated with the second protocol of the second set of one or more ECUs.

[0052] The method 700, at block B704, includes routing a first query message via a vehicle gateway to request diagnostic data from a first set of one or more electronic control units (ECUs) coupled to the vehicle gateway when the diagnostic message classification indicates a first classification, the first query message comprising a message format based on a first protocol of the first set of one or more ECUs. The first protocol may comprise a hexadecimal encoded message format. In some embodiments, the first set of one or more ECUs comprises individual ECU devices (e.g., legacy ECU devices) coupled to the vehicle gateway via a vehicle controller area network (CAN) bus. As an example, referring to FIG. 1, legacy ECU devices 140 are typically stand-alone specialized electronic devices embedded at various locations within a vehicle. The legacy ECU devices 140 may connect to a Controller Area Network (CAN) 142 through which they can communicate with each other. Access to the LN 142 and legacy ECU devices 140 may be obtained through the vehicle gateway, shown in FIG. 1 as legacy vehicle gateway 150. As such, with respect to communicating legacy protocol diagnostic information between unified diagnostic gateway 122 and the legacy ECU devices 140, the legacy hexadecimal query and response message are routed between the unified diagnostic gateway 122 and the legacy ECU devices 140 by legacy vehicle gateway 150.

[0053] The method 700, at block B706, includes routing a second query message via a Service-Oriented Vehicle Diagnostics (SOVD) server of an on-vehicle computing platform to request the diagnostic data from a second set of one or more ECUs when the diagnostic messageclassification indicates a second classification, the second query message comprising a message format based on a second protocol of the second set of one or more ECUs. In some embodiments, the second protocol comprises a hypertext format. The second set of one or more ECUs may comprise one or more virtualized ECUs instantiated by the on-vehicle computing platform. As explained with respect to FIG. 1, HPC ECU nodes 126 represent virtual ECUs that are implemented as software executed by the computing resources of the HPC platform 120. HPC ECU nodes 126 may be programmed to perform the specialized functions associated with one or more of the particular types of ECUs discussed above, and / or other functions. In some embodiments, an HPC ECU node 126 is coupled to the SOVD server 128, which is coupled to the unified diagnostic gateway 122. In some embodiments, the second set of one or more ECUs may comprise one or more individual ECU devices coupled to the SOVD server, such as one or more HPC hosted legacy ECUs 130 that operate through an SOVD server 128. The HPC hosted legacy ECU(s) 130 may comprise legacy ECU hardware devices (such as legacy ECU device(s) 140) that are coupled to exchange VO with an HPC, rather than connect via the legacy vehicle gateway 150.

[0054] In some embodiments, the unified diagnostic gateway 122 may route diagnostic information requests and responses through protocol mapping 124. In some embodiments, the method may include mapping the query data from a first diagnostic message protocol to the first protocol of the first set of one or more ECUs, and mapping the diagnostic data from the first protocol of the first set of one or more ECUs to the first diagnostic message protocol to generate the response data from the vehicle diagnostic gateway. In some embodiments, the method may include mapping the query data from a first diagnostic message protocol to the second protocol of the second set of one or more ECUs, and mapping the diagnostic data from the second protocol of the second set of one or more ECUs to the first diagnostic message protocol to generate the response data from the vehicle diagnostic gateway. As explained with respect to FIG. 1, protocol mapping 124 may comprise a function executed by an HPC platform 120. The protocol mapping 124 may map an incoming SOVD native diagnostic query message into a legacy query message comprising a hexadecimal code corresponding to the diagnostic information being requested by the SOVD native diagnostic message. When the hexadecimal code query response from the legacy ECU device 140 is received by the unified diagnostic gateway 122, the response message is processed by the protocol mapping 124 function and mapped to an SOVD native HTTP message. The SOVD native HTTP message may then be routed by the unified diagnostic gateway 122 back to the diagnostic client 110.

[0055] The method 700, at block B708, includes outputting response data from the vehicle diagnostic gateway based on the diagnostic data generated in response to the query data. The diagnostic data may be used to facilitate efficient troubleshooting and maintenance of the vehicle, ensuring vehicle safety and compliance with regulatory standards. Diagnostic data provided by the output may include diagnostic data (e.g., fault codes and / or other diagnostic information) generated by ECUs (e.g., HPC ECU nodes and / or legacy ECU devices) such as, but not limited to, an Engine Control Module (ECM), Brake Control Module (BCM), Transmission Control Module (TCM), Suspension Control Module (SCM), and / or other ECUs to regulate and / or monitor subsystems that optimize fuel economy, operate safety features (e.g., stability control, lane departure features, airbag deployment, crash detection, warning lights, etc.), operate adaptive cruise control, operate body lighting, and / or process data from vehicle sensors (e.g., cameras, radar, etc.). Advantageously, the embodiments for adaptive diagnostic message routing described herein provide for intelligent routing of diagnostic information on HPC vehicles to support onboard diagnostic activities using either legacy or SOVD protocol diagnostic tools. With regard to FIG. 8, one exemplary operating environment for implementing aspects of the technology described herein is shown and designated generally as computing device 800. For example, in some embodiments, one or more aspects of the onboard diagnostics system, 100, HPC platform 120, unified diagnostic gateway 122, SOVD server 128, and / or HPC ECU nodes may be implemented onboard a vehicle using one or more computing devices such as computing device 800. Computing device 800 is just one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the technology described herein, and nor should the computing device 800 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

[0056] The technology described herein can be described in the general context of computer code or machine-usable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components, including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks or implements particular abstract data types. Aspects of the technology described herein can be practiced in a variety of system configurations, including vehicles, industrial machinery, robots, consumer electronics, general-purpose computers, and specialty computing devices. Aspects of the technology described herein can also be practicedin distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network. For example, the computing device 800 may comprise a computing device integrated within a vehicle, industrial machinery, a robot, and / or other mobile or stationary systems.

[0057] With continued reference to FIG. 8, computing device 800 includes a bus 810 that directly or indirectly couples the following devices: memory 812, one or more processors 814, one or more presentation components 816, input / output (I / O) ports 818, I / O components 820, an illustrative power supply 822, and a radio(s) 824. An HPC platform 120 may comprise one or more elements of computing device 800.

[0058] Bus 810 represents one or more buses (such as an address bus, data bus, or combination thereof). Although the various blocks of FIG. 8 are shown with lines for the sake of clarity, it should be understood that one or more of the functions of the components can be distributed between components. For example, a presentation component 816 such as a display device can also be considered an VO component 820. The diagram of FIG. 8 is merely illustrative of an exemplary computing device that can be used in connection with one or more aspects of the technology described herein. Distinction is not made between such categories as "workstation," "server," "laptop," "tablet," "smart phone," or "handheld device," as all are contemplated within the scope of FIG. 8 and refer to "computer" or "computing device."

[0059] In some embodiments, a unified diagnostic gateway 122, as described in any of the examples of this disclosure may be implemented at least in part using code executed by the one or more processors(s) 814. In some embodiments, the one or more processors(s) 814 may include processing circuitry such as, but not limited to, one or more central processing units (CPUs) 830 and / or one or more graphics processing units (GPUs) 832. In some embodiments, one or more of the unified diagnostic gateways 122 may be implemented at least in part using a neural network inference engine executed on the one or more processors(s) 814. For example, the determining of a diagnostic message classification of query data may be performed by a neural network inference engine trained to perform classification tasks, for example to determine a protocol of the query data.

[0060] Computing device 800 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device 800 and includes both volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes bothvolatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.

[0061] Computer storage media includes non-transient random access memory (RAM), read only memory (ROM), electronically-erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc (CD)-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Computer storage media and computer-readable media do not comprise a propagated data signal or signals per se.

[0062] Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0063] Memory 812 includes computer storage media in the form of volatile and / or non-volatile memory. Memory 812 may be removable, non-removable, or a combination thereof. Exemplary memory includes solid-state memory, hard drives, optical-disc drives, etc. Memory 812 may include any type of tangible medium that is capable of storing information, such as a database. A database may include any collection of records, data, and / or other information.

[0064] Computing device 800 includes one or more processors 814 that read data from various entities such as bus 810, memory 812, or I / O components 820. One or more presentation components 816 present data indications to a person or other device. For example, presentation components 816 may include a human-machine interface (HMI) that may display alerts, warnings, or other information generated by one or more ECUs. Exemplary one or more presentation components 816 include a display device, speaker, printing component, vibrating component, etc. VO ports 818 allow computing device 800 to be logically coupled to other devices including I / O components 820, some of which may be built into computing device 800. Illustrative I / O components 820 include a microphone, joystick, game pad, satellite dish,scanner, printer, wireless device, display device, a controller (such as a keyboard and a mouse), a natural user interface (NUI) (such as touch interaction, pen (or stylus) gesture, and gaze detection), and the like. In some embodiments, I / O components 820 may include a network interface card (NIC) to implement a network interface (e.g., to establish a data link via network 605). In some embodiments, a diagnostic port interface for coupling a diagnostic client 110 to the unified diagnostic gateway 122 may be implemented using one or more of I / O components 820.

[0065] Radio(s) 824 represents a radio that facilitates communication with a wireless telecommunications network and / or a wireless channel to network 605. For example, radio(s) 824 may comprise a wireless network interface used to establish communications with the telematics platform 618 and / or remote diagnostic client 616 via network 605. In some embodiments, radio(s) 824 may comprise the wireless diagnostic port 614. Illustrative wireless telecommunications technologies include CDMA, GPRS, TDMA, GSM, and the like. Radio 824 might additionally or alternatively facilitate other types of wireless communications including Wi-Fi, WiMAX, LTE, and / or other voice-over-internet protocol (VoIP) communications. As can be appreciated, in various embodiments, radio(s) 824 can be configured to support multiple technologies, and / or multiple radios can be utilized to support multiple technologies.

[0066] The computing device 800, in some embodiments, is equipped with sensors such as, but not limited to, temperature sensors, pressure sensors, airflow sensors, air mass sensors, process flow sensors, electrical current and / or voltage sensors, image sensors, cameras, depth cameras, such as stereoscopic camera systems, infrared camera systems, red- green-blue (RGB) camera systems, accelerometers or gyroscopes that enable detection of motion, and / or combinations of these, which may be used for generating sensor data for input to the HPC platform 120 discussed herein (e.g., to implement one or more HPC ECU nodes 126, as discussed herein). In some embodiments, an output of the accelerometers or gyroscopes can be provided to a display of the computing device 800 to render immersive augmented reality or virtual reality.

[0067] FIG. 9 is a diagram illustrating a cloud-based computing environment 900 for implementing one or more aspects of the onboard diagnostics system 100 with respect to any of the embodiments discussed herein. For example, a vehicle 905 may comprise an HPC platform 120 that includes a unified diagnostic gateway 122, where one or more functions of the unified diagnostic gateway 122 as described herein may be implemented at least in part byunified diagnostic gateway logic 926 implemented by cloud-based computing environment 900. In some embodiments, unified diagnostic gateway logic 926 may be accessed (via network 605) by the unified diagnostic gateway 122 to perform one or more functions of the unified diagnostic gateway 122 described herein. For example, unified diagnostic gateway logic 926 may provide unified diagnostic gateway 122 with data that may be used to classify diagnostic messages (e.g., what protocols are being used and / or which ECU devices are able to provide diagnostic information in response to a query based on a current configuration of an ECU onboard the vehicle 905). In some embodiments, unified diagnostic gateway logic 926 may provide look-up table(s) and / or diagnostic description files used by an HPC platform 120 to perform protocol mapping 124.

[0068] Cloud-based computing environment 900 may comprise one or more controllers 910 that each comprises one or more processors and memory, each programmed to execute code to implement at least part of the unified diagnostic gateway 122 and / or unified diagnostic gateway logic 926 described herein. In one embodiment, the one or more controllers 910 comprise server components of a data center. The controllers 910 may be configured to establish a cloud-based computing platform executing aspects of the unified diagnostic gateway 122 and / or unified diagnostic gateway logic 926 described herein. For example, in some embodiments, one or more operations of unified diagnostic gateway logic 926 are virtualized network services running on a cluster of worker nodes 920 established on the controllers 910. For example, the cluster of worker nodes 920 can include one or more pods 922 (such as Kubernetes (K8s) pods) orchestrated onto the worker nodes 920 to realize one or more containerized applications 924 to implement one or more functions of the unified diagnostic gateway logic 926 described herein. In some embodiments, the HPC platform(s) 120 and / or unified diagnostic gateway 122 can be coupled to the controllers 910 by network 605 (for example, a public network such as the Internet, a proprietary network, or a combination thereof). In some embodiments the cluster of worker nodes 920 includes one or more data store persistent volumes 930 that may record and store vehicle diagnostic history 932, which may be accessed, for example, by telematics platform 618 and / or remote diagnostic client 616 via network 605.EXAMPLE CLAUSES

[0069] Example 1 includes a system including one or more processors coupled to amemory, the one or more processors configured to: determine a diagnostic message classification associated with query data received at a vehicle diagnostic gateway; when the diagnostic message classification indicates a first classification, route a first query message via a vehicle gateway to request diagnostic data from a first set of one or more electronic control units (ECUs) coupled to the vehicle gateway, the first query message comprising a message format based on a first protocol of the first set of one or more ECUs; when the diagnostic message classification indicates a second classification, route a second query message via a Service-Oriented Vehicle Diagnostics (SOVD) server of an on-vehicle computing platform to request the diagnostic data from a second set of one or more ECUs, the second query message comprising a message format based on a second protocol of the second set of one or more ECUs; and output response data from the vehicle diagnostic gateway based on the diagnostic data generated in response to the query data.

[0070] Example 2 includes the system of example 1, wherein the first set of one or more ECUs comprises individual ECU devices coupled to the vehicle gateway via a vehicle controller area network (CAN) bus.

[0071] Example 3 includes the system of any of examples 1-2, wherein the second set of one or more ECUs comprises one or more virtualized ECUs instantiated by the on-vehicle computing platform.

[0072] Example 4 includes the system of any of examples 1-3, wherein the second set of one or more ECUs comprises one or more individual ECU devices coupled to the SOVD server.

[0073] Example 5 includes the system of any of examples 1-4, the one or more processors further configured to map the query data from a first diagnostic message protocol to the first protocol of the first set of one or more ECUs; and map the diagnostic data from the first protocol of the first set of one or more ECUs to the first diagnostic message protocol to generate the response data from the vehicle diagnostic gateway.

[0074] Example 6 includes the system of any of examples 1-5, the one or more processors further configured to map the query data from a first diagnostic message protocol to the second protocol of the second set of one or more ECUs; and map the diagnostic data from the second protocol of the second set of one or more ECUs to the first diagnostic message protocol to generate the response data from the vehicle diagnostic gateway.

[0075] Example 7 includes the system of any of examples 1-6, wherein the first classification indicates that the query data is directed to the first set of one or more ECUs, orthat the query data comprises the message format associated with the first protocol of the first set of one or more ECUs.

[0076] Example 8 includes the system of any of examples 1-7, wherein the second classification indicates that the query data is directed to one or more virtualized ECUs instantiated by the on-vehicle computing platform, or that the query data comprises the message format associated with the second protocol of the second set of one or more ECUs.

[0077] Example 9 includes the system of any of examples 1-8, wherein the second classification indicates that the query data is directed to one or more individual ECU devices coupled to the SOVD server, or that the query data comprises the message format associated with the second protocol of the second set of one or more ECUs.

[0078] Example 10 includes the system of any of examples 1-9, wherein the first protocol comprises a hexadecimal encoded message format and the second protocol comprises a hypertext format.

[0079] Example 11 includes the system of any of examples 1-10, the one or more processors further configured to couple to a diagnostic client using a diagnostic port interface, wherein the query data and the response data are communicated via the diagnostic port interface.

[0080] Example 12 includes the system of example 11, wherein the diagnostic port interface comprises at least one of: a wired data link interface, a wireless data link interface, and a wireless network interface.

[0081] Example 13 includes a vehicle onboard diagnostics system, the system including: at least one diagnostic port interface configured to couple to a diagnostic client; a vehicle gateway coupled to a first set of one or more electronic control units (ECUs) via a vehicle controller area network (CAN) bus; at least one computing platform comprising: at least one diagnostic server, wherein the at least one computing platform instantiates a second set of one or more virtualized ECUs coupled to the at least one diagnostic server; and a unified diagnostic gateway coupled to the at least one diagnostic server and the vehicle gateway, wherein the unified diagnostic gateway is configured to: determine a diagnostic message classification associated with query data received from the diagnostic client; route a first query message via the vehicle gateway to request diagnostic data from the one or more ECUs coupled to the vehicle gateway when the diagnostic message classification indicates a first classification; route a second query message via the at least one diagnostic server to request the diagnostic data from the second set of one or more virtualized ECUs when the diagnosticmessage classification indicates a second classification; and output response data to the diagnostic client based on the diagnostic data generated in response to the query data.

[0082] Example 14 includes the system of example 13, wherein the first query message comprises a message format based on a first protocol of the first set of one or more ECUs; and the second query message comprises the message format based on a second protocol of the second set of one or more virtualized ECUs.

[0083] Example 15 includes the system of any of examples 13-14, the system further including: one or more individual ECU devices coupled to the at least one diagnostic server; and wherein the second classification indicates that the query data is directed to the one or more individual ECU devices coupled to the at least one diagnostic server, or that the query data comprises a message format associated with the one or more individual ECU devices coupled to the at least one diagnostic server.

[0084] Example 16 includes the system of any of examples 13-15, the system further including a protocol mapping function; wherein the protocol mapping function is configured to map the query data from a first diagnostic message protocol to a first protocol of the one or more ECUs coupled to the vehicle gateway; and wherein the protocol mapping function is configured to map the diagnostic data from the first protocol of the one or more ECUs coupled to the vehicle gateway to the first diagnostic message protocol to generate the response data.

[0085] Example 17 includes a method for routing onboard vehicle diagnostic messages, the method including: determining a diagnostic message classification associated with query data received at a vehicle diagnostic gateway; routing a first query message via a vehicle gateway to request diagnostic data from a first set of one or more electronic control units (ECUs) coupled to the vehicle gateway when the diagnostic message classification indicates a first classification, the first query message comprising a message format based on a first protocol of the first set of one or more ECUs; routing a second query message via a Service- Oriented Vehicle Diagnostics (SOVD) server of an on-vehicle computing platform to request the diagnostic data from a second set of one or more ECUs when the diagnostic message classification indicates a second classification, the second query message comprising a message format based on a second protocol of the second set of one or more ECUs; and outputting response data from the vehicle diagnostic gateway based on the diagnostic data generated in response to the query data.

[0086] Example 18 includes the method of example 17, the method further including: mapping the query data from a first diagnostic message protocol to the first protocol of the firstset of one or more ECUs; and mapping the diagnostic data from the first protocol of the first set of one or more ECUs to the first diagnostic message protocol to generate the response data from the vehicle diagnostic gateway.

[0087] Example 19 includes the method of any of examples 17-18, wherein the second set of one or more ECUs comprises one or more virtualized ECUs instantiated by the on-vehicle computing platform.

[0088] Example 20 includes the method of any of examples 17-19, wherein the second set of one or more ECUs comprises one or more individual ECU devices coupled to the SOVD server.

[0089] In various alternative embodiments, system and / or device elements, method steps, or example implementations described throughout this disclosure can be implemented at least in part using one or more computer systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or similar devices comprising a processor coupled to a memory and executing code to realize that elements, processes, or examples, said code stored on a non-transient hardware data storage device. Therefore, other embodiments of the present disclosure can include elements comprising program instructions resident on computer-readable media that when implemented by such computer systems, enable them to implement the embodiments described herein. As used herein, the terms "computer-readable media" and "computer storage media" refer to tangible memory storage devices having nontransient physical forms and include both volatile and non-volatile, removable and nonremovable media. Such non-transient physical forms can include computer memory devices, such as but not limited to: magnetic disk or tape, or other magnetic storage devices, any optical data storage system, flash read-only memory (ROM), non-volatile ROM, programmable ROM (PROM), erasable-programmable ROM (E-PROM), electrically erasable-programmable ROM (EEPROM), random-access memory (RAM), CD-ROM, digital versatile disks (DVDs), or any other form of permanent, semi-permanent, or temporary memory storage system of a device having a physical, tangible form. By way of example, and not limitation, computer-readable media can comprise computer storage media and communication media. Computer storage media and computer-readable media do not comprise a propagated data signal. Program instructions include, but are not limited to, computer-executable instructions executed by computer system processors and hardware description languages such as Very High-Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL).

[0090] Many different arrangements of the various components depicted, as well ascomponents not shown, are possible without departing from the scope of the claims below. Embodiments in this disclosure are described with the intent to be illustrative rather than restrictive. Alternative embodiments will become apparent to readers of this disclosure after and because of reading it. Alternative means of implementing the aforementioned can be completed without departing from the scope of the claims below. Certain features and subcombinations are of utility and can be employed without reference to other features and subcombinations and are contemplated within the scope of the claims.

Claims

CLAIMSWhat is claimed is:

1. A system comprising one or more processors (814) coupled to a memory (812), the one or more processors (814) configured to: determine a diagnostic message classification associated with query data (302, 405, 505) received at a vehicle diagnostic gateway (122); when the diagnostic message classification indicates a first classification, route a first query message via a vehicle gateway (142) to request diagnostic data from a first set of one or more electronic control units (ECUs) (140) coupled to the vehicle gateway (142), the first query message comprising a message format based on a first protocol of the first set of one or more ECUs (140); when the diagnostic message classification indicates a second classification, route a second query message via a Service-Oriented Vehicle Diagnostics (SOVD) server (128) of an on-vehicle computing platform (120) to request the diagnostic data from a second set of one or more ECUs (126), the second query message comprising a message format based on a second protocol of the second set of one or more ECUs (126); and output response data (304, 406, 506) from the vehicle diagnostic gateway (122) based on the diagnostic data generated in response to the query data (302, 405, 505).

2. The system (100) of claim 1, wherein the first set of one or more ECUs (140) comprises individual ECU devices (140) coupled to the vehicle gateway (142) via at least one of a vehicle controller area network (CAN) bus, an Ethernet bus, a Flexray bus, or a Local Interconnect Network (LIN) bus (142).

3. The system (100) of any of claims 1 to 2, wherein the second set of one or more ECUs (126) comprises one or more virtualized ECUs (126) instantiated by the on-vehicle computing platform (120).

4. The system (100) of any of claims 1 to 3, wherein the second set of one or more ECUs (16) comprises one or more individual ECU devices (130) coupled to the SOVD server (128).

5. The system (100) of any of claims 1 to 4, the one or more processors (814) further configured to: map the query data (302, 405, 505) from a first diagnostic message protocol to the first protocol of the first set of one or more ECUs (140); and map the diagnostic data from the first protocol of the first set of one or more ECUs to the first diagnostic message protocol to generate the response data (304, 406, 506) from the vehicle diagnostic gateway (122).

6. The system (100) of any of claims 1 to 5, the one or more processors (814) further configured to map the query data (302, 405, 505) from a first diagnostic message protocol to the second protocol of the second set of one or more ECUs (126); and map the diagnostic data from the second protocol of the second set of one or more ECUs (126) to the first diagnostic message protocol to generate the response data (304, 406, 506) from the vehicle diagnostic gateway (122).

7. The system (100) of any of claims 1 to 6, wherein the first classification indicates that the query data (302, 405, 505) is directed to the first set of one or more ECUs (140), or that the query data (302, 405, 505) comprises the message format associated with the first protocol of the first set of one or more ECUs (140).

8. The system (100) of any of claims 1 to 7, wherein the second classification indicates that the query data (302, 405, 505) is directed to one or more virtualized ECUs (126) instantiated by the on-vehicle computing platform (120), or that the query data (302, 405, 505) comprises the message format associated with the second protocol of the second set of one or more ECUs (126).

9. The system (100) of any of claims 1 to 8, wherein the second classification indicates that the query data (302, 405, 505) is directed to one or more individual ECU devices (130) coupled to the SOVD server (128), or that the query data (302, 405, 505) comprises the message format associated with the second protocol of the second set of one or more ECUs (126).

10. The system (100) of any of claims 1-9, wherein the first protocol comprises a hexadecimal encoded message format and the second protocol comprises a hypertext format.

11. The system (100) of any of claims 1 to 10, the one or more processors (814) further configured to couple to a diagnostic client (110, 402, 503) using a diagnostic port interface (301, 401, 501), wherein the query data (302, 405, 505) and the response data (304, 406, 506) are communicated via the diagnostic port interface (301, 401, 501).

12. The system (100) of claim 11, wherein the diagnostic port interface (301, 401, 501) comprises at least one of: a wired data link interface, a wireless data link interface, and a wireless network interface.

13. A vehicle onboard diagnostics system (100), the system (100) comprising: at least one diagnostic port interface configured to couple to a diagnostic client (110, 402, 503); a vehicle gateway (142) coupled to a first set of one or more electronic control units (ECUs) via a vehicle legacy network bus; at least one computing platform (120) comprising: at least one diagnostic server (128), wherein the at least one computing platform (120) instantiates a second set of one or more virtualized ECUs (126) coupled to the at least one diagnostic server (128); and a unified diagnostic gateway (122) coupled to the at least one diagnostic server (128) and the vehicle gateway (142), wherein the unified diagnostic gateway (122) is configured to: determine a diagnostic message classification associated with query data (302, 405, 505) received from the diagnostic client (110, 402, 503); route a first query message via the vehicle gateway (142) to request diagnostic data from the one or more ECUs (140) coupled to the vehicle gateway (142) when the diagnostic message classification indicates a first classification; route a second query message via the at least one diagnostic server (128) to request the diagnostic data from the second set of one ormore virtualized ECUs (126) when the diagnostic message classification indicates a second classification; and output response data (304, 406, 506) to the diagnostic client (110, 402, 503) based on the diagnostic data generated in response to the query data (302, 405, 505).

14. The system (100) of claim 13, wherein the first query message comprises a message format based on a first protocol of the first set of one or more ECUs; and the second query message comprises the message format based on a second protocol of the second set of one or more virtualized ECUs (126).

15. The system (100) of any of claims 13 to 14, the system (100) further comprising: one or more individual ECU devices (130) coupled to the at least one diagnostic server (128); and wherein the second classification indicates that the query data (302, 405, 505) is directed to the one or more individual ECU devices (130) coupled to the at least one diagnostic server (128), or that the query data (302, 405, 505) comprises a message format associated with the one or more individual ECU devices (130) coupled to the at least one diagnostic server (128).

16. The system (100) of any of claims 13 to 14, further comprising a protocol mapping function (124); wherein the protocol mapping function (124) is configured to map the query data (302, 405, 505) from a first diagnostic message protocol to a first protocol of the one or more ECUs coupled to the vehicle gateway (142); and wherein the protocol mapping function (124) is configured to map the diagnostic data from the first protocol of the one or more ECUs coupled to the vehicle gateway (142) to the first diagnostic message protocol to generate the response data (304, 406, 506).

17. A method for routing onboard vehicle diagnostic messages, the method comprising:determining a diagnostic message classification associated with query data (302, 405, 505) received at a vehicle diagnostic gateway (122); routing a first query message via a vehicle gateway (142) to request diagnostic data from a first set of one or more electronic control units (ECUs) (140) coupled to the vehicle gateway (142) when the diagnostic message classification indicates a first classification, the first query message comprising a message format based on a first protocol of the first set of one or more ECUs (140); routing a second query message via a Service-Oriented Vehicle Diagnostics (SOVD) server (128) of an on-vehicle computing platform (120) to request the diagnostic data from a second set of one or more ECUs (126, 130) when the diagnostic message classification indicates a second classification, the second query message comprising a message format based on a second protocol of the second set of one or more ECUs (126, 130); and outputting response data (304, 406, 506) from the vehicle diagnostic gateway (122) based on the diagnostic data generated in response to the query data (302, 405, 505).

18. The method of claim 17, the method further comprising: mapping the query data (302, 405, 505) from a first diagnostic message protocol to the first protocol of the first set of one or more ECUs (140); and mapping the diagnostic data from the first protocol of the first set of one or more ECUs (140) to the first diagnostic message protocol to generate the response data (304, 406, 506) from the vehicle diagnostic gateway (122).

19. The method of any of claims 17 to 18, wherein the second set of one or more ECUs comprises one or more virtualized ECUs (126) instantiated by the on-vehicle computing platform (120).

20. The method of any of claims 17 to 19, wherein the second set of one or more ECUs comprises one or more individual ECU devices (130) coupled to the SOVD server (128).

Images