Electrical Architecture for Service-Oriented Vehicle Diagnosis

Abstract

A method for providing diagnostic communications in a diagnostic electrical architecture of a vehicle, the vehicle including a plurality of on-board computing devices for hosting the diagnostic electrical architecture. The diagnostic electrical architecture includes one or more electronic control units, each including a diagnostic server module, a service interface module configured to enable diagnostic communications between the one or more electronic control units and a network service bus of the vehicle, and a diagnostic service registry module. The method includes: executing a diagnostic task by the diagnostic server module to generate diagnostic object data; receiving the generated diagnostic object data into the service interface module; retrieving diagnostic service data from the diagnostic service registry module, the diagnostic service data including a diagnostic capability description of the generated diagnostic object data; and sending a diagnostic service notification over the network service bus, the diagnostic service notification being based on the generated diagnostic object data and the diagnostic service data.

Description

Technical Field

[0001] The present disclosure relates to a diagnostic electrical architecture for a vehicle, and more particularly, to a diagnostic electrical architecture hosted on a plurality of vehicle on-board computing devices. Aspects of the present invention relate to an electrical architecture, method, computer-readable medium, and vehicle for vehicle diagnostics.

Background Art

[0002] Modern vehicles, such as road vehicles like automobiles, include several embedded electronic control units, components or modules (ECUs) for controlling and executing many functions of the vehicle. Examples of such ECUs can include an anti-lock braking system (ABS), a powertrain control module (PCM), a transmission control module (TCM), an instrument panel cluster (IPC), an ADAS domain controller (ADC), an engine control system (EMS), an air conditioning module (ACM), and the like. Generally, each vehicle ECU is connected to a plurality of sensors of the vehicle and receives sensor data from the sensors as inputs together with signals from other parts of the vehicle.

[0003] The electronic components or software of the ECU, or the sensors connected to the ECU, may malfunction or experience failures. Many ECUs include a local diagnostic server with self-diagnostic capabilities and can identify and report faults and perhaps perform self-repair of the faults.

[0004] Currently, vehicle diagnostic tests include a diagnostic tester that can be on-board or off-board the vehicle, and establish point-to-point (p2p) diagnostic communication between the diagnostic tester and the local diagnostic server of any ECU of the vehicle. In particular, such diagnostic communication is performed via a single central gateway that functions as a router for diagnostic messages to a specific local diagnostic server, particularly for routing diagnostic messages between different transport protocols.

Summary of the Invention

Problems to be Solved by the Invention

[0005] There are many potential disadvantages or drawbacks associated with the current vehicle diagnostic architecture described above. These include, but are not limited to, a static diagnostic configuration, lack of diagnostic redundancy, limitations to component-based diagnosis, diagnostic access restricted to one tester at a time, and logical and physical separation between an external tester and vehicle modules leading to security risks. The object of the present invention is to address one or more of the disadvantages associated with the prior art.

Means for Solving the Problems

[0006] According to an aspect of the present invention, a diagnostic electrical architecture for a vehicle such as an automobile or other road vehicle is provided. The vehicle comprises a plurality of on-board computing devices for hosting the diagnostic electrical architecture. The diagnostic electrical architecture includes one or more electronic control units each including a diagnostic server module configured to execute diagnostic tasks to generate diagnostic object data. The architecture includes a service interface module configured to enable diagnostic communication between the one or more electronic control units and a vehicle network service bus. The service interface module is configured to receive the generated diagnostic object data. The architecture includes a diagnostic service registry module configured to store diagnostic service data indicative of the diagnostic services provided by the service interface module. The diagnostic service data includes a diagnostic function description of the generated diagnostic object data. The service interface module is configured to transmit a diagnostic service notification via the network service bus. The diagnostic service notification is based on the generated diagnostic object data and the diagnostic service data obtained from the diagnostic service registry.

[0007] The diagnostic service notification may be generated in response to a change in the diagnostic function provided by the service interface module.

[0008] Changes in the diagnostic function can be caused by the addition or deletion of diagnostic tasks executed by one or more control units.

[0009] Changes in the diagnostic function can be caused by the addition or deletion of electronic control units associated with the service interface module.

[0010] Diagnostic service notifications can be generated in response to requests for diagnostic functions received by the service interface module.

[0011] Requests for diagnostic functions can be received from an off-board diagnostic tester of the vehicle.

[0012] The generated service notifications can be transmitted off-board the vehicle.

[0013] The generated diagnostic function notifications can be used to update the diagnostic register module.

[0014] The service interface module can be deployed in the communication middleware in one or more of the on-board computing devices.

[0015] The communication middleware can be one of SOME / IP (Scalable service-oriented middleware over IP); REST (Representational state transfer); and DDS (Data Distribution Service).

[0016] The vehicle service bus can include an Ethernet backbone network.

[0017] The service interface module can be directly connected to the Ethernet backbone network.

[0018] The stored diagnostic service data may include an Open Diagnostic Exchange (ODX) file for interpreting diagnostic object data.

[0019] The diagnostic service registry module may be configured to allow on - board and off - board modules of a vehicle to subscribe to diagnostic services provided by a service interface module so as to dynamically learn them.

[0020] The diagnostic electrical architecture may be configured to provide a conversion between Unified Diagnostics Services (UDS) protocol communication and service - oriented diagnostic communication.

[0021] The diagnostic electrical architecture may be a hierarchical architecture having a component diagnostic layer and at least one monitoring diagnostic layer. The component diagnostic layer includes one or more electronic units.

[0022] At least one monitoring diagnostic layer may include a service interface module.

[0023] At least one monitoring diagnostic layer may include a diagnostic service registry module.

[0024] At least one monitoring diagnostic layer may include a system diagnostic layer and a vehicle diagnostic layer in a layer of architecture higher than the system diagnostic layer. The vehicle diagnostic layer may include a service interface module. The system diagnostic layer may include an application service module, and the application service module includes a local diagnostic agent configured to aggregate generated diagnostic service notifications received from an electronic control unit to generate monitoring - level diagnostic service notifications.

[0025] The monitoring - level diagnostic service notifications may be used to update the diagnostic service registry module.

[0026] The service interface module can be hosted on a vehicle's zone input / output computing device or the vehicle's central computing platform.

[0027] According to another aspect of the present invention, a vehicle such as an automobile or other road vehicle is provided, which includes a network architecture having a plurality of computing devices and hosting the diagnostic electrical architecture described above.

[0028] According to another aspect of the present invention, a method for providing diagnostic communication in a diagnostic electrical architecture of a vehicle such as an automobile or other road vehicle is provided. The vehicle includes a plurality of on-board computing devices for hosting the diagnostic electrical architecture. The diagnostic electrical architecture includes one or more electronic control units each including a diagnostic server module, a service interface module configured to enable diagnostic communication between the one or more electronic control units and the vehicle's network service bus, and a diagnostic service registry module. The method includes executing a diagnostic task by the diagnostic server module to generate diagnostic object data, and receiving the generated diagnostic object data into the service interface module. The method includes obtaining diagnostic service data from the diagnostic service registry module, wherein the diagnostic service data includes a diagnostic function description of the generated diagnostic object data. The method includes transmitting a diagnostic service notification via the network service bus, wherein the diagnostic service notification is based on the generated diagnostic object data and the diagnostic service data.

[0029] According to another aspect of the present invention, a non-transitory computer-readable storage medium is provided, which stores instructions for causing one or more processors to execute the method described above when executed by the one or more processors.

[0030] Within the scope of this application, it is clearly contemplated that the various aspects, embodiments, examples, and alternatives described in the preceding paragraphs, claims, and / or the following description and drawings, particularly their individual features, may be employed independently or in any combination. That is, all embodiments and / or features of any embodiment may be combined in any manner and / or combination, except where such features are incompatible. The applicant reserves the right to amend any of the claims initially filed or to file any new claims accordingly. This includes the right to correct any of the claims initially filed to be dependent on any other claim and / or incorporate the features of any other claim, even if not initially claimed in that manner.

[0031] Next, one or more embodiments of the present invention will be described with reference to the accompanying drawings for illustrative purposes only.

Brief Description of the Drawings

[0032]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

[0033] Detailed Description FIG. 1 shows a point-to-point (p2p) diagnostic electrical architecture 10 for a vehicle. The vehicle diagnostic architecture 10 has a flat non-hierarchical structure 10, or a plurality of electronic control units, components or modules (ECUs) 101 logically arranged in a component-level diagnostic architecture 10. Each ECU 101 performs a separate function and may include an anti-lock braking system module (ABS), a powertrain control module (PCM), a transmission control module (TCM), an instrument panel cluster (IPC), an ADAS domain controller (ADC), an engine control system (EMS), and / or an air conditioning module (ACM). It is understood that the vehicle diagnostic architecture 10 may include any number of suitable ECUs. Generally, a vehicle may include 40 to 60 ECUs.

[0034] Each ECU101 of the diagnostic architecture 10 can communicate with an on-board or off-board diagnostic tester 11 of the vehicle. In fact, the diagnostic tester 11 can directly establish a diagnostic communication path with any of the on-board ECUs101. Therefore, the diagnostic tester 11 can initiate diagnostic communication and execute various diagnostic tasks such as the initiation of the on-demand self-test (ODST) of any of the ECUs101 so that faults related to the ECU are reported to the tester 11. In particular, the diagnostic communication between each ECU101 and the diagnostic tester 11 is performed using the gateway module (GWM) 12. The diagnostic tester 11 can be any suitable vehicle diagnostic tester, for example, an engineering, manufacturing or service tester, a connected diagnostic tester, or an on-board diagnostic or software over-the-air (SOTA) tester. In fact, a vehicle generally has a number of different diagnostic testers that communicate with the on-board ECUs.

[0035] Each ECU101 of the diagnostic electrical architecture 10 has a local diagnostic server or module 102. Each diagnostic server 102 is configured to perform self-diagnostic operations related to its respective ECU101, including the identification, reporting, and / or repair of faults or malfunctions of the components or software of the ECU101 or the sensors associated with the ECU101. The diagnostic server 102 then reports any identified faults or errors to the diagnostic tester 11 and notifies the diagnostic tester 11 of any self-repair operations performed.

[0036] The ECU 101 of the diagnostic architecture 10 is part of different networks present in the vehicle, such as CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay, and Ethernet. Each of these networks has different protocols and data transmission speeds. For example, LIN is used for low-speed networks such as sensors and actuators with a data speed of about 20 kbps, CAN can be used for communication between different ECUs with a data speed of about 1 - 5 Mbps, FlexRay can be used for applications where safety is important with a data speed of about 10 Mbps, and Ethernet can be used for infotainment systems, advanced driver assistance systems (ADAS), and wireless interfaces such as 4G, Wi-Fi, etc. in the range of megabits per second to gigabits per second data speed.

[0037] GWM 12 provides a single entry point from a logical perspective for communication between the diagnostic tester 11 and the component-level diagnostic architecture 10 having the ECU 101. GWM 12 functions as a router for diagnostic messages from one network to another, for example, from an Ethernet frame to a CAN bus frame and vice versa. In particular, GWM 12 bridges between the external or off-board network of the diagnostic tester 11 and the internal or on-board network of the vehicle ECU 101.

[0038] The diagnostic protocol used between the diagnostic tester 11 and the ECU 101 is the Unified Diagnostics Services (UDS) protocol defined in ISO standard 14229-1. In particular, the UDS protocol for diagnostic communication for various different underlying network technologies is addressed and specified in various ISO standards. ISO 14229-3 specifies UDS on CAN. ISO 14229-4 specifies UDS on FlexRay. Also, ISO 14229-5 specifies UDS on the Internet protocol. The UDS protocol continues to be used for the purpose of diagnostic communication regardless of the underlying network technology used in the vehicle electrical architecture. This can limit the diagnostic functions that can be performed while also limiting the scalability and / or flexibility of the entire diagnostic electrical architecture.

[0039] The standardized diagnostic transport protocol DoIP (diagnostic communication via the Internet protocol) is used in combination with the UDS protocol to package diagnostic messages into Ethernet frames for communication between the diagnostic tester 11 and the vehicle ECU 101. Therefore, the GWM 12 routes the DoIP Ethernet frames from the diagnostic tester 11 to the relevant transport protocol for the specific ECU 101 to which the diagnostic message is to be sent, such as CAN, LIN, FlexRay frames, etc. That is, the diagnostic tester 11 establishes p2p diagnostic communication with the individual ECUs 101 in the vehicle architecture, i.e., the component-level diagnostic architecture 10, via the DoIP gateway module 12, and the UDS is used as the protocol for diagnostic communication across the entire diagnostic electrical architecture 10.

[0040] A single failure or malfunction in a vehicle can cause failures across several ECUs 101. Each ECU 101 detects and reports failures related to or associated with that particular ECU 101 and reports them to the diagnostic tester 11. This means that the diagnostic tester 11 can receive multiple, fault codes, also called diagnostic trouble codes (DTCs), from multiple different ECUs 101. The diagnostic tester 11, or an engineer or service technician, then has to analyze and interpret the received DTCs to determine the root cause of the multiple DTCs and thus the correct diagnostic repair that needs to be carried out.

[0041] Although many different diagnostic testers can access the ECU 101, only a single diagnostic tester can establish diagnostic communication with the component-level diagnostic architecture 10 at any time. Therefore, the relative levels of priority between different diagnostic testers can be set in the GWM 12. For example, a third-party off-board tester such as an OBD scan tool or insurance dongle can be assigned the highest priority, the manufacturer's off-board tester can be assigned the next highest priority, and the on-board SOTA can be assigned the lowest priority.

[0042] The present invention provides a vehicle diagnostic electrical architecture in which a vehicle's diagnostic function, in particular the vehicle's ECUs, provides diagnostic services via the vehicle's network service bus to, for example, an off-board diagnostic tester of the vehicle and / or other on-board modules of the vehicle. This is in contrast to the signal-directed p2p diagnostic communication of the diagnostic electrical architecture 10 of FIG. 1. For example, the individual ECUs of the electrical architecture of FIG. 1 can respond to the diagnostic tester with signals having live diagnostic object data regarding the executed diagnostic tests (in this case the live data has to be interpreted off-board of the vehicle). In contrast, in the present invention, the ECU can respond to the diagnostic tester with data or values that have been interpreted or evaluated regarding the executed diagnostic tests. This is detailed below.

[0043] Figure 2 shows another diagnostic electrical architecture 20 for a vehicle. Unlike FIG. 1, in FIG. 2, the architecture 20 is a hierarchical diagnostic architecture 20 for the vehicle. This may also be referred to as a hierarchical diagnostic architecture 20. Unlike the non-hierarchical architecture 10 of FIG. 1, the hierarchical architecture 20 includes several diagnostic layers 21, 22, 23. Similar to the non-hierarchical architecture 10 of FIG. 1, the hierarchical architecture 20 has a component diagnostic layer 21 that includes several ECUs 211 for performing different functions on the vehicle respectively.

[0044] Each of the ECUs 211 of the hierarchical diagnostic architecture 20 has a local diagnostic server or module 212. Each diagnostic server 212 provides a function of reading the fault record data associated with the related ECU 211 and starting an ECU self-test. The ECU self-test determines whether all the inputs and outputs to the ECU are connected, configured, and functioning as specified, and whether the components or software of the ECU, as well as the sensors connected to the ECU, are functioning correctly. In addition to these "pull" mechanisms for obtaining fault data from the ECU 211, the ECU 211 can "push" or transmit the fault data to a higher level or layer 22, 23 of the hierarchical diagnostic architecture 20, for example, when a fault is detected or when a predefined event or trigger occurs.

[0045] Unlike the non - hierarchical architecture 10 of FIG. 1, the hierarchical architecture 20 also includes two monitoring diagnostic layers 22, 23 across or between the on - board or off - board component diagnostic layer 21 and the diagnostic tester 24 of a vehicle configured to perform diagnostic communication with the hierarchical diagnostic architecture 20. The provision of such monitoring layers 22, 23 enables diagnostic monitoring and reporting to be performed at a higher level than the component - level diagnosis provided by the ECU 211 in the component diagnostic layer 21. The diagnosis performed in the component diagnostic layer 21 is limited to the determination and reporting of faults related to a specific ECU separated from other ECUs, while the monitoring layers have an overview of several different ECUs 211 in the lower layer 21. Therefore, the diagnosis performed in the monitoring layers can integrate fault data from a number of different ECUs 211, more generally fault data from the lower layers, and provide a clearer diagnostic overview of the vehicle system.

[0046] In the example described, the hierarchical diagnostic architecture 20 includes a system diagnostic layer 22 on the component diagnostic layer 21 and a vehicle diagnostic layer 23 on the system diagnostic layer 22, and is configured to perform diagnostic communication with the diagnostic tester 24. In the system diagnostic layer 22, fault data from multiple ECUs 211 is analyzed and analyzed and interpreted for each of several application services. Each application service requires a specific function provided by a particular individual component or ECU 211. As an example, vehicle speed can be provided or given as an application service of the vehicle. To determine the vehicle speed, wheel speed sensor signals are required to be provided by each of the four wheel speed sensors of the vehicle.

[0047] Next, the diagnosis can be performed at a "service level" for each of the different application services provided based on the fault data from the associated ECU. In particular, the system diagnosis layer 22 includes several application service interface modules 221, and each module 221 is connected to several ECUs 211 in the component diagnosis layer 21. Note that a given ECU 211 can provide fault data to several different application service modules 221 by means of a hierarchical architecture. The diagnosis notification can then be sent from the application service module 221 to a higher layer of the architecture 20, in this case the vehicle diagnosis layer 23. The system diagnosis layer 22 also includes a local database or register 222 that can be used to store fault data or other notifications from the ECUs 211 in the component diagnosis layer 21.

[0048] In the vehicle diagnosis layer 23, the fault data from the plurality of application service modules 221 is analyzed and interpreted for each of several customer-oriented vehicle functions. These user functions can be regarded as vehicle functions available to assist the user in driving the vehicle, or other vehicle functions for providing entertainment, comfort, etc. to the vehicle user. Such vehicle functions can include, for example, a turn indicator function or a lane change assistance function.

[0049] Next, the diagnosis can be performed at a "vehicle level" or "vehicle function level" for each of the different vehicle user functions provided based on the fault data from the associated application service module 221. In particular, the vehicle diagnosis layer 23 includes a platform diagnosis service module 231 connected to the application service module 221 in the system diagnosis layer 22. Next, the diagnosis notification can be sent from the platform diagnosis service module 231 to either an on-board or off-board diagnostic tester 24 of the vehicle. The vehicle diagnosis layer 23 also includes a central database or register 232, which can be used to store fault data or other notifications from the application service module 221 in the system diagnosis layer 22. The central database 232 also includes a current list of the application services provided by the vehicle, and this list can be added to or modified over time.

[0050] Figure 3 shows one of the application service modules 221 from Figure 2 in more detail. In particular, each of the application service modules 221 includes a local diagnostic agent 2211 that is similar in some respects to the diagnostic server 212 of the ECU. In particular, the local diagnostic agent 2211 is integral with the associated application service module 221 and has direct access to all inputs and outputs to and from the module 221, as well as direct access to the internal state of the application service module 221. That is, the local diagnostic agent 2211 is connected to the respective interfaces of the input 2212, output 2213, and internal state 2214 of the module 221. In the example of Figure 2, the local diagnostic agent 2211 can then perform a diagnosis at the "service level" of the hierarchical network architecture 20 based on the accessed data (which can include, for example, fault data received from some of the ECUs 211).

[0051] Figure 4 shows a vehicle network architecture 40 that includes several connected computing devices disposed in a vehicle. The network architecture 40 includes a central computing platform (CCP) 41. The CCP 41 is connected to several other computing platforms in the form of domain controllers or zone computing platforms (CP), or remote input / output (RIO) modules 43 via an Ethernet data backbone 42. Each of these CPs and RIO 43 is further connected to several ECUs 211 via a conventional network 44 such as CAN, FlexRay, or LIN.

[0052] The computing devices can be provided by suitable software executed on any suitable computing substrate using conventional or customer processors and memories. Some of the computing devices can use a common computing substrate (e.g., they can be executed on the same server) or individual substrates. Alternatively, one or some of the computing devices can themselves be distributed among multiple computing devices.

[0053] In the example described illustratively, the CCP 41 is connected to four CPs and RIOs 43, specifically three RIO modules 431, 432, 434 and an ADC (ADAS domain controller) 433 along the Ethernet backbone network. In the case of architecture 20, the first RIO 431 is connected to three ECUs 211, specifically an ABS module 2111, a PCM 2112 and a TCM 2113 along the conventional network 44. The ABS module 2111 is further connected to four wheel speed sensors 45 for each of the four wheels of the vehicle. The second RIO 432 is connected to an IPC 2114 and several other peripheral modules or ECUs 2115 along the conventional network 44. The nth one of the RIOs 434 is also connected to several peripheral modules 2116, 2117, 2118 along the conventional network 44.

[0054] The different diagnostic layers 21, 22, 23 of the hierarchical diagnostic architecture 20 in FIG. 2 are hosted on different computer devices or modules of the vehicle network architecture 40. In particular, as shown in FIG. 4, the vehicle diagnostic layer 23 is hosted on the CCP41, the system diagnostic layer 22 is hosted on the CP / RIO43 and / or the CCP41, and the component diagnostic layer 21 is hosted on the ECU211 and / or the CP / RIO43.

[0055] Unlike the "signal-oriented" diagnosis of the architecture 10 in FIG. 1, the "service-oriented" diagnosis of the architecture 20 in FIG. 2 does not use UDS as the protocol for diagnostic communication across the entire diagnostic architecture 20. None of the diagnostic testers 24 that establish diagnostic communication with the vehicle directly support the service-oriented diagnostic interface. Alternatively, the platform diagnostic service module 231 performs the conversion from UDS (between the tester 24 and the platform diagnostic service module 231) to service-oriented diagnostic communication (between the platform diagnostic service module 231 and the rest of the vehicle architecture 20) and vice versa.

[0056] Application services via the application service module 221 are provided by various ones of the RIOs 43 connected via the Ethernet data backbone 42. These application services are available to or subscribed to by the vehicle tester 24 or other components / modules via the network service bus 42. Note that modules not directly connected to the Ethernet backbone network 42 cannot provide diagnostic services. In the example of FIG. 2, the application service module 221 is part of the service layer 22, which is hosted on the CCP 41 and / or the RIO 42. Since the CCP 41 and / or the RIO 42 are directly connected to the Ethernet backbone 42 as shown in FIG. 4, in this case, the application service module 221 is always directly connected to the Ethernet backbone 42. If a (peripheral) module / ECU is not directly connected to the Ethernet backbone and thus cannot provide diagnostic services, it may expose an equivalent network signal interface for diagnostic services via one of the conventional sub-networks, such as CAN, LIN, FlexRay. The diagnostic signal manager module hosted on the RIO 43 manages the mapping between diagnostic signals from the ECU and, for example, diagnostic services provided to the tester. That is, the diagnostic signal manager functions as a local gateway between the Ethernet data backbone and the individual sub-networks of the CAN / LIN / FlexRay network.

[0057] With reference to FIG. 4, an example is described to emphasize the advantages of the service-oriented diagnostic architecture by the local diagnostic agent. In particular, in this example, the vehicle speed is provided as a service from each of the four wheel speed sensors, i.e., one wheel speed signal for each wheel of the vehicle.

[0058] The ABS module 2111 receives wheel speeds from four wheel speed sensors 45 connected to the ABS 2111 via a conventional network 44. The RIO#1 module 431 directly connected to the Ethernet backbone 42 calculates the vehicle speed from the wheel speed signals received from the ABS module 2111 via the conventional network 44. Then, the RIO#1 module 431 provides the vehicle speed as a service to the modules related to the service-oriented architecture, and the quality of service is added to the service interface. Then, the RIO#1 module 431 sends back the calculated vehicle speed signal via the conventional network 44 connected to the RIO#1 module 431.

[0059] Other modules directly connected to the Ethernet backbone network 42 can then subscribe to the vehicle speed service provided in the RIO#1 module 431. For example, the RIO#2 module 432 subscribes to the vehicle speed service and uses it as an input for the application / service hosted on the module 432. In addition, the RIO#2 module 432 provides the reverse conversion from service-oriented communication to signal-oriented communication and transmits the acquired vehicle speed signal via the conventional network 44 connected to the RIO#2 module 432. Also, the ADC module 433 subscribes to the vehicle speed service from the Ethernet service bus 42 and uses it for its own application / service.

[0060] The PCM 2112 and the TCM 2113 are connected to the RIO#1 module 431 via a conventional network 44, so these modules 2112, 2113 receive the vehicle speed signal transmitted by the RIO#1 module 431 and distribute their own functions. Similarly, the IPC module 2114 is connected to the RIO#2 module 432 via a conventional network 44, so the IPC module 2114 receives the vehicle speed signal transmitted by the RIO#2 module 432 and distributes its own functions.

[0061] Regarding diagnostics, faults or malfunctions related to wheel speed sensors or signals can be reported at a service level, which can then advantageously provide an interpreted view of the fault, rather than the raw diagnostic trouble codes (DTCs) that require off-board analysis of the vehicle to find the root cause of the fault.

[0062] For example, if the first of the wheel speed sensors 45 develops a fault, this is detected by the diagnostic server in the ABS module 2111, which generates a DTC, such as a short circuit or open circuit to the wheel speed sensor 45. Referring to FIG. 4, the fault in the wheel speed sensor 45 is also detected by the RIO module #1 431, which also generates a DTC, such as receiving invalid serial data from the wheel speed sensor 45. In a signal-oriented diagnostic architecture, both of these individual DTCs can be reported, and then it would be necessary to proceed with the analysis of the underlying or root fault. In contrast, in a service-oriented diagnostic architecture, the triage of the DTCs can be performed in the system diagnostic layer 22, specifically the local diagnostic agent 2211 of the application service module, to confirm the root fault causing multiple DTCs. In this case, the triage confirms that there is a fault in the wheel speed sensor 45 and reports only the DTC code generated by the ABS module 2111.

[0063] As another example, still referring to FIG. 4, consider a scenario where three of the wheel sensors 45 fail. In this case, the ABS module 2111 generates three DTCs, namely that there is a short circuit or open circuit in each of the three wheel speed sensors 45. The RIO module #1 431 also generates three DTCs, namely that it has received invalid serial data from each of the three faulty wheel speed sensors 45. However, unlike the previous example, when there are faults in three wheel speed sensors, the vehicle speed cannot be calculated, and thus the RIO module #1 431 cannot provide the vehicle speed as a service. As outlined above, there are many vehicle modules that utilize the calculated vehicle speed signal. The RIO module #2 432 generates a DTC because the vehicle speed service is not received as an invalid vehicle speed signal, for example, as a service along the Ethernet network 42. Also, the IPC module 2114 generates DTCs such as signals indicating that the steering column cannot be unlocked or the engine cannot be started due to an incorrect vehicle speed, for example. Additionally, the ADC module 433 also utilizes the vehicle speed service as part of the cruise control function, and thus it generates a DTC because the vehicle speed is not received as an invalid vehicle speed signal, for example, as a service along the Ethernet network 42. In addition, the PCM 2112 and the TCM 2113 can use the vehicle speed signal transmitted along the conventional network 44 by the RIO module #1 431, and thus these modules generate DTCs if it is not received. In a signal-oriented diagnostic structure, each of these nine individual DTCs (two for the TCM 2113) can be reported, and then it will be necessary to start analyzing the underlying or root cause of the fault. In contrast, in a service-oriented diagnostic architecture, a service-level analysis of the DTCs can be performed in the system diagnostic layer 22 (hosted in this case by the domain controllers 431, 432, 433) and the vehicle diagnostic layer 23 (hosted in this case at the CCP 41) to confirm the root cause of the fault that causes multiple DTCs.In this case, the service level diagnosis confirms that three of the wheel speed sensors 45 are faulty, and therefore reports only the three DTC codes related to the wheel speed sensor faults generated by the ABS module 2111.

[0064] As a further example, consider that the conventional network communication bus 44 connected to the RIO module #1 431 is off / faulty. In this case, the RIO module #1 431 will generate a DTC for this effect. The ABS, PCM, and TCM 2111, 2112, 2113 are all on this communication bus 44, and therefore each of these modules will also generate a DTC for this effect. The RIO module #2 432 and the ADC 433 need to communicate with the ABS module 2111, and therefore each generates a DTC that communication with the ABS module 2111 has been lost. Similarly, the IPC module 2114 needs to communicate with the ABS module 2111, and therefore generates a DTC that communication with the ABS module 2111 has been lost. In a signal-directed diagnostic structure, "communication bus off" DTCs and "loss of communication with ABS" DTCs are reported, and then it will be necessary to proceed with the analysis of the underlying or root cause of the fault. In contrast, in a service-directed diagnostic architecture, a service level analysis of the DTCs can be performed in the system and vehicle diagnostic layers 22, 23 to determine whether the communication bus being off or faulty is the root cause, and therefore only the "communication bus off" DTC is reported.

[0065] Figure 5 shows an example of how the hierarchical diagnostic electrical architecture 20 of FIG. 2 can provide application services for vehicle user functions in the form of a direction indicator function. The direction indicator function is decomposed into one application service 51 in the system diagnostic layer (or second diagnostic layer) 22 and four functions 521, 522, 523, 524 in the component diagnostic layer (or first diagnostic layer) 21. In the example described, both the vehicle diagnostic layer 23 and the system diagnostic layer 22 are hosted on CCP41, and the component diagnostic layer 21 is hosted on RIO43. The four functional components or modules 521, 522, 523, 524 are each hosted on a different one of RIO43. The four functional components 521, 522, 523, 524 each have associated diagnostic servers 5211, 5221, 5231, 5241.

[0066] In the example described, the four functions 521, 522, 523, 524 include three optical functions 521, 522, 524 and a stalk function 523. Each of the functions 521, 522, 523, 524 receives sensor data from their respective sensors 531, 532, 533, 534 connected thereto via a conventional network 44, particularly LIN in this case. In particular, the sensors include sensors associated with different indicator lights in the vehicle, for example at the front or rear of the vehicle or in the door mirrors. The data from each of the functional modules 521, 522, 523, 524 is transmitted to the indicator service module 51 via the Ethernet backbone network 42.

[0067] Regarding the diagnostic function, each of the diagnostic servers 5211, 5221, 5231, 5241 can perform diagnostic operations on the received sensor output data together with the input / output connections of the functional modules 521, 522, 523, 524. Diagnostic notifications are sent to the indicator application service 51, for example in the form of fault codes. In particular, the local diagnostic agent 511 of service 51 performs service-level diagnostics on the diagnostic notifications received from the internal states of the functional modules 521, 522, 523, 524 and the indicator module 51.

[0068] As shown in FIG. 5, the off-board engineering diagnostic tester 54 is connected to the platform diagnostic service module 231 in the vehicle diagnostic layer 23. In this example, since there is only one application service, namely the indicator service 51, there is no vehicle or function level triage of diagnostic notifications in the vehicle diagnostic layer 23. The availability of the indicator service 51 is stored in the central database 232. The engineering tester 54 can be made aware of the indicator service 51, or the availability of the indicator service 51 can be sent to the engineering tester 54, and as a result, diagnostic messages related to the indicator service 51 can be sent to the engineering tester 54. In particular, the local diagnostic agent 511 can generate group diagnostic notifications based on its diagnostic operations. In the described example, the diagnostic communication between the off-board engineering tester 54 of the vehicle and the on-board platform service module 231 of the vehicle is sent using the UDS transport protocol. An individual gateway module in the vehicle architecture is not essential. This is because such gateway functionality can be provided as part of the platform diagnostic service module 231. That is, it converts the diagnostic communication between service-oriented diagnostic communication and UDS over DoIP so that normal diagnostic communication between the tester 54 and the vehicle architecture 20 becomes possible.

[0069] The engineering tester 54 can dynamically discover the indicator service 51 by subscribing to the latest list of diagnostic functions of the provided services stored in the on-board diagnostic registry or the central database 232. In particular, the central database 232 stores a list of faults, sensor readings, etc. supported by the diagnostic services. When one of the functions 521, 522, 523, 524 of the indicator service 51 is added / removed / modified, the diagnostic function of the indicator service 51 is updated in the central registry 232. For example, the engineering tester 54 may send a request to read fault information related to the indicator service 51. The ECUs 5211, 5221, 5231, 5241 respond with raw data in the form of related diagnostic objects, such as fault codes / DTCs. The diagnostic registry of the on-board central database 232 can then be used to interpret the DTCs and can send the interpreted diagnostic objects back to the diagnostic tester 54 so that diagnostic data sent off-board of the vehicle does not need to be interpreted by the tester.

[0070] Component-based diagnosis enables the detection of physical faults in sensors and actuators. However, this does not enable a determination as to whether the received sensor data conforms to the purpose of the application using it. That is, the received data may be outside the range useful for a particular application even if the sensor is not faulty itself. Therefore, the quality of the service can be improved by introducing monitoring of the functional operating range for the received sensor data.

[0071] Physical impairments of sensors and actuators can be monitored at the component level, i.e., the ECU level. This includes physical I / O impairments such as short circuit or open circuit impairments. A DTC log is created as soon as such an impairment is detected. At the service level, the local diagnostic agent 2211 can perform monitoring of the functional operating range of sensor data. Specifically, the local diagnostic agent 2211 can evaluate the functional validity of the sensor data received in a given operating state of a particular system and fuse the data received from other sources in a given context. The local diagnostic agent 2211 creates a DTC log and generates an event notification if it determines that the received data does not conform to the purpose even if no physical impairment has been detected at the component level.

[0072] Once the local diagnostic agent 2211 generates such a notification, it is evaluated at the vehicle level through vehicle-level monitoring services for the vehicle's state and power mode. As a result of this evaluation, a predictive event notification, i.e., an event notification that predicts the likelihood of a sensor or actuator impairment, can be generated as needed. Therefore, the diagnostic architecture 20 is not limited to reactive event notifications.

[0073] The example of FIG. 2 shows an essentially hierarchical service-oriented diagnostic electrical architecture having several diagnostic layers, but in different examples, an essentially non-hierarchical service-oriented diagnostic electrical architecture is also possible. In such an example, the services provided by individual ECUs can be broadcast or published. For example, other components such as an external diagnostic tester can subscribe to a particular ECU to receive event notifications.

[0074] The differences between the non - hierarchical signal - oriented (i.e., UDS protocol) architecture 10 of FIG. 1 and the non - hierarchical and hierarchical variations of the service - oriented architecture (such as the hierarchical service - oriented architecture 20 of FIG. 2, etc.) are described herein. In particular, the steps related to the design, deployment, execution, and update phases of diagnostic use cases for each architecture are described herein.

[0075] First, the diagnostic design phase is described. In UDS communication, adaptation to the UDS protocol is required. This includes identifying all diagnostic use cases for a particular system. Then, in addition to the UDS protocol specification for diagnostic communication, i.e., ISO14229 - 1, as described above, manufacturer - specific rules and limitations are defined. Note that not all manufacturer - specific customizations or extensions may be executable within the UDS framework.

[0076] In service - oriented diagnosis (SoD), SoD design is required. In both flat and hierarchical architectures, this includes identifying all diagnostic use cases for a particular system, similar to UDS communication. However, unlike UDS, SoD services that satisfy all diagnostic use cases are designed by specifying the service - provider and consumer relationship. Then, appropriate communication middleware that satisfies all the identified diagnostic use cases is selected. In particular, appropriate industry - standard middleware may be selected. For example, SOME / IP (Scalable service - oriented middleware over IP), REST (Representational state transfer), DDS (Data Distribution Service), etc. Next, the SoD service interface needs to be designed. In particular, properties, methods, events, and fields are specified in addition to the selected middleware. In a hierarchical SoD architecture, the SoD service interface is then instantiated across the various diagnostic layers of the architecture, such as the system layer and vehicle layer described above.

[0077] For both UDS communication and SoD communication, diagnostic objects are designed. In both cases, the failure modes and causes of malfunctions for the system are identified. This can be achieved using, for example, Failure Mode and Effects Analysis (FMEA). In particular, diagnostic objects in the form of Diagnostic Trouble Codes (DTCs) are designed to monitor the identified failure modes and causes of malfunctions. Snapshot information is also designed to capture environmental conditions when a malfunction occurs. A Diagnostic Extraction File (DEXT) is created to configure the ECU software. A Diagnostic Description File (ODX) is also created to configure the diagnostic tester.

[0078] Second, the diagnostic deployment phase is described. In UDS communication, the ECU software platform is configured using the DEXT file, and the diagnostic tester is configured using the ODX file. An external process ensures that the revisions of the DEXT file and the ODX file are compatible between the on-board ECU and the diagnostic tester.

[0079] In SoD communication, the SoD service interface is deployed on a selected communication middleware, for example, SOME / IP. The ECU software platform is configured using both the DEXT file and the ODX file. Note that this is in contrast to UDS communication where the ODX file is used to configure the diagnostic tester. In flat (non-hierarchical) SoD, the ECU ODX file is embedded in the ECU software, and in hierarchical (layered) SoD, the vehicle ODX file is embedded in the vehicle diagnostic layer of the architecture. This means that an external off-board diagnostic tester does not need to be configured using the ODX file for (both flat and hierarchical) SoD communication, which significantly simplifies the complexity of the external process that, for example, the manufacturer has to manage. Additionally, in hierarchical SoD, the central management of the ODX file in the vehicle diagnostic layer further simplifies the process and communication.

[0080] Thirdly, the diagnostic execution time phase is taken into account. In UDS communication, an off-board diagnostic tester establishes diagnostic communication with a target ECU or module in the vehicle by using the UDS protocol. This diagnostic communication is successful if the ODX file used in the configuration of the tester is compatible with the DEXT file used in the configuration of the ECU software stack in the vehicle. In one example, the off-board diagnostic tester sends a request message, for example, a request to read DTC information. The on-board target ECU responds with a UDS response message containing the requested diagnostic object with the appropriate DTC statically configured using the "raw" values. The diagnostic tester then interprets the received raw values of the diagnostic object using the ODX file configured by the diagnostic tester. The diagnosis can accurately interpret the response from the ECU if the ODX file used in the tester is the same / compatible with the DEXT file used to configure the ECU software.

[0081] In SoD communication, the off-board diagnostic tester establishes diagnostic communication with the target ECU or module in the vehicle using the SoD interface. This diagnostic communication is successful if the diagnostic tester directly supports the SoD interface. Alternatively, the diagnostic tester uses UDS to communicate with the vehicle architecture, and the platform diagnostic service module in the vehicle architecture performs the conversion between SoD and UDS on DoIP so that the diagnostic tester can communicate normally with the target ECU through the SoD interface. The diagnostic tester can then dynamically discover or learn the diagnostic services presented or provided by the network service bus via the SoD service interface. In particular, the central database maintains a diagnostic service registry containing a list of the provided services, and the diagnostic tester subscribes to the diagnostic service registry to dynamically learn the available services. Note that the target ECU also subscribes to the diagnostic service registry. Since the ODX file is embedded in the on-board architecture, specifically in the ECU software for the flat architecture and the vehicle diagnostic layer for the hierarchical architecture, the target ECU can respond to the diagnostic tester with the interpreted values of the diagnostic objects (DTC, events, snapshot dates, etc.) instead of the raw values of the diagnostic objects that need to be interpreted off-board in the vehicle.

[0082] Finally, the diagnostic update phase is considered. The update can be in the form of, for example, a new application or diagnostic function. In both UDS and SoD communications, the DEXT file and the ODX file are updated to reflect the changes in the diagnostic function. A new version of the DEXT file is released for the ECU software configuration, and a new version of the ODX file is released for the tester configuration. In both UDS and SoD configurations, the ECU software is reconfigured using the new DEXT file. However, unlike UDS communication, in SoD communication, a new ODX is also used to reconfigure the ECU software. In UDS communication, it is necessary to reconfigure the diagnostic tester using the new ODX file by using an external process. In contrast, in SoD communication, such reconfiguration of the external diagnostic tester is not necessary. In UDS communication, if both the tester and the target ECU are statically updated to recognize the changes, the target ECU supports the new diagnostic function when requested by the diagnostic tester. In contrast, in SoD communication, the diagnostic tester dynamically discovers the new diagnostic functions by discovering and subscribing to the new diagnostic services provided in the updated diagnostic service registry. As described above, if the diagnostic tester supports the SoD interface, or by performing the conversion between UDS and SoD in the platform diagnostic service module of the vehicle architecture, the diagnostic communication between the diagnostic tester and the target ECU can be successfully established.

[0083] Figure 6 outlines the steps of a method 60 for providing diagnostic communication in a vehicle's diagnostic electrical architecture. The vehicle has a network that includes a plurality of on-board computing devices for hosting the diagnostic electrical architecture. The on-board computing devices include a CCP 41, a plurality of RIO modules 43, or other zone computing devices or domain controllers, and a plurality of ECUs or other peripheral modules 211. For example, the diagnostic electrical architecture can be the hierarchical architecture 20 of FIG. 2. Alternatively, the diagnostic electrical architecture can be a non-hierarchical architecture. The architecture 20 includes electronic control units 211 each having a diagnostic server module 212. The architecture 20 also includes service interface modules 221, 231 configured to enable diagnostic communication between the electronic control units 211 and the vehicle's network service bus 42. In the example described, the architecture 20 includes some application service interface modules 221 in the system layer and a platform service interface module 231 in the vehicle layer. The architecture 20 also includes diagnostic service registry modules 222, 232 that store a list of diagnostic services provided via the service interface modules 221, 231.

[0084] In step 601, the diagnostic server module 212 executes a diagnostic task to generate diagnostic object data. In particular, each diagnostic server 212 has several related diagnostic objects that may include DTCs, events, data IDs (DIDs), and / or diagnostic control routines, which are for the diagnostic monitoring of various possible failure modes related to their respective ECUs 211, input / output / internal state control, and / or module identification. Specific diagnostic object data may be generated in response to a request or other event. The diagnostic object data includes raw data or codes that need to be interpreted to identify related malfunctions. For example, the DEXT file may specify configuration parameters for the ECU diagnostic software and diagnostic objects supported by the ECU software.

[0085] In step 602, the service interface module receives the generated diagnostic object data from the ECU 211. In particular, in the described example, the platform diagnostic service module 231 may receive diagnostic object data from each of the plurality of ECUs 211.

[0086] In step 603, diagnostic service data is obtained from the diagnostic service registry module 232. In particular, the obtained diagnostic service data includes a diagnostic function description of the generated diagnostic object data. For example, the diagnostic service data may include a diagnostic description file, such as an ODX file.

[0087] In step 604, a diagnostic service notification is sent via a network service bus, such as the Ethernet backbone 42. In particular, the diagnostic service notification is based on the generated diagnostic object data and diagnostic service data. That is, the sent diagnostic service notification includes the interpreted values or data of the unprocessed (uninterpreted) diagnostic object data. For example, the diagnostic service notification may be sent to the diagnostic tester 24 off-board the vehicle, so that the diagnostic tester 24 advantageously does not need to interpret the messages received from the vehicle architecture 20.

[0088] The diagnostic service notification can be an autonomous diagnostic service notification, i.e., one that is automatically generated when an event / fault occurs. The diagnostic service notification can also be a response to a diagnostic request received from an on-board or off-board diagnostic tester.

[0089] FIG. 7 shows a vehicle 70, which in the illustrated embodiment includes an automobile having a network architecture 40 (not shown in FIG. 8) and hosting a diagnostic electrical architecture 20.

[0090] Embodiments of the present invention are advantageous in that they provide service-oriented diagnostic communication in a vehicle electrical network architecture. This is in contrast to known systems where signal-oriented diagnostic communication is used, for example, using the UDS protocol. The service-oriented diagnostic communication of the present invention enables diagnostic tasks to be provided as services via a vehicle service bus to, for example, an off-board diagnostic tester of the vehicle or other modules that are part of the vehicle network architecture. In particular, the service-oriented diagnostic communication enables interpreted diagnostic messages to be transmitted, for example, to an external diagnostic tester, instead of unprocessed diagnostic data that needs to be interpreted off-board in the vehicle, such as one or more DTCs.

[0091] Embodiments of the present invention are particularly advantageous in that they use those that do not depend on service-oriented architecture middleware for diagnostic communication. This enables the provision of a scalable and flexible on-board service diagnostic interface. In particular, the update of the ECU diagnostic function does not require re-flashing of the ECU. Also, this enables diagnostic services to be dynamically discovered by other components, such as an external diagnostic tester, so that these components do not need to be specially configured for compatibility with any ECU diagnostic updates.

[0092] Known systems do not provide such functionality, at least not maximally. Some known systems provide middleware support for service-oriented architectures. However, these systems only provide support for UDS diagnostics within the basic software components of the ECU. Therefore, known systems inherit the limitations of the UDS protocol. For example, in some known systems, the diagnostic functions of the ECU need to be statically configured during the design and development stages of the ECU. That is, every time there is a change in the diagnostic functions of the ECU, the basic software layer of the ECU needs to be statically reconfigured and reflashed. Some known systems may provide a certain degree of dynamic configuration of the basic software layer of the ECU. For example, a function for updating a specific software package may be provided without reflashing the entire ECU. In such cases, individual software packages are clustered and have their own diagnostic addresses used to access diagnostic functions or software updates through a diagnostic manager component. Here, this component can be configured for each software package using additional files. However, none of these known systems provide functionality / flexibility other than the services provided by UDS.

[0093] Embodiments of the present invention are advantageous in that components, such as an external diagnostic tester, can subscribe to specific services so that diagnostic updates of the services can be dynamically learned. In particular, the present invention advantageously enables a service to generate or publish event notifications to all subscribers of the service based on event triggers, such as updates in the diagnostic functions of the service. Additionally, delivery guarantees to service subscribers can be advantageously provided for the event notifications.

[0094] Embodiments of the present invention are advantageous in that they introduce an abstraction layer via a service interface module, providing a logical and physical separation between an external connectivity module, i.e., a diagnostic tester, and a vehicle core module, i.e., an ECU, from a diagnostic access perspective. This improves security and reduces the vulnerability of the diagnostic architecture to cyberattacks. This is in contrast to a p2p diagnostic architecture where an external diagnostic tester can establish a direct communication path to an on-board ECU.

[0095] Embodiments of the present invention are advantageous in that they provide dynamic diagnostic resource contention management. Specifically, embodiments of the present invention advantageously enable simultaneous access by multiple different diagnostic testers, such as legislative scan tools, SOTA events, OBD scan tools, insurance dongles, etc. This is in contrast to some known systems that are restricted to allowing access to one diagnostic tester at a time through a gateway module, even when different testers require access to different system domains.

[0096] Referring to FIG. 8, a simplified example of the on-board computing device 800 described above is shown. The on-board computing device 800 can include a control unit or computing device having one or more electronic processors (e.g., microprocessors, microcontrollers, application specific integrated circuits (ASICs), etc.), and can also include a single control unit or computing device. Alternatively, the different functions of each on-board computing device 800 can be embedded or hosted in different control units or computing devices. As used herein, the terms "controller", "control unit" or "computing device" are understood to include a single controller, control unit or computing device, and multiple controllers, control units or computing devices that operate collectively to provide the necessary control functions. A set of instructions can be provided, which when executed cause the on-board computing device 800 to execute the control techniques described herein (including some or all of the functions necessary for the methods described herein). The set of instructions can be embedded in the one or more of the electronic processors of the on-board computing device 800. Alternatively, the set of instructions can be provided as software to be executed on the on-board computing device 800. The first controller or control unit can be implemented in software executed on one or more processors. One or more other controllers or control units can be implemented in software executed on one or more processors, optionally the same one or more processors as the first controller or control unit. Other configurations are also beneficial.

[0097] In the example shown in FIG. 8, the on-board computing device 800 includes at least one electronic processor 820, and the electronic processor 820 has one or more electrical inputs 822 for receiving one or more (input signals) and one or more electrical outputs 824 for outputting one or more (output signals). The on-board computing device 800 further includes at least one memory device 830, and the memory device 830 is electrically connected to at least one electronic processor 820 and stores instructions 840 therein. At least one electronic processor 820 is configured to access at least one memory device 830 and execute the instructions 840 therein.

[0098] The above or each electronic processor 820 may comprise any suitable electronic processor configured to execute electronic instructions (e.g., a microprocessor, a microcontroller, an ASIC, etc.). The above or each electronic memory device 830 can comprise any suitable memory device and can store various data, information, thresholds, lookup tables or other data structures, and / or instructions therein or thereon. In one embodiment, the memory device 830 has information and instructions for software, firmware, programs, algorithms, scripts, applications, etc. stored therein or thereon that may govern all or part of the methodologies described herein. The processor or each electronic processor 820 accesses the memory device 830 and executes and / or uses its or their instructions and information to perform some or all of the functions and methodologies described herein.

[0099] At least one memory device 830 may comprise a computer-readable storage medium (e.g., a non-transitory or non-volatile storage medium) that can include any mechanism for storing information in a form readable by a mechanical or electronic processor / computing device. The mechanical or electronic processor / computing device can include, but is not limited to, magnetic storage media (e.g., floppy disks); optical storage media (e.g., CD-ROMs); magneto-optical storage media; read-only memory (ROM); random access memory (RAM); erasable programmable memory (e.g., EPROM and EEPROM); flash memory; or electrical or other types of media for storing such information / instructions.

[0100] An example of an on-board computing device 800 is described, which includes at least one electronic processor 820 configured to execute electronic instructions stored in at least one memory device 830. When the electronic instructions are executed, the electronic processor 820 causes the methods described above to be executed. However, it is understood that embodiments of the present invention can be implemented by any suitable form of hardware, software, or a combination of hardware and software. For example, the present invention is not limited to being implemented by a programmable processing device, and it is contemplated that at least some of the functions and / or method steps of the present invention, and in some embodiments all of the functions and / or method steps of the present invention, can be equally executed by non-programmable hardware, such as via non-programmable ASICs, Boolean logic circuits, etc.

[0101] It is understood that various changes and modifications can be made to the present invention without departing from the scope of the present application. For example, all of the functions (including any accompanying claims, abstract, and drawings) disclosed herein, and / or all of the steps of any method or process so disclosed, can be combined in any combination, except combinations in which at least some of such functions and / or steps are mutually exclusive.

[0102] Each function disclosed in this specification (including any accompanying patent claims, abstract, and drawings) may be replaced by alternative functions that perform the same, equivalent, or similar purpose, unless expressly stated otherwise. Therefore, unless expressly stated otherwise, each function disclosed is merely an example of a general series of equivalent or similar functions.

[0103] The present invention is not limited to the details of any of the foregoing embodiments. The present invention extends to any novel one or any novel combination (including any accompanying patent claims, abstract, and drawings) of the functions disclosed herein, or to any novel one or any novel combination of the steps of any method or process so disclosed. The claims should not be construed as merely encompassing the foregoing embodiments, but rather as encompassing any embodiments within the scope of the claims.

Claims

1. A diagnostic electrical architecture for a vehicle, the vehicle comprising a plurality of on-board computing devices for hosting the diagnostic electrical architecture, the diagnostic electrical architecture comprising: One or more electronic control units each including a diagnostic server module configured to execute diagnostic tasks to generate diagnostic object data; A service interface module configured to enable diagnostic communication between the one or more electronic control units and a network service bus of the vehicle, the service interface module being configured to receive the generated diagnostic object data; A diagnostic service registry module configured to store diagnostic service data indicating the diagnostic services provided by the service interface module, the diagnostic service data including a diagnostic function description of the generated diagnostic object data; The service interface module is configured to send a diagnostic service notification via the network service bus, the diagnostic service notification being based on the generated diagnostic object data and the diagnostic service data obtained from the diagnostic service registry; The diagnostic service registry module is configured to enable modules, on-board and / or off-board of the vehicle, to dynamically learn the diagnostic services provided by the service interface module by joining the diagnostic service registry module. A diagnostic electrical architecture.

2. The diagnostic electrical architecture according to claim 1, wherein the diagnostic service notification is generated in response to a change in a diagnostic function provided by the service interface module.

3. The diagnostic electrical architecture according to claim 2, wherein the change in the diagnostic function is caused by addition or deletion of diagnostic tasks executed by the one or more electronic control units.

4. The diagnostic electrical architecture according to claim 2, wherein the change in the diagnostic function is caused by addition or deletion of an electronic control unit associated with the service interface module.

5. The diagnostic service notification is the diagnostic electrical architecture according to any one of claims 1 to 4, generated in response to a request for a diagnostic function received by the service interface module.

6. The diagnostic electrical architecture according to claim 5, wherein the request for the diagnostic function is received from an off-board diagnostic tester of a vehicle.

7. The diagnostic electrical architecture according to any one of claims 1 to 6, wherein the generated service notification is transmitted to the off-board of the vehicle.

8. The diagnostic electrical architecture according to any one of claims 1 to 7, wherein the diagnostic service notification is used to update a diagnostic register module.

9. The diagnostic electrical architecture according to any one of claims 1 to 8, wherein the service interface module is deployed in communication middleware in one or more on-board computing devices.

10. The communication middleware is SOME / IP (Scalable Service-Oriented Middleware over IP); REST (Representational state transfer); and The diagnostic electrical architecture according to claim 9, which is one of DDS (Data Distribution Service).

11. The diagnostic electrical architecture according to any one of claims 1 to 10, wherein the network service bus includes an Ethernet backbone network.

12. The diagnostic electrical architecture according to claim 11, wherein the service interface module is directly connected to the Ethernet backbone network.

13. The diagnostic electrical architecture according to any one of claims 1 to 12, configured to provide conversion between Unified Diagnostics Services (UDS) protocol communication and service-oriented diagnostic communication.

14. The diagnostic electrical architecture is a hierarchical architecture having a component diagnostic layer and at least one monitoring diagnostic layer, The diagnostic electrical architecture according to any one of claims 1 to 13, wherein the component diagnostic layer includes one or more electronic units.

15. The diagnostic electrical architecture according to claim 14, wherein the at least one monitoring diagnostic layer includes the service interface module.

16. The diagnostic electrical architecture according to claim 14 or 15, wherein the at least one monitoring and diagnostic layer includes the diagnostic service registry module.

17. The diagnostic electrical architecture according to claim 14, wherein the at least one monitoring and diagnostic layer includes a system diagnostic layer and a vehicle diagnostic layer in a layer of the diagnostic electrical architecture higher than the system diagnostic layer, the vehicle diagnostic layer includes the service interface module, the system diagnostic layer includes an application service module, and the application service module includes a local diagnostic agent configured to aggregate generated diagnostic service notifications received from the electronic control unit to generate monitoring level diagnostic service notifications.

18. The diagnostic electrical architecture according to claim 17, wherein the monitoring level diagnostic service notification is used to update the diagnostic service registry module.

19. A vehicle including a network architecture having a plurality of computing devices and hosting the diagnostic electrical architecture according to any one of claims 1 to 18.

20. A method for providing diagnostic communication in a diagnostic electrical architecture of a vehicle, the vehicle including a plurality of on-board computing devices for hosting the diagnostic electrical architecture, the diagnostic electrical architecture includes one or more electronic control units each including a diagnostic server module, a service interface module configured to enable diagnostic communication between the one or more electronic control units and a vehicle network service bus, and a diagnostic service registry module, the method includes executing a diagnostic task by the diagnostic server module to generate diagnostic object data, receiving the generated diagnostic object data into the service interface module, acquiring diagnostic service data from the diagnostic service registry module, the diagnostic service data including a diagnostic function description of the generated diagnostic object data, transmitting a diagnostic service notification via the network service bus, the diagnostic service notification being based on the generated diagnostic object data and the diagnostic service data. Enabling on-board and off-board modules of a vehicle to subscribe to the diagnostic service registry module so that on-board and / or off-board modules of the vehicle can dynamically learn the diagnostic services provided by the service interface module. A method including this. **Claim 21** A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to execute the method according to claim 20.

Images