Apparatus, system and method for routing multiple diagnostic pathways

Abstract

The present invention provides an apparatus, system, and method for routing multiple diagnostic paths. A protocol data unit (PDU) router can receive a diagnostic response. The PDU router can identify the diagnostic request based on a comparison of a first PDU identifier associated with the diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response. Based on the first PDU identifier and the second PDU identifier, a routing path between a diagnostic target and a diagnostic client associated with the diagnostic request is identified. The PDU router can route the diagnostic response to the diagnostic client based on the routing path. The routing path can overlap with at least a portion of a second routing path between the diagnostic target and the second diagnostic client.

Description

Technical Field

[0001] The present disclosure relates generally to automotive electronic systems and, more particularly, to vehicle diagnostics. Background Art

[0002] Some automotive electronic systems may include an electronic control unit (ECU) capable of controlling electrical systems or subsystems within the vehicle. In some cases, the ECU (also referred to herein as a diagnostic server) can retrieve diagnostic information associated with the vehicle by reading values ​​from vehicle sensors. A diagnostic tester (also referred to herein as a diagnostic client, diagnostic test device, or diagnostic test application) can access the ECU and use the diagnostic application to access and evaluate the retrieved diagnostic information.

[0003] In some vehicle diagnostic technologies, routing between diagnostic equipment and ECUs is managed by preventing multiple overlapping routing paths between the diagnostic testers and the ECUs. For example, in some vehicle diagnostic systems, multiple diagnostic testers are routed to the ECUs via corresponding static routing paths that do not overlap with each other. Summary of the Invention

[0004] According to example aspects of the present disclosure, a vehicle system (e.g., a vehicle communication system) is described herein that can support multiple routing paths (also referred to herein as routing pathways) between a diagnostic client and a diagnostic server. The diagnostic client can be, for example, a diagnostic test device, a diagnostic test application, etc. The diagnostic server can be, for example, an ECU, a controller area network (CAN) ECU, a local interconnect network (LIN) ECU, etc.

[0005] Each routing path between the diagnostic client and the diagnostic server can include an electrical interconnection between the diagnostic client and the diagnostic server. In some aspects, the routing path can be a static (e.g., fixed) routing path. Aspects of the present disclosure can support overlaps between multiple routing paths. For example, an electrical interconnection included in a routing path can overlap with an electrical interconnection included in at least one other routing path.

[0006] The vehicle system may include a protocol data unit (PDU) router module capable of routing PDUs (eg, diagnostic requests, diagnostic responses) between a diagnostic client and a diagnostic server of the vehicle system.

[0007] For example, the PDU router may include a diagnostic manager (also referred to herein as a diagnostic assistant or diagnostic assistant) that includes a list of PDU identifiers for matching diagnostic requests with diagnostic responses. In an example, the list may be a pre-generated list of PDU identifiers. In some aspects, when routing the diagnostic response from the diagnostic server to the diagnostic client, the diagnostic manager may use the list of PDU identifiers to distinguish between multiple routing paths between the diagnostic client and the diagnostic server.

[0008] In an example, the diagnostic manager can distinguish between multiple routing paths by tracking where each diagnostic request originates (e.g., from which diagnostic client). For example, the diagnostic manager can distinguish between multiple routing paths by remembering the most recent (e.g., most recent) diagnostic request to the diagnostic server. In an example, the diagnostic manager can remember (e.g., maintain in memory) the PDU identifier associated with the most recent diagnostic request. Accordingly, for example, the diagnostic manager can remember the routing path between the diagnostic server and the diagnostic client that provided the most recent diagnostic request.

[0009] When the PDU router receives a diagnostic response from the diagnostic server, the diagnostic manager can match the diagnostic response with the latest diagnostic request based on the PDU identifier associated with the diagnostic response and the PDU identifier associated with the latest diagnostic request. Accordingly, for example, the PDU router (e.g., using the diagnostic manager and the PDU identifier list) can route the diagnostic response to the diagnostic client that provided the latest diagnostic request. In an example, the PDU router can route the diagnostic response to the diagnostic client using the routing path provided by the diagnostic client through which the latest diagnostic request was taken.

[0010] Aspects of the present disclosure may support avoiding multiple client diagnostic sessions concurrently with a single server. For example, a PDU router may inhibit routing or distributing multiple diagnostic requests (e.g., from the same diagnostic client, from different diagnostic clients, etc.) to the same diagnostic server.

[0011] In some aspects, a newer diagnostic request to a diagnostic server may take precedence (e.g., always take precedence) over an earlier diagnostic request. For example, if a PDU router (and / or diagnostic server) receives two diagnostic requests consecutively and the first diagnostic request requires a response, the PDU router (and / or diagnostic server) may consider the two diagnostic requests to be errors. Additionally or alternatively, if the first diagnostic request does not require a response, the PDU router (and / or diagnostic server) may consider the two diagnostic requests to be not errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1An example of a system supporting routing multiple diagnostic pathways according to aspects of the present disclosure is shown.

[0013] Figure 2 An example of a system supporting routing multiple diagnostic pathways according to aspects of the present disclosure is shown.

[0014] Figure 3 An example of a process flow supporting routing multiple diagnostic pathways according to aspects of the present disclosure is shown.

[0015] Figure 4 is a block diagram illustrating an example of a communication environment for a vehicle according to aspects of the present disclosure.

[0016] Figure 5 is a block diagram illustrating an example of a communication subsystem of a vehicle according to aspects of the present disclosure.

[0017] Figure 6 is a block diagram illustrating an example of a computing environment for a vehicle in accordance with aspects of the present disclosure.

[0018] Figure 7 is a block diagram illustrating an example of a computing device associated with one or more components described herein. DETAILED DESCRIPTION

[0019] Embodiments of the present disclosure will be described in conjunction with vehicle systems.

[0020] Figure 1 A perspective view of a vehicle 100 according to an example aspect of the present disclosure is shown. The vehicle 100 may include one or more interior components (e.g., components within the interior space of the vehicle 100 or within a user's space, etc.), exterior components (e.g., components outside the interior space of the vehicle 100 or within a user's space, etc.), a drive system, a control system, structural components, etc.

[0021] Although shown in the form of a car, it should be understood that the vehicle 100 described herein may include any vehicle or type of vehicle designed to move one or more tangible objects, such as people, animals, cargo, etc. The term "vehicle" does not require that the vehicle move or be capable of moving. Typical vehicles may include, but are not limited to, cars, trucks, motorcycles, buses, automobiles, trains, rail vehicles, boats, ships, marine vehicles, submarine vehicles, airplanes, space shuttles, aircraft, human transport vehicles, etc.

[0022] In some embodiments, the vehicle 100 may include a plurality of sensors, devices, and / or systems that can assist in driving operations, such as automatic or semi-automatic control. Examples of various sensors and systems may include, but are not limited to, one or more of the following: cameras (e.g., independent, stereoscopic, combined images, etc.), infrared (IR) sensors, radio frequency (RF) sensors, ultrasonic sensors (e.g., transducers, transceivers, etc.), radar sensors (e.g., object detection sensors and / or systems), lidar (light imaging, detection, and ranging) systems, ranging sensors and / or devices (e.g., encoders, etc.), orientation sensors (e.g., accelerometers, gyroscopes, magnetometers, etc.), navigation sensors and systems (e.g., GPS, etc.), and other ranging, imaging, and / or object detection sensors. Sensors may be located in the interior space of the vehicle 100 and / or on the exterior of the vehicle 100. In some embodiments, sensors and systems may be located in one or more parts of the vehicle 100 (e.g., the frame, body panels, compartments, etc. of the vehicle 100).

[0023] According to an example aspect of the present disclosure, a vehicle 100 may include a vehicle system 101 that supports multiple routing paths between diagnostic test devices 112, diagnostic test applications 116 (e.g., implemented at the diagnostic test devices 112 or other devices (not shown)), and controllers 120. The routing paths may be referred to as diagnostic pathways. The vehicle system 101 may include a PDU router 104, diagnostic test devices 112 (e.g., diagnostic test devices 112-a through diagnostic test devices 112-n), diagnostic test applications 116 (e.g., diagnostic test applications 116-a through diagnostic test applications 116-n), and controllers 120 (e.g., controllers 120-a through 120-n).

[0024] In some aspects, the diagnostic test device 112 (e.g., any one of the diagnostic test devices 112-a through 112-n) can be implemented locally on the vehicle system 101. For example, the diagnostic test device 112-a can be mechanically and / or electrically integrated with the vehicle system 101, connected to a local communication network of the vehicle system 101, etc. Additionally or alternatively, the diagnostic test device 112 (e.g., any one of the diagnostic test devices 112-a through 112-n) can be external to the vehicle system 101. In some cases, the diagnostic test application 116 (e.g., any one of the diagnostic test applications 116-a through 116-n) can be implemented locally on the vehicle system 101 or can be external to the vehicle system 101.

[0025] The PDU router 104 can support routing PDUs between the diagnostic test device 112 (and / or the diagnostic test application 116) and the controller 120. In some aspects, the PDU can include a diagnostic request and a diagnostic response. For example, the PDU router 104 can support routing PDUs between the diagnostic test device 112 (and / or the diagnostic test application 116) and the controller 120 via bus-specific interface modules and protocol-specific modules associated with a vehicle communication stack architecture (e.g., an AUTOSAR ComStack architecture, etc.).

[0026] For example, the PDU router 104 can route PDUs between modules such as communication interface (IF) modules (e.g., CAN IF modules, LIN IF modules, Ethernet IF modules, etc.), transport protocol (TP) modules (e.g., CAN TP modules, LIN TP modules, etc.), relay modules (e.g., CAN relay modules, etc.), etc. In some aspects, the PDU router 104 can provide a PDU-level gateway for transmitting PDUs received from a bus-specific interface module to another bus-specific interface module. In some cases, the PDU router 104 can provide a gateway function when routing PDUs from a controller 120 (e.g., controller 120-a) to another controller 120 (e.g., controller 120-n) using the same protocol.

[0027] In an example, the PDU router 104 may route diagnostic request(s) from the diagnostic test device 112-a to the controller 120-a, and the PDU router 104 may route corresponding diagnostic response(s) from the controller 120-a to the diagnostic test device 112-a. Additionally or alternatively, the PDU router 104 may route diagnostic request(s) from the diagnostic test application 116-a to the controller 120-a, and the PDU router 104 may route corresponding diagnostic response(s) from the controller 120-a to the diagnostic test application 116-a. In such an example, the diagnostic test device 112-a (and / or the diagnostic test application 116-a) may be referred to as a diagnostic client, and the controller 120-a may be referred to as a diagnostic server.

[0028] In some aspects, the PDU router 104 can route diagnostic request(s) and corresponding diagnostic response(s) between any of the diagnostic test devices 112, the diagnostic test applications 116, and the controller 120. For example, the PDU router 104 can route diagnostic request(s) from a diagnostic client (e.g., a diagnostic test device 112, a diagnostic test application 116, a controller 120, etc.) to a diagnostic server (e.g., a diagnostic test device 112, a diagnostic test application 116, a controller 120, etc.), and the PDU router 104 can route corresponding diagnostic response(s) from the diagnostic server to the diagnostic client. The diagnostic server can be referred to as a diagnostic target.

[0029] In some cases, the diagnostic test device 112 (e.g., any one of the diagnostic test devices 112-a through 112-n) may be internal to (e.g., mechanically and / or electrically integrated with) the vehicle 100. Additionally or alternatively, the diagnostic test device 112 (e.g., any one of the diagnostic test devices 112-a through 112-n) may be external to the vehicle 100.

[0030] The controller 120 (e.g., any one of the controllers 120-a to 120-n) may be an embedded system capable of controlling one or more electrical systems or subsystems in the vehicle 100. For example, the controller 120 (e.g., the controller 120-a) may be an ECU (also referred to herein as an electronic control module (ECM)). In some cases, the controller 120 may be an ECU, such as an engine control module (ECM), a powertrain control module (PCM), a transmission control module (TCM), a brake control module (BCM or EBCM), a central control module (CCM), a central timing module (CTM), a general electronic module (GEM), a body control module (BCM), a suspension control module (SCM), a control unit, or a control module, but is not limited thereto. In some examples, the controller 120 (e.g., any one of the controllers 120-a to 120-n) may be a CAN ECU, a local interconnect network (LIN) ECU, or the like.

[0031] According to example aspects of the present disclosure, the vehicle system 101 can support overlap between multiple routing paths. For example, an electrical interconnection included in a routing path (e.g., between the diagnostic test device 112-a and the controller 120-a) can overlap with an electrical interconnection included in at least one other routing path (e.g., between the diagnostic test device 112-b and the controller 120-a).

[0032] The PDU router 104 may include a diagnostic manager 108. The diagnostic manager 108 may also be referred to herein as a diagnostic assistant, diagnostic assistant, or PDU routing engine. In some aspects, the diagnostic manager 108 may include a list of PDU identifiers (e.g., a table, a lookup table, a registry, etc.) for matching diagnostic requests with diagnostic responses. In an example, the list may be a pre-generated list of PDU identifiers. In some aspects, when routing a diagnostic response from a diagnostic server (e.g., a controller 120-a) to a diagnostic client (e.g., a diagnostic test device 112-a), the diagnostic manager 108 may use the PDU identifier list to distinguish between multiple routing paths between the diagnostic client (e.g., a diagnostic test device 112, a diagnostic test application 116, etc.) and the diagnostic server (e.g., a controller 120-a).

[0033] In some aspects, the diagnostic manager 108 can distinguish between multiple routing paths by tracking where each diagnostic request originates (e.g., from which diagnostic client). For example, the diagnostic manager 108 can distinguish between multiple routing paths by remembering the latest (e.g., most recent) diagnostic request to a diagnostic server (e.g., controller 120-a). In an example, the diagnostic manager 108 can remember (e.g., maintain in memory) the PDU identifier associated with the latest diagnostic request. Accordingly, for example, the diagnostic manager 108 can remember the routing path between the diagnostic server (e.g., controller 120-a) and the diagnostic client (e.g., diagnostic test device 112-a) that provided the latest diagnostic request.

[0034] When the PDU router 104 receives a diagnostic response from a diagnostic server (e.g., controller 120-a), the diagnostic manager 108 can match the diagnostic response with the latest diagnostic request based on the PDU identifier associated with the diagnostic response and the PDU identifier associated with the latest diagnostic request. Accordingly, for example, the PDU router 104 (e.g., using the diagnostic manager 108 and the PDU identifier list) can route the diagnostic response to the diagnostic client (e.g., diagnostic test device 112-a) that provided the latest diagnostic request. In the example, the PDU router 104 can route the diagnostic response to the diagnostic client (e.g., diagnostic test device 112-a) using the routing path through which the diagnostic client provided the latest diagnostic request.

[0035] The vehicle system 101 (eg, the PDU router 104, the diagnostic manager 108, the diagnostic test equipment 112, the controller 120, etc.) can communicate with the vehicle system 101 via the communication system 400 (hereinafter referred to as Figure 4 Description), vehicle computing device 604 (later reference Figure 6 ) and / or computer system 700 (later referred to Figure 7In some cases, the controller 120 may be implemented by referring to Figure 4 and Figure 5 The PDU identifier lists (e.g., tables, lookup tables, registers, etc.) described herein may be implemented in a database (e.g., referenced later). Figure 6 described database 618) and / or memory (e.g., referenced later). Figure 7 (one or more) storage devices 720) described above.

[0036] Figure 2 An example of a system 200 that supports routing multiple diagnostic pathways (eg, routing paths 201 to 204) according to aspects of the present disclosure is shown. The system 200 may be a reference Figure 1 An example of a vehicle system 101 is depicted. For example, system 200 may include a PDU router 204, diagnostic test devices 212 (e.g., diagnostic test devices 212-a through 212-c), diagnostic test applications 216 (e.g., diagnostic test applications 216-a through 216-d), and a controller 220.

[0037] exist Figure 2 In the example of FIG, the routing paths 201 to 204 illustrate the direction of the diagnostic request. It should be understood that the routing paths 201 to 204 also support the direction of the diagnostic response (e.g., Figure 2 The arrows shown in the example are in opposite directions).

[0038] The system 200 may support routing of PDUs between the diagnostic test device 212, the diagnostic test application 216, and the controller 220 (e.g., using the PDU router 204 and the diagnostic manager 208). In some aspects, the PDUs may include diagnostic requests and diagnostic responses. The PDU router 204, the diagnostic manager 208, the diagnostic test device 212, the diagnostic test application 216, and the controller 220 may include the PDUs described herein. Figure 1 Examples of aspects of similar elements are described.

[0039] Controller 220 may be an ECU. For example, controller 220 may be a CAN ECU with diagnostic capabilities. In some examples, controller 220 may be a LIN ECU with diagnostic capabilities. In another example, controller 220 may be a UDS server local to system 200.

[0040] An example is described in which the controller 220 can receive (one or more) diagnostic requests from the diagnostic client during a client diagnostic session established between the controller 220 and the diagnostic client. The diagnostic client can be any of the diagnostic test devices 212, any of the diagnostic test applications 216, or another controller 220 (not shown). The controller 220 can provide corresponding (one or more) diagnostic responses to the PDU router 204, and the PDU router 204 can route the (one or more) diagnostic responses to the diagnostic client. In such an example scenario, the controller 220 can be referred to as a diagnostic server or a diagnostic target.

[0041] In the examples described herein, diagnostic requests and diagnostic responses are transmitted via modules associated with the CAN protocol and / or DoIP. Aspects of the technology described herein are not limited thereto, and the technology described herein supports transmitting diagnostic requests and diagnostic responses via modules associated with other protocols (e.g., LIN TP module 252, LIN IF module 256, etc. associated with the LIN protocol).

[0042] In a first example, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between a diagnostic test application 216 (e.g., any one of the diagnostic test applications 216-d through 216-f that are implemented locally on the system 200 and capable of interacting with diagnostic functionality) and the controller 220 using a routing path 201. For example, the PDU router 204 can receive a diagnostic request from the diagnostic test application 216-d, and the PDU router 204 can route the diagnostic request to the controller 220 (and a corresponding diagnostic response to the diagnostic test application 216-d) via a 'CAN bus A' (not shown) local to the system 200. Accordingly, for example, the routing path 201 can include the PDU router 204, the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232 (e.g., wherein the PDU router 204 communicates with the diagnostic test application 216-d, the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232 using the 'CAN bus A'). In some aspects, each of the diagnostic test applications 216-d through 216-f may have a respective routing path to the PDU router 204. In an example, the diagnostic test applications 216-d through 216-f may share a portion of the routing path 201 (e.g., the portion of the routing path 201 between the PDU router 204 and the controller 220).

[0043] In a second example, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between the diagnostic test device 212-a (and / or the diagnostic test application 216-a) and the controller 220 using the routing path 202. In some aspects, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between multiple diagnostic test devices (e.g., diagnostic test devices other than the diagnostic test device 212-a) and / or multiple diagnostic test applications (e.g., diagnostic test applications other than the diagnostic test application 216-a) and the controller 220 using the routing path 202. In an example, the diagnostic test device 212-a (and / or the diagnostic test application 216-a) can connect to the PDU router 204 using a CAN bus other than 'CAN bus A' (also referred to herein as 'CAN bus B' (not shown)). 'CAN bus B' can be directly connected and routed to 'CAN bus A' via the PDU router 204. Accordingly, for example, the PDU router 204 may support exchanging diagnostic requests and diagnostic responses between the diagnostic test device 212 - a (and / or the diagnostic test application 216 - a ) and the controller 220 using 'CAN bus B' and 'CAN bus A' (eg, using a CAN to CAN connection).

[0044] For example, the PDU router 204 may receive a diagnostic request from the diagnostic test application 216-a (or alternatively, from the diagnostic test application 216-a) using 'CAN bus B'. The PDU router 204 may route the diagnostic request to the controller 220 using 'CAN bus A' (e.g., via the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232). The PDU router 204 may receive a corresponding diagnostic response from the controller 220 via 'CAN bus A' (e.g., via the CAN MCAL module 232, the CAN IF module 228, and the CAN TP module 224). The PDU router 204 may route the diagnostic response to the diagnostic test application 216-a using 'CAN bus B'. Accordingly, for example, the routing path 202 may include a CAN-to-CAN connection that includes 'CAN bus B', the PDU router 204, and 'CAN bus A' (e.g., including the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232).

[0045] In a third example, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between the diagnostic test device 212-b (and / or the diagnostic test application 216-b) and the controller 220 using the routing path 203. In some aspects, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between a plurality of diagnostic test devices (e.g., diagnostic test devices other than the diagnostic test device 212-b) and / or a plurality of diagnostic test applications (e.g., diagnostic test applications other than the diagnostic test application 216-b) and the controller 220 using the routing path 203. In an example, the diagnostic test device 212-b (and / or the diagnostic test application 216-b) can connect to the PDU router 204 using a diagnostics over internet protocol (DoIP) function (e.g., via the DoIP module 236). DoIP facilitates the use of automotive diagnostic services exposed via a TCP / IP-based UDS over an Ethernet network. The DoIP module 236 may be an operating system-independent software module that may enable the transmission of diagnostic communications between a test device (eg, the diagnostic test device 212 - b ) and a vehicle electronic component (eg, the controller 220 ) using IP.

[0046] The PDU router 204 may support exchanging diagnostic requests and diagnostic responses between the diagnostic test device 212 - b (and / or the diagnostic test application 216 - b ) and the controller 220 using DoIP and 'CAN bus A' (eg, using a DoIP to CAN connection).

[0047] For example, the PDU router 204 can receive a diagnostic request from a diagnostic test device 212-b (or alternatively, from a diagnostic test application 216-b) using DoIP. In an example, the diagnostic test device 212-b can transmit the diagnostic request to the PDU router 204 via a 'DoIP path' that includes an Ethernet IF (ETH IF) module 248, a TCP / IP module 244 (e.g., a socket-based TCP / IP stack), a socket adapter (SoAd) module 240, and the DoIP module 236. The SoAd module 240 creates an interface between the PDU router 204 (e.g., a communication service module using PDUs) and the TCP-IP module 244 (e.g., a socket-based TCP / IP stack). The SoAd module 240 can map I-PDU identifiers to socket connections and vice versa. In some cases, the SoAd module 240 may receive a UDP message or a TCP stream (e.g., where the UDP message or TCP stream may include a diagnostic request) and convert it into a PDU that is compatible with the system 200 (e.g., compatible with the PDU router 204, the CAN TP module 224, the CAN IF module 228, the CAN MCAL module 232, the controller 220, etc.).

[0048] The PDU router 204 may route the diagnostic request (e.g., converted into a PDU) to the controller 220 using 'CAN bus A' (e.g., via the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232). The PDU router 204 may receive a corresponding diagnostic response from the controller 220 using 'CAN bus A' (e.g., via the CAN MCAL module 232, the CAN IF module 228, the CAN TP module 224). The PDU router 204 may route the diagnostic response to the diagnostic test application 216-b via the 'DoIP path' described herein (e.g., via the DoIP module 236, the SoAd module 240, the TCP / IP module 244, and the ETH IF module 248). Accordingly, for example, the routing path 203 may include a DoIP to CAN connection including 'DoIP path', the PDU router 204, and 'CAN bus A' (eg, including the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232).

[0049] In a fourth example, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between a diagnostic test device 212-c (and / or a diagnostic test application 216-c) and a controller 220 using the routing path 204. In some aspects, the PDU router 204 can support exchanging diagnostic requests and diagnostic responses between a plurality of diagnostic test devices (e.g., diagnostic test devices other than the diagnostic test device 212-c) and / or a plurality of diagnostic test applications (e.g., diagnostic test applications other than the diagnostic test application 216-c) and the controller 220 using the routing path 204. In an example, the diagnostic test device 212-c (and / or the diagnostic test application 216-c) can connect to the PDU router 204 using a CAN bus other than 'CAN bus A' (also referred to herein as 'CAN bus C' (not shown)). 'CAN bus C' can be connected and routed to 'CAN bus A' using the CAN relay 262 and the PDU router 204. Accordingly, for example, the PDU router 204 may support exchanging diagnostic requests and diagnostic responses between the diagnostic test device 212 - c (and / or the diagnostic test application 216 - c ) and the controller 220 using 'CAN bus C' and 'CAN bus A' (eg, using a CAN relay to CAN connection).

[0050] For example, the PDU router 204 may receive a diagnostic request from the diagnostic test device 212-c (or alternatively, from the diagnostic test application 216-c) using the CAN bus C. In this example, the diagnostic test device 212-c may transmit the diagnostic request to the PDU router 204 via the CAN relay path, which includes the ETH IF module 248, the TCP / IP module 244, the SoAd module 240, the CAN relay module 262, the CAN IF module 228, and the CAN TP module 224.

[0051] The PDU router 204 may route the diagnostic request to the controller 220 using 'CAN bus A' (e.g., using the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232). The PDU router 204 may receive a corresponding diagnostic response from the controller 220 using 'CAN bus A' (e.g., using the CAN MCAL module 232, the CAN IF module 228, and the CAN TP module 224). The PDU router 204 may route the diagnostic response to the diagnostic test application 216-a via a 'CAN relay path'. Accordingly, for example, the routing path 204 may include a CAN relay to CAN connection that includes 'CAN bus C', the CAN relay module 262, the SoAd module 240, the TCP / IP module 244, the ETH IF module 2xx, the PDU router 204, and 'CAN bus A' (e.g., including the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232).

[0052] According to example aspects of the present disclosure, the PDU router 204 (e.g., using the diagnostic manager 208) can differentiate between multiple routing paths between the controller 220 and multiple diagnostic clients (e.g., diagnostic test application 216-d to diagnostic test application 216-f (local application to CAN), diagnostic test device 212-a (CAN to CAN), diagnostic test device 212-b (DoIP to CAN), diagnostic test device 212-c (CAN relay to CAN), etc.). Example aspects of the present disclosure can support routing between the controller 220 and multiple diagnostic clients (e.g., multiple diagnostic test devices 212 and / or diagnostic test applications 216), regardless of where the diagnostic clients are located.

[0053] For example, PDU router 204 (eg, using diagnostic manager 208 ) may distinguish between multiple routing paths by remembering the latest (eg, most recent) diagnostic request to controller 220 .

[0054] In an example, the PDU router 204 may (e.g., at different time instances) receive different diagnostic requests from any of the following: diagnostic test application 216-d to diagnostic test application 216-f (local application to CAN), diagnostic test device 212-a (CAN to CAN), diagnostic test application 216-a (CAN to CAN), diagnostic test device 212-b (DoIP to CAN), diagnostic test application 216-b (DoIP to CAN), diagnostic test device 212-c (CAN relay to CAN), and diagnostic test application 216-c (CAN relay to CAN).

[0055] In an example, the diagnostic manager 208 can remember (e.g., maintain in memory) the PDU identifier associated with each diagnostic request. In some aspects, the diagnostic manager 208 can remember (e.g., maintain in memory) the PDU identifier associated with the most recent diagnostic request (e.g., the most recent or most recent diagnostic request received at the PDU router 204).

[0056] For example, the diagnostic manager 208 can identify that the diagnostic request from the diagnostic test device 212-a (CAN to CAN) is the most recent diagnostic request received at the PDU router 204. The diagnostic manager 208 can remember the diagnostic test device 212-a as the source of the most recent diagnostic request. In an example, the diagnostic manager 208 can remember (e.g., maintain in memory) the PDU identifier associated with the diagnostic request from the diagnostic test device 212-a.

[0057] When the PDU router 204 receives a diagnostic response from the controller 220, the diagnostic manager 208 may identify a PDU identifier associated with the diagnostic response. The diagnostic manager 208 may determine that the PDU identifier associated with the diagnostic response matches (e.g., based on a table, a lookup table, a registry, etc.) a PDU identifier associated with the diagnostic request from the diagnostic test device 212-a. For example, the PDU identifier associated with the diagnostic request and the PDU identifier associated with the diagnostic response may be established at generation time. In an example, at generation time, the PDU identifier for the diagnostic request may be paired with the PDU identifier associated with the diagnostic response, and these PDU identifiers may be stored as a tuple in the table. Accordingly, for example, the PDU router 204 may route the diagnostic response to the diagnostic test device 212-a using the routing path 201 (e.g., including 'CAN bus B') via which the diagnostic test device 212-a provided the diagnostic request to the PDU router 204.

[0058] In some aspects, the PDU identifier associated with the diagnostic response can be the same as the PDU identifier associated with the diagnostic request. In some other aspects, the PDU identifier associated with the diagnostic response can be different from the PDU identifier associated with the diagnostic request.

[0059] Although the examples described herein describe the diagnostic request from the diagnostic test device 212-a (CAN to CAN) as the most recent diagnostic request received at the PDU router 204, aspects of the present disclosure are not limited thereto. For example, the most recent diagnostic request received at the PDU router 204 may be from any diagnostic client (e.g., any one of the diagnostic test device 212 and the diagnostic test application 216), and the diagnostic manager 208 may record the diagnostic client that provided the most recent diagnostic request as the corresponding source. The diagnostic manager 208 may remember (e.g., maintain in a memory) the PDU identifier associated with the diagnostic request. When the PDU router 204 receives a diagnostic response from the controller 220, the diagnostic manager 208 may match the diagnostic response with the most recent diagnostic request based on the PDU identifier associated with the diagnostic response and the PDU identifier associated with the most recent diagnostic request.

[0060] Accordingly, for example, the PDU router 204 (e.g., using the diagnostic manager 208 and the PDU identifier list) can route the diagnostic response to the diagnostic client that provided the most recent diagnostic request. In the example, the PDU router 204 can route the diagnostic response to the diagnostic client using the routing path (e.g., routing path 201, routing path 202, etc.) through which the diagnostic client provided the most recent diagnostic request.

[0061] Each routing path between the diagnostic client and the diagnostic server may include an electrical interconnection between the diagnostic client and the diagnostic server. In some aspects, the routing paths (e.g., routing path 201 to routing path 204) may be static (e.g., fixed) routing paths. Aspects of the present disclosure may support overlap between routing paths 201 to routing paths 204. For example, Figure 2 As shown, routing paths 201 to 204 can share a single shared path (also referred to as an overlapping shared path) from PDU router 204 to controller 220. In an example, routing paths 203 and 204 can share a single shared path from ETH IF module 248 to SoAd module 240.

[0062] For example, the electrical interconnects included in a routing path may overlap with the electrical interconnects included in a portion of at least one other routing path. In an example, portions of routing paths 201 through 204 overlap from the PDU router 204 to the controller 220 (e.g., each of routing paths 201 through 204 traverses the CAN TP module 224, the CAN IF module 228, and the CAN MCAL module 232). In another example, portions of routing paths 203 and 204 overlap from the PDU router 204 to the controller 220, and additional portions of routing paths 203 and 204 overlap from the SoAd module 240 to the ETH IF module 248 (e.g., each of routing paths 203 and 204 traverses the SoAd module 240, the TCP / IP module 244, and the ETH IF module 248).

[0063] According to example aspects of the present disclosure, a system can support routing of PDUs between a diagnostic client (e.g., a diagnostic test device 212, a diagnostic test application 216) and multiple diagnostic targets (e.g., a controller 220, other controllers, etc.). For example, although the examples herein are described with reference to the controller 220 as a diagnostic target, aspects of the present disclosure can be applied to multiple simultaneous client diagnostic sessions established at multiple diagnostic targets (e.g., the controller 220, other controllers, etc.). For example, the routing techniques described herein can support routing PDUs (e.g., routing diagnostic requests and diagnostic responses according to corresponding routing paths) between the controller 220 and any one of the diagnostic test device 212 and the diagnostic test application 216, while simultaneously routing PDUs (e.g., diagnostic requests, diagnostic responses, etc.) between another controller (not shown) and any one of the diagnostic test device 212 and the diagnostic test application 216.

[0064] In some aspects of the present disclosure, the system 200 can support receiving additional diagnostic requests from other sources (e.g., at the PDU router 204, at the controller 220) before providing a diagnostic response corresponding to the first diagnostic request. In some aspects, the system 200 can support maintaining client request ordering (e.g., providing and routing a diagnostic response corresponding to a first diagnostic request before providing and routing a diagnostic response corresponding to a subsequent diagnostic request). In some other aspects, the system 200 may not support maintaining client request ordering.

[0065] In some aspects of the present disclosure, each diagnostic request can suppress a diagnostic response (eg, for a functional request). For example, a diagnostic request can support suppressing a diagnostic response based on the value of a UDS SuppressPosReplyBit.

[0066] Figure 3An example of a process flow 300 that supports routing multiple diagnostic pathways according to aspects of the present disclosure is shown. In some examples, the process flow 300 may implement a reference Figure 1 and Figure 2 Aspects of vehicle 100 , vehicle system 101 , and system 200 are described.

[0067] In the following description of process flow 300, operations may be performed in a different order than shown, or operations may be performed in a different order or at a different time. Some operations may not be performed in process flow 300, or other operations may be added to process flow 300.

[0068] It should be understood that although the PDU router 104 is described as performing the various operations of the process flow 300 , any device (eg, another PDU router 104 ) may perform the illustrated operations.

[0069] At 305 , the PDU router 104 may receive a diagnostic request from a diagnostic client.

[0070] At 310, the PDU router 104 may route the diagnostic request to a diagnostic target. In some aspects, the diagnostic request may include a request for a diagnostic response.

[0071] In some aspects, the diagnostic client may include at least one of: a first client device coupled to a diagnostic target via a first communication bus; a second client device coupled to the diagnostic target via a second communication bus, wherein the first communication bus and the second communication bus are of a first communication protocol type; a third client device coupled to the diagnostic target via a third communication bus, wherein the third communication bus is of a second communication protocol type; and a fourth client device coupled to the diagnostic target via a fourth communication bus and a relay device, wherein the fourth communication bus and the relay device are of the first communication protocol type.

[0072] In some aspects, the first communication protocol type may include the CAN protocol; and the second communication protocol type may include DoIP.

[0073] In some aspects, the diagnostic target may include at least one of: a diagnostic server; a CAN ECU; a LIN ECU; and a local UDS server.

[0074] The PDU router 104 may receive a diagnostic response at 315. In some aspects, the diagnostic response is generated at the diagnostic target based on the diagnostic request.

[0075] At 320 , the PDU router 104 may identify the diagnostic request based on a comparison of a first PDU identifier associated with the diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response.

[0076] At 325 , the PDU router 104 may identify a routing path between the diagnostic target and the diagnostic client based on the first PDU identifier and the second PDU identifier, wherein the routing path is associated with the diagnostic request.

[0077] At 330 , the PDU router 104 may route the diagnostic response to the diagnostic client associated with the diagnostic request.

[0078] In some aspects, routing the diagnostic response to the diagnostic client may include transmitting the diagnostic response to the diagnostic client based on the routing path.

[0079] In some aspects, the routing path overlaps with at least a portion of a second routing path between the diagnostic target and the second diagnostic client. In some aspects, the routing path may include a set of electrical interconnections between the diagnostic target and the diagnostic client; the second routing path may include a second set of electrical interconnections between the diagnostic target and the second diagnostic client; and the set of electrical interconnections at least partially overlaps with the second set of electrical interconnections.

[0080] In some examples not shown, the PDU router 104 can generate a set of PDU identifiers, the set of PDU identifiers including a first PDU identifier and a second PDU identifier. In some aspects, each PDU identifier in the set of PDU identifiers corresponds to a previous diagnostic request in a set of previous diagnostic requests and a candidate diagnostic client in a set of candidate diagnostic clients; the set of previous diagnostic requests can include a diagnostic request; and the set of candidate diagnostic clients can include a diagnostic client. In some aspects, each PDU identifier is associated with a routing path between a diagnostic target and a diagnostic client in the set of candidate diagnostic clients.

[0081] Figure 4 is a block diagram illustrating an example of a communication environment of a vehicle 100 according to aspects of the present disclosure.

[0082] The communication system 400 may include one or more vehicle driving sensors and systems 404, a sensor processor 430, a sensor data storage 434, a vehicle control system 438, a communication subsystem 450, control data 464, a computing device 468, a display device 472, and other components 474 that may be associated with the vehicle 100. These associated components may be electrically and / or communicatively coupled to each other via at least one bus 460. In some embodiments, one or more of the associated components may send and / or receive signals to at least one of a navigation source 456A, a control source 456B, or some other entity 456N via a communication network 452.

[0083] According to at least some embodiments of the present disclosure, the communication network 452 may include any type of known communication medium or collection of communication media and may use any type of protocol, such as SIP, TCP / IP, SNA, IPX, AppleTalk, etc., to transmit messages between endpoints. The communication network 452 may include wired and / or wireless communication technologies. The Internet is an example of a communication network 452, which constitutes an Internet Protocol (IP) network, which is composed of many computers, computing networks, and other communication devices located around the world, which are connected by many telephone systems and other means. Other examples of communication networks 452 include, but are not limited to, standard plain old telephone systems (POTS), integrated services digital networks (ISDN), public switched telephone networks (PSTN), local area networks (LANs) such as Ethernet, token ring networks, and / or the like, wide area networks (WANs), including but not limited to virtual private networks ("VPNs"); the Internet, intranets, extranets, cellular networks, infrared networks; wireless networks (e.g., those in the IEEE 802.9 protocol suite, known in the art); The communication network 452 may include any type of network operating under any of the IEEE 802.11 protocols and / or any other wireless protocols, as well as any other type of packet-switched or circuit-switched network known in the art and / or any combination of these and / or other networks. Additionally, it will be appreciated that the communication network 452 need not be limited to any one type of network, but may include many different networks and / or network types. The communication network 452 may include a number of different communication media, such as coaxial cables, copper cables / wires, fiber optic cables, antennas for transmitting / receiving wireless messages, and combinations thereof.

[0084] The driving vehicle sensors and systems 404 may include at least one navigation sensor or system 408 (e.g., a global positioning system (GPS) or the like), an orientation sensor or system 412, a range sensor or system 416, a lidar sensor or system 420, a radar sensor or system 424, an ultrasonic sensor or system 428, a camera sensor or system 432, an infrared (IR) sensor or system 436, and / or other sensors or systems 438. These driving vehicle sensors and systems 404 may be combined with Figure 1 and Figure 2 The sensors and systems 116A to 116K, 112 are described as being similar, if not identical.

[0085] Navigation sensor 408 may include one or more sensors having a receiver and an antenna configured to utilize a satellite-based navigation system including a network of navigation satellites capable of providing geolocation and time information to at least one component of vehicle 100. Examples of navigation sensor 408 described herein may include, but are not limited to, at least one of the following: GLOTM series GPS and GLONASS combination sensors, GPS 15xTM series sensors, GPS 16xTM series of sensors with high sensitivity receivers and antennas, GPS 18xOEM series high-sensitivity GPS sensors, Dewetron DEWE-VGPS series GPS sensors, GlobalSat 1-Hz series GPS sensors, other industry equivalent navigation sensors and / or systems, and may use any known or future developed standards and / or architectures to perform navigation and / or geolocation functions.

[0086] Orientation sensor 412 may include one or more sensors configured to determine the orientation of vehicle 100 relative to at least one reference point. In some embodiments, orientation sensor 412 may include at least one pressure transducer, stress / strain gauge, accelerometer, gyroscope, and / or geomagnetic sensor. Examples of the navigation sensor 408 described herein may include, but are not limited to, at least one of the following: Bosch Sensortec BMX 160 series low-power absolute orientation sensor, Bosch Sensortec BMX055 9-axis sensor, Bosch Sensortec BMI055 6-axis inertial sensor, Bosch Sensortec BMI160 6-axis inertial sensor, Bosch Sensortec BMF055 9-axis inertial sensor (accelerometer, gyroscope, and magnetometer) with integrated Cortex M0+ microcontroller, Bosch Sensortec BMP280 absolute barometric pressure sensor, Infineon TLV494D-A1B6 4D magnetic sensor, Infineon TLI494D-W1B6 4D magnetic sensor, Infineon TL series 4D magnetic sensor, Murata Electronics SCC2000 series combined gyroscope sensor and accelerometer, Murata Electronics The SCC1400 series combines gyroscope sensors with accelerometers, other industry equivalent orientation sensors, and / or systems that may use any known or future developed standards and / or architectures to perform orientation detection and / or determination functions.

[0087] The ranging sensor and / or system 416 may include one or more components configured to determine the change in the position of the vehicle 100 over time. In some embodiments, the ranging system 416 may utilize data from one or more other sensors and / or systems 404 to determine the position (e.g., distance, location, etc.) of the vehicle 100 relative to a previously measured position of the vehicle 100. Additionally or alternatively, the ranging sensor 416 may include one or more encoders, Hall effect speed sensors, and / or other measurement sensors / devices configured to measure wheel speed, rotation, and / or revolutions over time. Examples of ranging sensors / systems 416 as described herein may include, but are not limited to, at least one of the following: Infineon TLE4924 / 26 / 27 / 28C high performance speed sensors, Infineon TL4941plusC(B) single chip differential Hall effect wheel speed sensors, Infineon TL5041plusC giant magnetoresistance (GMR) effect sensors, Infineon TL series magnetic sensors, EPC 25SP model Accu-CoderPro TMIncremental shaft encoders, EPC 40M compact incremental encoders with advanced magnetic sensing and signal processing technology, EPC 925 absolute shaft encoders, EPC 958 absolute shaft encoders, EPC MA46S / MA64S / SA46S absolute shaft encoders, Dynapar TM F18 commutation optical encoder, Dynapar TM HS45R Series phased array encoder sensors, other industrial equivalent distance measuring sensors and / or systems, and may use any known or future developed standards and / or architectures to perform position change detection and / or determine a change in functionality.

[0088] The lidar sensor / system 420 may include one or more components configured to measure the distance to a target using laser illumination. In some embodiments, the lidar sensor / system 420 may provide 4D imaging data of the environment surrounding the vehicle 100. The imaging data may be processed to generate a full 460-degree view of the environment surrounding the vehicle 100. The lidar sensor / system 420 may include a laser generator configured to generate multiple target illumination laser beams (e.g., laser channels). In some embodiments, the multiple laser beams may be aimed or pointed at a rotating reflective surface (e.g., a mirror) and directed outward from the lidar sensor / system 420 into the measurement environment. The rotating reflective surface may be configured to continuously rotate 460 degrees around an axis so that the multiple laser beams are directed within a full 460-degree range around the vehicle 100. The photodiode receiver of the lidar sensor / system 420 may detect when light from the multiple laser beams emitted into the measurement environment returns (e.g., as a reflected echo) to the lidar sensor / system 420. The lidar sensor / system 420 can calculate the distance from the vehicle 100 to the illuminated target based on the time associated with the emission of light and the return of the detected light. In some embodiments, the lidar sensor / system 420 can generate more than 2 million points per second and have an effective operating range of at least 100 meters. Examples of the lidar sensor / system 420 described herein may include, but are not limited to, at least one of the following: LiDAR TM HDL-64E 64-channel lidar sensor, LiDAR TM HDL-42E 42-channel lidar sensor, LiDAR TM PUCK TM VLP-16 16-channel lidar sensor, Leica Geosystems Pegasus:Two mobile sensor platform, LIDAR-Lite v4 measurement sensor, Quanergy M8 lidar sensor, Quanergy S4 solid-state lidar sensor, LeddarVU compact solid-state fixed-beam lidar sensor, other industry equivalent lidar sensors and / or systems, and may use any known or future developed standards and / or architectures to perform illuminated target and / or obstacle detection in the environment surrounding the vehicle 100.

[0089] Radar sensor 424 may include one or more radio components configured to detect objects / targets in the environment of vehicle 100. In some embodiments, radar sensor 424 may determine the distance, position, and / or motion vector (e.g., angle, velocity, etc.) associated with the target over time. Radar sensor 424 may include a transmitter configured to generate and transmit electromagnetic waves (e.g., radio, microwave, etc.), and a receiver configured to detect returning electromagnetic waves. In some embodiments, radar sensor 424 may include at least one processor configured to interpret the returning electromagnetic waves and determine the position characteristics of the target. Examples of radar sensor 424 as described herein may include, but are not limited to, at least one of the following: Infineon RASIC TM The RTN7745PL transmitter and RRN7745PL / 46PL receiver sensors, Autoliv ASP vehicle radar sensor, Delphi L2C0051TR 77GHz ESR electronically scanned radar sensor, Fujitsu Ten Ltd. automotive compact 77GHz 4D electronically scanned millimeter wave radar sensor, other industrial equivalent radar sensors and / or systems, and can perform radio target and / or obstacle detection in the environment surrounding the vehicle 100 using any known or future developed standards and / or architectures.

[0090] The ultrasonic sensor 428 may include one or more components configured to detect objects / targets in the environment of the vehicle 100. In some embodiments, the ultrasonic sensor 428 may determine the distance, position, and / or motion vector (e.g., angle, velocity, etc.) associated with the target over time. The ultrasonic sensor 428 may include an ultrasonic transmitter and receiver, or transceiver, configured to generate and transmit ultrasonic waves and interpret the return echoes of those waves. In some embodiments, the ultrasonic sensor 428 may include at least one processor configured to interpret the returned ultrasonic waves and determine the positional characteristics of the target. Examples of the ultrasonic sensor 428 described herein may include, but are not limited to, at least one of the following: Texas Instruments TIDA-00151 Automotive Ultrasonic Sensor Interface IC sensor, MB8450 ultrasonic proximity sensor, ParkSonar TM -EZ ultrasonic proximity sensor, Murata Electronics MA40H1S-R open structure ultrasonic sensor, Murata Electronics MA40S4R / S open structure ultrasonic sensor, Murata Electronics MA58MF14-7N waterproof ultrasonic sensor, other industry equivalent ultrasonic sensors and / or systems, and may use any known or future developed standards and / or architectures to perform ultrasonic detection of targets and / or obstacles in the environment surrounding the vehicle 100.

[0091] The camera sensor 432 may include one or more components configured to detect image information associated with the environment of the vehicle 100. In some embodiments, the camera sensor 432 may include a lens, a filter, an image sensor, and / or a digital image processor. One aspect of the present disclosure is that multiple camera sensors 432 may be used together to produce stereo images, thereby providing depth measurements. Examples of camera sensors 432 as described herein may include, but are not limited to, at least one of the following: MT9V024 global shutter VGA GS CMOS image sensor, Teledyne DALSAFalcon2 camera sensor, CMOSIS CMV50000 high-speed CMOS image sensor, other industrial equivalent camera sensors and / or systems, and may use any known or future developed standards and / or architectures to perform visual object and / or obstacle detection in the environment surrounding the vehicle 100 .

[0092] The infrared (IR) sensor 436 may include one or more components configured to detect image information associated with the environment of the vehicle 100. The IR sensor 436 may be configured to detect targets in low light, dark, or poorly lit environments. The IR sensor 436 may include an IR light emitting element (e.g., an IR light emitting diode (LED), etc.) and an IR photodiode. In some embodiments, the IR photodiode may be configured to detect returned IR light of the same or approximately the same wavelength as the wavelength emitted by the IR light emitting element. In some embodiments, the IR sensor 436 may include at least one processor configured to interpret the returned IR light and determine positional characteristics of the target. The IR sensor 436 may be configured to detect and / or measure a temperature associated with a target (e.g., an object, a pedestrian, another vehicle, etc.). Examples of the IR sensor 436 as described herein may include, but are not limited to, at least one of the following: a photodiode lead salt IR array sensor, a photodiode OD-850 near infrared LED sensor, a photodiode SA / SHA727 steady state IR emitter with IR detector, LS microbolometer sensor, TacFLIR 480-HD InSb MWIR FPA with HD MWIR thermal sensor, VOx 640x480 pixel detector sensor, DelphiIR sensor, other industry equivalent IR sensor and / or system, and performs IR visual target and / or obstacle detection in the environment around the vehicle 100 using any known or future developed standard and / or architecture.

[0093] The vehicle 100 may also include one or more interior sensors 437. The interior sensors 437 may measure characteristics of the interior environment of the vehicle 100.

[0094] The navigation system 402 may include any hardware and / or software for manually or automatically navigating a vehicle. Figure 4 Descriptive.

[0095] In some embodiments, the driving vehicle sensors and system 404 may include other sensors 438 and / or combinations of the aforementioned sensors 406-437. Additionally or alternatively, one or more of the aforementioned sensors 406-437 may include one or more processors configured to process and / or interpret signals detected by one or more of the sensors 406-437. In some embodiments, processing of at least some sensor information provided by the vehicle sensors and system 404 may be handled by at least one sensor processor 430. Raw and / or processed sensor data may be stored in a sensor data storage 434 storage medium. In some embodiments, the sensor data storage 434 may store instructions used by the sensor processor 430 to process the sensor information provided by the sensors and system 404. In any case, the sensor data storage 434 may be a disk drive, an optical storage device, a solid-state storage device such as a random access memory ("RAM") and / or a read-only memory ("ROM"), which may be programmable, flash-updatable, or the like.

[0096] The vehicle control system 438 may receive processed sensor information from the sensor processor 430 and determine whether to control certain aspects of the vehicle 100. Controlling certain aspects of the vehicle 100 may include presenting information via one or more display devices 472 associated with the vehicle, sending commands to one or more computing devices 468 associated with the vehicle, and / or controlling the driving operation of the vehicle. In some embodiments, the vehicle control system 438 may correspond to one or more computing systems that control the driving operation of the vehicle 100 according to the aforementioned driving automation level. In one embodiment, the vehicle control system 438 may manipulate the speed of the vehicle 100 by controlling output signals to the vehicle's accelerometer and / or braking system. In this example, the vehicle control system 438 may receive sensor data describing the environment surrounding the vehicle 100 and, based on the received sensor data, determine whether to adjust the acceleration, power output, and / or braking of the vehicle 100. The vehicle control system 438 may also control the steering and / or other driving functions of the vehicle 100.

[0097] The vehicle control system 438 can communicate with the driving sensors and system 404 in real time, thereby forming a feedback loop. In particular, upon receiving sensor information describing target conditions in the environment surrounding the vehicle 100, the vehicle control system 438 can automatically change the driving operation of the vehicle 100. The vehicle control system 438 can then receive subsequent sensor information describing any changes to the target conditions detected in the environment due to the changed driving operation. This continuous cycle of observation (e.g., via sensors, etc.) and action (e.g., selected control or non-control of vehicle operation, etc.) allows the vehicle 100 to operate autonomously in the environment.

[0098] In some embodiments, one or more components of the vehicle 100 (e.g., driving vehicle sensors 404, vehicle control system 438, display device 472, etc.) can communicate with one or more entities 456A to 456N via a communication subsystem 450 of the vehicle 100 over a communication network 452. Figure 5 Embodiments of the communication subsystem 450 are described in greater detail. For example, the navigation sensor 408 can receive global positioning, location, and / or navigation information from a navigation source 456A. ​​In some embodiments, the navigation source 456A can be a global navigation satellite system (GNSS) similar to (if not identical to) NAVSTAR GPS, GLONASS, EU Galileo, and / or the BeiDou Navigation Satellite System (BDS), to name a few.

[0099] In some embodiments, the vehicle control system 438 can receive control information from one or more control sources 456B. The control sources 456 can provide vehicle control information, including autonomous driving control commands, vehicle operational override control commands, and the like. The control sources 456 can correspond to an automated vehicle control system, a traffic control system, an administrative control entity, and / or some other control server. One aspect of the present disclosure is that the vehicle control system 438 and / or other components of the vehicle 100 can exchange information with the control sources 456 via the communication network 452 and via the communication subsystem 450.

[0100] Information associated with controlling the driving operation of the vehicle 100 may be stored in the control data memory 464 storage medium. The control data memory 464 may store instructions, historical control information, autonomous driving control rules, etc., used by the vehicle control system 438 to control the driving operation of the vehicle 100. In some embodiments, the control data memory 464 may be a disk drive, an optical storage device, a solid-state storage device such as a random access memory ("RAM") and / or a read-only memory ("ROM"), which may be programmable, flash-updatable, etc.

[0101] In addition to the mechanical components described herein, the vehicle 100 may also include multiple user interface devices. The user interface device receives human input and converts it into mechanical motion or electrical signals or stimuli. The human input can be one or more of the following: motion (e.g., body motion, body part motion in two or three-dimensional space, etc.), voice, touch, and / or physical interaction with components of the vehicle 100. In some embodiments, the human input can be configured to control one or more functions of the vehicle 100 and / or the systems of the vehicle 100 described herein. The user interface may include, but is not limited to, at least one graphical user interface of the following: a display device, a steering wheel or steering mechanism, a gear lever or button (e.g., including a parking position, a neutral position, a reverse position, and / or a drive position, etc.), an accelerator control pedal or mechanism, a brake control pedal or mechanism, a power control switch, a communication device, etc.

[0102] Figure 5 A hardware diagram illustrating communication components that may optionally be associated with vehicle 100 according to an embodiment of the present disclosure is shown.

[0103] The communication components may include one or more wired or wireless devices, such as (one or more) transceivers and / or modems that allow communication not only between the various systems disclosed herein but also with other devices such as devices on a network and / or devices on a distributed network such as the Internet and / or in the cloud and / or with (one or more) other vehicles.

[0104] The communication subsystem 450 may also include inter-vehicle and intra-vehicle communication capabilities, such as hotspot and / or access point connections for any one or more of vehicle occupant and / or vehicle-to-vehicle communications.

[0105] In addition, although not specifically shown, the communication subsystem 450 may include one or more communication links (which may be wired or wireless) and / or communication buses (managed by the bus manager 574), including one or more of the following: CAN bus, OBD-II, ARCINC 429, Byteflight, CAN (Controller Area Network), D2B (Domestic Digital Bus), FlexRay, DC-BUS, IDB-1394, IEBus, I2C, ISO 9141-1 / -2, J1708, J1587, J1850, J1939, ISO 11783, Keyword Protocol 2000, LIN (Local Interconnect Network), MOST (Media Oriented Systems Transport), Multifunction Vehicle Bus, SMARTwireX, SPI, VAN (Vehicle Area Network), etc., or generally any communication protocol and / or standard(s).

[0106] The various protocols and communications may be communicated wirelessly and / or over one or more of a transmission medium such as single wire, twisted pair, fiber optic, IEEE 1394, MIL-STD-1553, MIL-STD-1773, power line communication, etc. (all of the above standards and protocols are incorporated herein by reference in their entirety).

[0107] As discussed, the communication subsystem 450 enables communications between any inter-vehicle systems and subsystems and with non-collocated resources (such as those reachable via a network such as the Internet).

[0108] In addition to well-known components (omitted for clarity), the communication subsystem 450 includes interconnect elements, including one or more of the following: one or more antennas 504, an interleaver / deinterleaver 508, an analog front end (AFE) 512, memory / storage / cache 516, a controller / microprocessor 520, a MAC circuitry 522, a modulator / demodulator 524, an encoder / decoder 528, a plurality of connectivity managers 534, 558, 562, 566, a GPU 540, an accelerometer 544, a multiplexer / demultiplexer 552, a transmitter 570, a receiver 572, and additional radio components such as Wi-Fi. module 580, Wi-Fi / BT MAC module 584, additional transmitter(s) 588, and additional receiver(s) 592). The various elements in device 450 are connected via one or more links / buses 5 (also not shown for clarity).

[0109] The device 450 may have one or more antennas 504 for wireless communications, such as multiple-input multiple-output (MIMO) communications, multi-user multiple-input multiple-output (MU-MIMO) communications, and multiple-user multiple-input multiple-output (MU-MIMO) communications. LTE, 4G, 5G, near field communication (NFC), etc., and is generally used for any type of wireless communication. (One or more) antennas 504 may include, but are not limited to, one or more of the following: a directional antenna, an omnidirectional antenna, a monopole antenna, a patch antenna, a loop antenna, a microstrip antenna, a dipole antenna, and any other antenna (one or more) suitable for communication transmission / reception. In an exemplary embodiment, transmission / reception using MIMO may require specific antenna spacing. In another exemplary embodiment, MIMO transmission / reception can achieve spatial diversity, thereby allowing different channel characteristics at each antenna. In yet another embodiment, MIMO transmission / reception can be used to allocate resources to multiple users, for example, within the vehicle 100 and / or in another vehicle.

[0110] The antenna(s) 504 typically interact with an analog front end (AFE) 512, which is necessary to properly process received modulated signals and perform signal conditioning on transmitted signals. The AFE 512 can be functionally located between the antenna and the digital baseband system to convert analog signals to digital signals for processing and vice versa.

[0111] Subsystem 450 may also include a controller / microprocessor 520 and a memory / storage / cache 516. Subsystem 450 may interact with memory / storage / cache 516, which may store information and operations necessary for configuration and transmitting or receiving information as described herein. Memory / storage / cache 516 may also be used in conjunction with controller / microprocessor 520 to execute application programming or instructions and for temporary or long-term storage of program instructions and / or data. By way of example, memory / storage / cache 520 may include computer-readable storage devices, RAM, ROM, DRAM, SDRAM, and / or other storage devices (one or more) and media.

[0112] The controller / microprocessor 520 may include a general-purpose programmable processor or controller for executing application programming or instructions associated with the subsystem 450. In addition, the controller / microprocessor 520 may perform operations for configuration and transmitting / receiving information, as described herein. The controller / microprocessor 520 may include multiple processor cores and / or implement multiple virtual processors. Alternatively, the controller / microprocessor 520 may include multiple physical processors. As an example, the controller / microprocessor 520 may include a specially configured application-specific integrated circuit (ASIC) or other integrated circuit, a digital signal processor (one or more), a controller, a hard-wired electronic or logic circuit, a programmable logic device or gate array, a special-purpose computer, etc.

[0113] Subsystem 450 may also include transmitter(s) 570, 588 and receiver(s) 572, 592, which may use the one or more antennas 504 and / or links / buses to transmit and receive signals to and from other devices, subsystems, and / or other destinations, respectively. Subsystem 450 circuitry includes medium access control or MAC circuitry 522. MAC circuitry 522 provides for controlling access to the wireless medium. In an exemplary embodiment, MAC circuitry 522 may be arranged to contend for the wireless medium and configure frames or packets transmitted over the wired / wireless medium.

[0114] Subsystem 450 may also optionally include a security module (not shown). This security module may contain information about, but not limited to, security parameters required to connect the device to one or more other devices or other available networks, and may include WEP or WPA / WPA-2 (optionally with AES and / or TKIP) security access keys, network keys, etc. A WEP security access key is a security password used by a Wi-Fi network. Knowing this code enables a wireless device to exchange information with an access point and / or another device. Information exchange may be performed through coded messages, where a WEP access code is typically selected by a network administrator. WPA is an additional security standard also used in conjunction with network connections, where encryption is stronger than WEP.

[0115] In some embodiments, the communication subsystem 450 further includes a GPU 540, an accelerometer 544, Wi-Fi / BT / BLE ( The GPU 540 includes a graphics processing unit (GPU) or a visual processing unit (VPU) including at least one circuit and / or chip that manipulates and modifies memory to accelerate the creation of images in a frame buffer for output to at least one display device. The GPU 540 may include one or more of the following: a display device connection port, a printed circuit board (PCB), a GPU chip, a metal oxide semiconductor field effect transistor (MOSFET), memory (e.g., single data rate random access memory (SDRAM), double data rate random access memory (DDR) RAM, etc., and / or combinations thereof), auxiliary processing chips (e.g., to handle video output capabilities, processing and / or other functions in addition to the GPU chip), capacitors, a heat sink, a temperature control or cooling fan, a motherboard connection, shielding, etc.

[0116] Various connectivity managers 534, 558, 562, 566 manage and / or coordinate communications between subsystem 450 and one or more systems disclosed herein and one or more other devices / systems. Connectivity managers 534, 558, 562, 566 include a charging connectivity manager 534, a vehicle database connectivity manager 558, a teleoperation system connectivity manager 562, and a sensor connectivity manager 566.

[0117] The charging connectivity manager 534 can not only coordinate the physical connectivity between the vehicle 100 and the charging device / vehicle, but can also communicate with one or more of a power management controller, one or more third parties, and optionally, a billing system(s). As an example, the vehicle 100 can establish communication with the charging device / vehicle to do one or more of the following: coordinate the interconnectivity between the two (e.g., by spatially aligning a charging receptacle on the vehicle with a charger on the charging vehicle), and optionally share navigation information. Once charging is complete, the amount of charge provided can be tracked and optionally forwarded to, for example, a third party for billing. In addition to being able to manage connectivity for exchanging power, the charging connectivity manager 534 can also communicate information, such as billing information, to the charging vehicle and / or third party. This billing information can include, for example, the vehicle's owner, the vehicle's driver / occupant(s), company information, or generally any information that can be used to bill the appropriate entity for the power received.

[0118] The vehicle database connectivity manager 558 allows the subsystems to receive and / or share information stored in the vehicle database. This information can be shared with other vehicle components / subsystems and / or other entities such as third parties and / or charging systems. This information can also be shared with one or more vehicle occupant devices, such as apps on a mobile device used by the driver to track information about the vehicle 100 and / or dealership or service / maintenance provider. In general, any information stored in the vehicle database can optionally be shared with any one or more other devices, optionally subject to any privacy or confidentiality constraints.

[0119] The teleoperation system connectivity manager 562 facilitates communications between the vehicle 100 and any one or more automated vehicle systems. These communications may include one or more of: navigation information, vehicle information, other vehicle information, weather information, occupant information, or generally any information related to the teleoperation of the vehicle 100.

[0120] The sensor connectivity manager 566 facilitates communication between any one or more vehicle sensors (e.g., driving vehicle sensors and systems 304, etc.) and any one or more other vehicle systems. The sensor connectivity manager 566 can also facilitate communication between any one or more sensors and / or vehicle systems and any other destination (such as a service company, an application, or generally any destination requiring sensor data).

[0121] According to an exemplary embodiment, any of the communications discussed herein can be transmitted via the conductor(s) used for charging. One exemplary protocol that can be used for these communications is power line communication (PLC). PLC is a communication protocol that uses wires to carry both data and alternating current (AC) power transmission or distribution. It is also known as power line carrier, power line digital subscriber line (PDSL), power communication, power line communication, or power line networking (PLN). For DC environments in vehicles, PLC can be used in conjunction with the CAN bus, the LIN bus over power line (DC-LIN), and the DC-BUS.

[0122] The communication subsystem may also optionally manage one or more identifiers, such as IP (Internet Protocol) addresses associated with the vehicle, and one or more of the systems or subsystems or components and / or devices therein. These identifiers may be used in conjunction with any one or more of the connectivity managers discussed herein.

[0123] Figure 6A block diagram of a computing environment 600 that can be used as a server, user computer, or other system as provided and described herein is shown. The computing environment 600 includes one or more user computers or computing devices, such as a vehicle computing device 604, a communication device 608, and / or more devices 612. These computing devices 604, 608, 612 may include general-purpose personal computers (including, by way of example only, running various versions of Microsoft Corp.'s and / or Apple Corp.'s operating systems); and / or running a variety of commercial , or a workstation computer running any of a UNIX-like operating system. The computing devices 604, 608, 612 may also have any of a variety of applications, including, for example, database client and / or server applications and web browser applications. Alternatively, the computing devices 604, 608, 612 may be any other electronic device capable of communicating via the network 452 and / or displaying and navigating web pages or other types of electronic documents or information, such as a thin client computer, an Internet-enabled mobile phone, and / or a personal digital assistant. Although an exemplary computing environment 600 is shown with two computing devices, any number of user computers or computing devices may be supported.

[0124] The computing environment 600 may also include one or more servers 614, 616. In this example, the server 614 is shown as a web server and the server 616 is shown as an application server. The web server 614 can be used to process requests for web pages or other electronic documents from the computing devices 604, 608, 612. The web server 614 can run an operating system, including any of those discussed above and any commercially available server operating system. The web server 614 can also run a variety of server applications, including SIP (Session Initiation Protocol) servers, HTTP(S) servers, FTP servers, CGI servers, database servers, Server, etc. In some cases, the network server 614 may publish the available operations as one or more network services.

[0125] The computing environment 600 may also include one or more file and / or application servers 616, which, in addition to an operating system, may include one or more applications accessible by clients running on one or more of the computing devices 604, 608, 612. The server(s) 616 and / or 614 may be one or more general-purpose computers capable of executing programs or scripts in response to the computing devices 604, 608, 612. As an example, the servers 616, 614 may execute one or more web applications. The web applications may be implemented as one or more scripts or programs written in any programming language, such as JavaScript. C. or C++, and / or any scripting language, such as Perl, Python or TCL, and any combination of programming / scripting languages. The application server(s) 616 may also include a database server, including but not limited to These data block servers, such as those commercially available, can process requests from database clients running on computing devices 604 , 608 , 612 .

[0126] Web pages created by servers 614 and / or 616 may be forwarded to computing devices 604, 608, 612 via web (file) servers 614, 616. Similarly, web server 614 may be capable of receiving web page requests, web service calls, and / or input data from computing devices 604, 608, 612 (e.g., user computers, etc.) and may forward the web page requests and / or input data to web (application) server 616. In further embodiments, server 616 may function as a file server. Although for ease of description, Figure 6 A separate network server 614 and file / application server 616 are shown, but those skilled in the art will recognize that the functions described with respect to servers 614, 616 may be performed by a single server and / or multiple dedicated servers, depending on the requirements and parameters of the specific implementation. The computer systems 604, 608, 612, the network (file) server 614 and / or the network (application) server 616 may be used as Figures 1 to 6 The system, equipment or component described in.

[0127] The computing environment 600 may also include a database 618. The database 618 may reside in a variety of locations. As an example, the database 618 may reside on a storage medium that is local to (and / or resides in) one or more of the computers 604, 608, 612, 614, 616. Alternatively, the database may be remote from any or all of the computers 604, 608, 612, 614, 616 and in communication with one or more of these computers (e.g., via the network 452). The database 618 may reside in a storage area network ("SAN") familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers 604, 608, 612, 614, 616 may be stored locally on the respective computers and / or remotely, as appropriate. The database 618 may be a relational database, such as Oracle Database 11g, suitable for storing, updating, and retrieving data in response to SQL-formatted commands.

[0128] Figure 7 One embodiment of a computer system 700 is shown on which the above-described servers, user computers, computing devices, or other systems or components may be deployed or executed. The computer system 700 is shown as including hardware elements that may be electrically coupled via a bus 704. The hardware elements may include one or more central processing units (CPUs) 708; one or more input devices 712 (e.g., a mouse, keyboard, etc.); and one or more output devices 716 (e.g., a display device, a printer, etc.). The computer system 700 may also include one or more storage devices 720. By way of example, the storage device(s) 720 may be a disk drive, an optical storage device, a solid-state storage device such as a random access memory ("RAM") and / or a read-only memory ("ROM"), which may be programmable, flash-updatable, and / or the like.

[0129] The computer system 700 may further include a computer-readable storage medium reader 724; a communication system 728 (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.); and a working memory 736, which may include the RAM and ROM devices described above. The computer system 700 may also include a processing acceleration unit 732, which may include a DSP, a special-purpose processor, and / or the like.

[0130] Computer-readable storage media reader 724 may also be connected to computer-readable storage media, which together (and optionally, in conjunction with storage device(s) 720) comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing computer-readable information. Communication system 728 may allow data to be exchanged with the network and / or any other computer described above with respect to the computer environment described herein. Furthermore, as disclosed herein, the term "storage media" may refer to one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage media, optical storage media, flash memory devices, and / or other machine-readable media for storing information.

[0131] The computer system 700 may also include software elements, shown as currently located within working memory 736, including an operating system 740 and / or other code 744. It should be understood that alternative embodiments of the computer system 700 may have many variations different from those described above. For example, custom hardware and / or specific elements that can be implemented in hardware, software (including portable software, such as applets), or both may also be used. In addition, connections to other computing devices, such as network input / output devices, may be employed.

[0132] Examples of the processors 340, 708 described herein may include, but are not limited to, at least one of the following: 800 and 801, with 4G LTE integration and 64-bit operation 620 and 615, with 64-bit architecture A7 processor, M7 motion coprocessor, series, Core TM series processors, series processors, Atom TM series processors, Intel series processors, i5-4670K and i7-4770K 22nm Haswell, i5-3570K 22nm Ivy Bridge, FX TM series processors, FX-4300, FX-6300 and FX-8450 32nm Vishera, Kaveri processor, Texas Jacinto C6000TM Automotive infotainment processors, Texas OMAP TM Automotive-grade mobile processors, Cortex TM -M processor, Cortex-A and ARM926EJ-S TM processor, other industrial equivalent processor; and may use any known or future developed standard, instruction set, library, and / or architecture to perform computing functions.

[0133] Any of the steps, functions, and operations discussed herein may be performed continuously and automatically.

[0134] The exemplary systems and methods of the present disclosure have been described with respect to the PDU router 104 and the vehicle system 101. However, to avoid unnecessarily obscuring the present disclosure, the foregoing description omits many known structures and devices. This omission should not be construed as limiting the scope of the claimed disclosure. Numerous specific details are set forth to provide an understanding of the present disclosure. However, it should be understood that the present disclosure may be practiced in a variety of ways beyond the specific details set forth herein.

[0135] Furthermore, while the exemplary embodiments described herein illustrate various components of the system in conjunction with one another, certain components of the system may be remotely located, located at a remote portion of a distributed network such as a LAN and / or the Internet, or located within a dedicated system. Therefore, it should be understood that the components of the system may be combined into one or more devices, such as servers, communication devices, or collocated at specific nodes of a distributed network, such as an analog and / or digital telecommunications network, a packet-switched network, or a circuit-switched network. It will be understood from the foregoing description, and for computational efficiency reasons, that the components of the system may be arranged at any location within a distributed component network without affecting the operation of the system.

[0136] Furthermore, it should be understood that the various links connecting the elements may be wired or wireless links or any combination thereof, or any other known or subsequently developed element(s) capable of providing and transmitting data to and from the connected elements. These wired or wireless links may also be secure links and may be capable of transmitting encrypted information. For example, the transmission medium used as the link may be any suitable carrier for electrical signals, including coaxial cable, copper wire, and optical fiber, and may take the form of sound or light waves, such as those generated during radio wave and infrared data communications.

[0137] While the flowcharts have been discussed and illustrated with respect to a particular sequence of events, it should be understood that changes, additions, and omissions to this sequence may occur without materially affecting the operation of the disclosed embodiments, configurations, and aspects.

[0138] Many variations and modifications of the disclosure may be used. Some features of the disclosure may be provided without others.

[0139] In another embodiment, the system and method of the present disclosure can be implemented in combination with a special-purpose computer, a programmed microprocessor or microcontroller and (one or more) peripheral integrated circuit components, an ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic device or logic circuit (such as a discrete element circuit), a programmable logic device or gate array (such as a PLD, PLA, FPGA, PAL), a special-purpose computer, any suitable device, etc. In general, any (one or more) devices or devices capable of implementing the methods shown herein can be used to implement the various aspects of the present disclosure. Exemplary hardware that can be used for the present disclosure includes computers, handheld devices, phones (e.g., cellular, Internet, digital, analog, hybrid, etc.), and other hardware known in the art. Some of these devices include processors (e.g., single or multiple microprocessors), memory, non-volatile storage devices, input devices, and output devices. In addition, alternative software implementations can also be constructed, including but not limited to distributed processing or component / object distributed processing, parallel processing, or virtual machine processing to implement the methods described herein.

[0140] In yet another embodiment, the disclosed method can be readily implemented in conjunction with software using an object or object-oriented software development environment that provides portable source code that can be used on a variety of computer or workstation platforms. Alternatively, the disclosed system can be implemented partially or completely in hardware using standard logic circuits or VLSI designs. Whether software or hardware is used to implement a system according to the present disclosure depends on the speed and / or efficiency requirements of the system, the specific functionality, and the specific software or hardware system or microprocessor or microcomputer system being used.

[0141] In yet another embodiment, the disclosed method may be implemented in part in software, which may be stored on a storage medium and executed on a programmed general purpose computer, a special purpose computer, a microprocessor, etc., in cooperation with a controller and memory. In these cases, the systems and methods of the present disclosure may be implemented as a program (such as an applet, or CGI scripts), resources resident on a server or computer workstation, routines embedded in a dedicated measurement system, system components, etc. The system may also be implemented by physically incorporating the system and / or method into a software and / or hardware system.

[0142] Although this disclosure describes the components and functions implemented in the embodiments with reference to specific standards and protocols, this disclosure is not limited to such standards and protocols. Other similar standards and protocols not mentioned herein exist and are considered to be included in this disclosure. Moreover, the standards and protocols mentioned herein, as well as other similar standards and protocols not mentioned herein, are regularly replaced by faster or more efficient equivalents having substantially the same functions. Such alternative standards and protocols having the same functions are considered to be equivalents included in this disclosure.

[0143] The present disclosure includes, in various embodiments, configurations, and aspects, components, methods, processes, systems, and / or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those skilled in the art will understand how to make and use the systems and methods disclosed herein after understanding the present disclosure. The present disclosure, in various embodiments, configurations, and aspects, includes providing apparatus and processes, for example, to improve performance, facilitate implementation, and / or reduce implementation costs, including in the absence of matters not depicted and / or described herein, or in its various embodiments, configurations, or aspects, including in the absence of such matters that may have been used in previous apparatus or processes.

[0144] The foregoing discussion of the present disclosure has been presented for purposes of illustration and description. The foregoing is not intended to limit the present disclosure to the form or forms disclosed herein. In, for example, the above-described detailed description, various features of the present disclosure are combined in one or more embodiments, configurations, or aspects for the purpose of streamlining the present disclosure. Features of the embodiments, configurations, or aspects of the present disclosure may be combined in alternative embodiments, configurations, or aspects other than those discussed above. This approach to the present disclosure should not be interpreted as reflecting an intention that the claimed disclosure requires more features than are expressly recited in each claim. Rather, as reflected in the appended claims, inventive aspects rely on less than all of the features of a single, foregoing disclosed embodiment, configuration, or aspect. Accordingly, the appended claims are hereby incorporated into this detailed description, with each claim relying on itself as an independent preferred embodiment of the present disclosure.

[0145] Moreover, although the description of the present disclosure has included descriptions of one or more embodiments, configurations, or aspects and certain variations and modifications, other variations, combinations, and modifications are also within the scope of the present disclosure, for example, as may be within the skill and knowledge of one skilled in the art after understanding the present disclosure. It is intended to include, to the extent permitted, alternative embodiments, configurations, or aspects, including alternative, interchangeable, and / or equivalent structures, functions, ranges, or steps to those claimed, whether or not such alternative, interchangeable, and / or equivalent structures, functions, ranges, or steps are disclosed herein, and it is not intended to publicly dedicate any patentable subject matter.

[0146] Example aspects of the present disclosure include an apparatus comprising: a processor; and a memory in electronic communication with the processor; and instructions stored in the memory that are executable by the processor to: receive a diagnostic response; identify the diagnostic request based on a comparison of a first PDU identifier associated with the diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response; and route the diagnostic response to a diagnostic client associated with the diagnostic request.

[0147] Aspects of the above-mentioned device include: wherein the instructions can also be executed by the processor to perform the following operations: identify a routing path between a diagnostic target and a diagnostic client based on a first PDU identifier and a second PDU identifier, wherein the routing path is associated with a diagnostic request, wherein routing the diagnostic response to the diagnostic client may include transmitting the diagnostic response to the diagnostic client based on the routing path.

[0148] Aspects of the above apparatus include: wherein the routing path overlaps with at least a portion of a second routing path between the diagnosis target and the second diagnosis client.

[0149] Aspects of the above-mentioned apparatus include: wherein, the routing path may include a set of electrical interconnections between the diagnostic target and the diagnostic client; the second routing path may include a second set of electrical interconnections between the diagnostic target and the second diagnostic client; and the set of electrical interconnections at least partially overlaps with the second set of electrical interconnections.

[0150] Aspects of the above-mentioned device include: wherein the instructions can also be executed by the processor to perform the following operations: generate a set of PDU identifiers, which set of PDU identifiers includes a first PDU identifier and a second PDU identifier, wherein: each PDU identifier in the set of PDU identifiers corresponds to a previous diagnostic request in a set of previous diagnostic requests and a candidate diagnostic client in a set of candidate diagnostic clients; the set of previous diagnostic requests may include a diagnostic request; and the set of candidate diagnostic clients may include a diagnostic client.

[0151] Aspects of the above apparatus include: wherein each PDU identifier is associated with a routing path between the diagnosis target and one of the set of candidate diagnosis clients.

[0152] Aspects of the above-mentioned apparatus include: wherein the instructions can also be executed by the processor to perform the following operations: receiving a diagnostic request from a diagnostic client; and routing the diagnostic request to a diagnostic target, wherein the diagnostic request may include a request for a diagnostic response, wherein the diagnostic response is generated at the diagnostic target based on the diagnostic request.

[0153] Aspects of the above apparatus include: wherein the instructions are further executable by the processor to perform the following operations: receiving a diagnostic request from a diagnostic client; and routing the diagnostic request to a diagnostic target, wherein the diagnostic request is a latest diagnostic request among a set of previous diagnostic requests.

[0154] Aspects of the above-mentioned apparatus include: wherein the diagnostic client may include at least one of the following: a first client device, which is coupled to the diagnostic target via a first communication bus; a second client device, which is coupled to the diagnostic target via a second communication bus, wherein the first communication bus and the second communication bus are of the first communication protocol type; a third client device, which is coupled to the diagnostic target via a third communication bus, wherein the third communication bus is of the second communication protocol type; and a fourth client device, which is coupled to the diagnostic target via a fourth communication bus and a relay device, wherein the fourth communication bus and the relay device are of the first communication protocol type.

[0155] Aspects of the above apparatus include: wherein the first communication protocol type may include a CAN protocol; and the second communication protocol type may include DoIP.

[0156] Aspects of the above apparatus include: wherein the diagnostic target may include at least one of the following: a diagnostic server; a CAN ECU; a LIN ECU; and a local UDS server.

[0157] Example aspects of the present disclosure include a system comprising: a communication bus; a processor; and a memory in electronic communication with the processor; and instructions stored in the memory that are executable by the processor to perform the following operations: receive a diagnostic response; identify the diagnostic request based on a comparison of a first PDU identifier associated with the diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response; and route the diagnostic response to a diagnostic client associated with the diagnostic request.

[0158] Aspects of the above-mentioned system include: wherein the instructions can also be executed by the processor to perform the following operations: identify a routing path between a diagnostic target and a diagnostic client based on a first PDU identifier and a second PDU identifier, wherein the routing path is associated with a diagnostic request, wherein routing the diagnostic response to the diagnostic client may include transmitting the diagnostic response to the diagnostic client based on the routing path.

[0159] Aspects of the above system include: wherein the routing path overlaps with at least a portion of a second routing path between the diagnostic target and the second diagnostic client.

[0160] Aspects of the above-described system include: wherein, a routing path may include a set of electrical interconnections between a diagnostic target and a diagnostic client; a second routing path may include a second set of electrical interconnections between the diagnostic target and a second diagnostic client; and the set of electrical interconnections at least partially overlaps with the second set of electrical interconnections.

[0161] Aspects of the above-mentioned system include: wherein the instructions can also be executed by the processor to perform the following operations: generate a set of PDU identifiers, which set of PDU identifiers includes a first PDU identifier and a second PDU identifier, wherein: each PDU identifier in the set of PDU identifiers corresponds to a previous diagnostic request in a set of previous diagnostic requests and a candidate diagnostic client in a set of candidate diagnostic clients; the set of previous diagnostic requests may include a diagnostic request; and the set of candidate diagnostic clients may include a diagnostic client.

[0162] Aspects of the above system include: wherein each PDU identifier is associated with a routing path between the diagnosis target and one of the set of candidate diagnosis clients.

[0163] An example aspect of the present disclosure includes a method comprising: receiving a diagnostic response at a PDU routing engine; identifying, by the PDU routing engine, the diagnostic request based on a comparison of a first PDU identifier associated with a diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response; and routing, by the PDU routing engine, the diagnostic response to a diagnostic client associated with the diagnostic request.

[0164] Aspects of the above method include: identifying a routing path between a diagnostic target and a diagnostic client based on a first PDU identifier and a second PDU identifier, wherein the routing path is associated with a diagnostic request, wherein routing the diagnostic response to the diagnostic client may include transmitting the diagnostic response to the diagnostic client based on the routing path.

[0165] Aspects of the above method include: wherein the routing path overlaps with at least a portion of a second routing path between the diagnostic target and the second diagnostic client.

[0166] The phrases "at least one," "one or more," "or," and "and / or" are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," "A, B and / or C," and "A, B, or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together.

[0167] The term "a" or "an" entity refers to one or more of that entity. Thus, the terms "a" (or "an"), "one or more," and "at least one" are used interchangeably herein. It should also be noted that the terms "including," "comprising," and "having" are used interchangeably.

[0168] As used herein, the term "automatic" and its variations refer to any process or operation that is performed without significant human input, typically on a continuous or semi-continuous basis, when the process or operation is performed. However, a process or operation may be automatic if input is received prior to the execution of the process or operation, even if the execution of the process or operation utilizes significant or insignificant human input. Human input is considered significant if it affects the manner in which the process or operation is performed. Human input that consents to the execution of the process or operation is not considered "significant."

[0169] Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may generally be referred to herein as a "circuit," "module," or "system." Any combination of one or more computer-readable medium(s) may be used. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium.

[0170] A computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media would include the following: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0171] A computer-readable signal medium may include a propagated data signal in which a computer-readable program code is embedded, for example, in baseband or as part of a carrier wave. Such propagated signals may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium that is not a computer-readable storage medium and that can convey, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code embedded on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or the like, or any suitable combination thereof.

[0172] As used herein, the terms "determine," "calculate," "infer," and variations thereof are used interchangeably and include any type of methodology, process, mathematical operation, or technique.

Claims

1. An apparatus for routing multiple diagnostic pathways, comprising: processor; as well as a memory in electronic communication with the processor; as well as Instructions stored in the memory, the instructions being executable by the processor to: receiving a diagnostic response; identifying the diagnostic request based at least in part on a comparison of a first protocol data unit (PDU) identifier associated with the diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response; as well as The diagnostic response is routed to a diagnostic client associated with the diagnostic request.

2. The apparatus for routing multiple diagnostic pathways according to claim 1, wherein: The instructions are further executable by the processor to: identifying a routing path between a diagnostic target and the diagnostic client based at least in part on the first PDU identifier and the second PDU identifier, wherein the routing path is associated with the diagnostic request, Wherein, routing the diagnostic response to the diagnostic client includes transmitting the diagnostic response to the diagnostic client based at least in part on the routing path.

3. The apparatus for routing multiple diagnostic pathways according to claim 2, wherein: The routing path overlaps with at least a portion of a second routing path between the diagnosis target and a second diagnosis client.

4. The apparatus for routing multiple diagnostic pathways of claim 3, wherein: The routing path includes a set of electrical interconnections between the diagnostic target and the diagnostic client; the second routing path comprises a second set of electrical interconnections between the diagnostic target and the second diagnostic client; and The set of electrical interconnects at least partially overlaps the second set of electrical interconnects.

5. The apparatus for routing multiple diagnostic pathways according to claim 1, wherein: The instructions are further executable by the processor to: Generate a set of PDU identifiers, the set of PDU identifiers including the first PDU identifier and the second PDU identifier, wherein: Each PDU identifier in the set of PDU identifiers corresponds to a previous diagnostic request in a set of previous diagnostic requests and a candidate diagnostic client in a set of candidate diagnostic clients; the set of previous diagnostic requests including the diagnostic request; and The set of candidate diagnostic clients includes the diagnostic client.

6. The apparatus for routing multiple diagnostic pathways according to claim 5, wherein: Each PDU identifier is associated with a routing path between a diagnosis target and one of the set of candidate diagnosis clients.

7. The apparatus for routing multiple diagnostic pathways according to claim 1, wherein: The instructions are further executable by the processor to: receiving the diagnostic request from the diagnostic client; and routing the diagnostic request to a diagnostic target, wherein the diagnostic request includes a request for the diagnostic response, The diagnostic response is generated at the diagnostic target based at least in part on the diagnostic request.

8. The apparatus for routing multiple diagnostic pathways of claim 1, wherein: The instructions are further executable by the processor to: receiving the diagnostic request from the diagnostic client; and The diagnostic request is routed to a diagnostic target, wherein the diagnostic request is a most recent diagnostic request among a set of previous diagnostic requests.

9. The apparatus for routing multiple diagnostic pathways of claim 1, wherein: The diagnostic client includes at least one of the following: a first client device coupled to a diagnostic target via a first communication bus; a second client device coupled to the diagnostic target via a second communication bus, wherein the first communication bus and the second communication bus are of a first communication protocol type; a third client device coupled to the diagnostic target via a third communication bus, wherein the third communication bus is of a second communication protocol type; and A fourth client device is coupled to the diagnostic target via a fourth communication bus and a relay device, wherein the fourth communication bus and the relay device are of the first communication protocol type.

10. The apparatus for routing multiple diagnostic pathways of claim 9, wherein: The first communication protocol type includes the CAN protocol; and The second communication protocol type includes Diagnostics over Internet Protocol (DoIP).

11. The apparatus for routing multiple diagnostic pathways according to claim 1, wherein: Diagnostic objectives include at least one of the following: Diagnostic server; CAN electronic control unit (ECU); Local Interconnect Network (LIN) ECUs; and Local Unified Diagnostic Service (UDS) server.

12. A method for routing multiple diagnostic pathways, comprising: receiving a diagnostic response at a protocol data unit (PDU) routing engine; identifying, by the PDU routing engine, the diagnostic request based at least in part on a comparison of a first PDU identifier associated with the diagnostic request corresponding to the diagnostic response and a second PDU identifier associated with the diagnostic response; as well as The diagnostic response is routed by the PDU routing engine to a diagnostic client associated with the diagnostic request.

13. The method for routing multiple diagnostic pathways of claim 12, further comprising: identifying a routing path between a diagnostic target and the diagnostic client based at least in part on the first PDU identifier and the second PDU identifier, wherein the routing path is associated with the diagnostic request, Wherein, routing the diagnostic response to the diagnostic client includes transmitting the diagnostic response to the diagnostic client based at least in part on the routing path.

14. The method for routing multiple diagnostic pathways of claim 13, wherein: The routing path overlaps with at least a portion of a second routing path between the diagnosis target and a second diagnosis client.

Images