Double-MCU cabin and berth integrated diagnosis method and architecture

Abstract

The invention provides a cabin and berth integrated diagnosis method and architecture of double MCUs, and the method comprises the steps: enabling a diagnosis service of a cabin MCU to receive a UDS diagnosis request sent by an external diagnosis device through a UDS protocol, carrying out the judgment of the UDS diagnosis request, and determining a diagnosis target of the UDS diagnosis request; the diagnosis target responding to the UDS diagnosis request is SOC diagnosis, and the diagnosis service of the cabin MCU sends the diagnosis request to the SOC through an SPI protocol; and the SOC performs diagnosis based on the diagnosis request to obtain a corresponding SOC diagnosis result, and sends the SOC diagnosis result to the cabin MCU through an SPI protocol in response to a received diagnosis reading instruction of the cabin MCU, so that the diagnosis service of the cabin MCU sends the SOC diagnosis result to the diagnosis equipment through a UDS protocol.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle machine diagnosis, in particular to a cabin-parking integrated diagnosis method and architecture of dual MCUs. BACKGROUND

[0002] More and more controllers are integrated into one, and a single controller can develop multiple functions at the same time, such as vehicle control functions, cabin functions, etc., which are all developed in one controller to save controller costs and only need to develop one set of fault protocol.

[0003] At present, the traditional intelligent parking and intelligent cabin adopt a distributed inter-domain independent scheme, and two domain controllers are used to realize parking and cabin functions, and when diagnosing, a diagnosis fault table is developed independently for each controller.

[0004] However, the traditional intelligent parking and intelligent cabin need to independently develop their own diagnosis fault tables, the diagnosis scheme has high complexity and large workload, resulting in high development cost and low diagnosis efficiency. SUMMARY

[0005] Therefore, the purpose of the present application is to provide a cabin-parking integrated diagnosis method and architecture of dual MCUs, which takes the cabin MCU as the diagnosis master node through the cabin-parking integrated diagnosis architecture of dual MCUs, and through the diagnosis service in the cabin MCU and the combination of respective interaction protocols, the diagnosis target of the UDS diagnosis request is distinguished and then interacted to perform cabin MCU, parking MCU or SOC diagnosis. Thus, the diagnosis instruction and diagnosis result are sent and collected by the cabin MCU, and there is no need to independently develop the diagnosis fault tables of the cabin function and the parking function, only one diagnosis fault table needs to be developed, which reduces the diagnosis scheme complexity and workload, thereby reducing the development cost and improving the diagnosis efficiency.

[0006] In a first aspect, the embodiments of the present application provide a cabin-parking integrated diagnosis method of dual MCUs, applied to a cabin-parking integrated diagnosis architecture of dual MCUs; the cabin-parking integrated diagnosis architecture includes a cabin MCU, a parking MCU and a SOC, and the cabin MCU, the parking MCU and the SOC are in communication connection with each other; the cabin MCU interacts through its own diagnosis service; and the method includes: The diagnosis service of the cabin MCU receives a UDS diagnosis request sent by an external diagnosis device through a UDS protocol, judges the UDS diagnosis request, and determines the diagnosis target of the UDS diagnosis request; wherein the diagnosis target is cabin MCU diagnosis, parking MCU diagnosis or SOC diagnosis; In response to the diagnosis target of the UDS diagnosis request being SOC diagnosis, the diagnosis service of the cabin MCU sends the diagnosis request to the SOC through a SPI protocol. The SOC performs diagnosis based on the diagnosis request to obtain a corresponding SOC diagnosis result, and in response to receiving a diagnosis reading instruction of the cabin MCU, the SOC diagnosis result is sent to the cabin MCU through an SPI protocol, so that the diagnosis service of the cabin MCU sends the SOC diagnosis result to the diagnosis device through a UDS protocol; wherein the SOC diagnosis result includes a surround view perception diagnosis result, a first hardware diagnosis result and a first software diagnosis result.

[0007] In a possible implementation, the method further includes: In response to the diagnosis target of the UDS diagnosis request being the cabin MCU diagnosis, the cabin MCU sends a diagnosis request to the parking MCU through a UART protocol; The parking MCU performs diagnosis based on the diagnosis request to obtain a corresponding parking MCU diagnosis result, and in response to receiving a diagnosis reading instruction of the cabin MCU, the parking MCU diagnosis result is sent to the cabin MCU through the UART protocol, so that the cabin MCU sends the parking MCU diagnosis result to the diagnosis device through a UDS protocol; wherein the parking MCU diagnosis result includes a chassis CAN signal diagnosis result, a second hardware diagnosis result and a second software diagnosis result.

[0008] In a possible implementation, the method further includes: In response to the diagnosis target of the UDS diagnosis request being the cabin MCU diagnosis, the cabin MCU performs diagnosis to obtain a corresponding cabin MCU diagnosis result; wherein the cabin MCU diagnosis result includes an entertainment CAN signal diagnosis result, a third hardware diagnosis result and a third software diagnosis result; The cabin MCU sends the cabin MCU diagnosis result to the diagnosis device through a UDS protocol.

[0009] In a possible implementation, the SOC includes a first diagnosis application; the method further includes: The cabin MCU sends a diagnosis request to the first diagnosis application in the SOC through an SPI protocol; SOC diagnosis is performed through the first diagnosis application in the SOC to obtain a corresponding SOC diagnosis result.

[0010] In a possible implementation, the parking MCU includes a second diagnosis application; the method further includes: The cabin MCU sends a diagnosis request to the second diagnosis application in the parking MCU through a UART protocol; The parking MCU diagnosis is performed by a second diagnosis application in the parking MCU, and a corresponding parking MCU diagnosis result is obtained.

[0011] In a possible implementation, the cockpit MCU includes a third diagnosis application; and the method further includes: The cockpit MCU diagnosis is performed by the third diagnosis application in the cockpit MCU, and a corresponding cockpit MCU diagnosis result is obtained.

[0012] In a possible implementation, the cockpit MCU diagnosis is performed by the third diagnosis application in the cockpit MCU, and a corresponding cockpit MCU diagnosis result is obtained, including: The diagnosis service of the cockpit MCU sends a diagnosis request to the third diagnosis application; The cockpit MCU diagnosis is performed by the third diagnosis application in the cockpit MCU based on the diagnosis request, and a corresponding cockpit MCU diagnosis result is obtained.

[0013] In a possible implementation, the method further includes: Data is transmitted between the parking MCU and the SOC through the SPI protocol; If SPI transmission is found to be abnormal, the SOC and the parking MCU can both diagnose the SPI transmission abnormality.

[0014] In a possible implementation, the method further includes: The first software diagnosis result is diagnosed internally in the SOC, and the surround view perception diagnosis result and the first hardware diagnosis result are diagnosed externally in the SOC; The second software diagnosis result is diagnosed internally in the parking MCU, and the chassis CAN signal diagnosis result and the second hardware diagnosis result are diagnosed externally in the parking MCU; The third software diagnosis result is diagnosed internally in the cockpit MCU, and the entertainment CAN signal diagnosis result and the third hardware diagnosis result are diagnosed externally in the cockpit MCU.

[0015] In a second aspect, the embodiments of the present application further provide a dual-MCU cockpit-parking integrated diagnosis architecture, which includes a cockpit MCU, a parking MCU, and an SOC, wherein the cockpit MCU, the parking MCU, and the SOC are communicatively connected to each other; the cockpit MCU performs interaction through a diagnosis service of the cockpit MCU. The dual-MCU cockpit-parking integrated diagnosis architecture is configured to perform the dual-MCU cockpit-parking integrated diagnosis method provided in the first aspect.

[0016] This application provides a dual-MCU integrated cabin diagnostic method and architecture. The cabin MCU's diagnostic service receives a UDS diagnostic request sent by an external diagnostic device via the UDS protocol, judges the UDS diagnostic request, and determines the diagnostic target of the UDS diagnostic request. In response to the diagnostic target of the UDS diagnostic request being SOC diagnostic, the cabin MCU's diagnostic service sends the diagnostic request to the SOC via the SPI protocol. The SOC performs diagnosis based on the diagnostic request, obtains the corresponding SOC diagnostic result, and in response to receiving the diagnostic read instruction from the cabin MCU, sends the SOC diagnostic result to the cabin MCU via the SPI protocol, so that the cabin MCU's diagnostic service can send the SOC diagnostic result to the diagnostic device via the UDS protocol. This application utilizes a dual-MCU integrated cabin and parking diagnostic architecture, with the cabin MCU serving as the main diagnostic node. By combining the diagnostic services within the cabin MCU with their respective interaction protocols, the diagnostic targets of the UDS diagnostic request are differentiated, and then interactive diagnostics are performed on the cabin MCU, parking MCU, or SOC. As a result, diagnostic commands and results are uniformly sent and received by the cabin MCU, eliminating the need to develop separate diagnostic fault tables for the cabin and parking functions. Only one diagnostic fault table needs to be developed, reducing the complexity and workload of the diagnostic scheme, thereby lowering development costs and improving diagnostic efficiency.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a dual-MCU integrated cabin diagnostic method provided according to an embodiment of this application; Figure 2 This is a schematic diagram of the integrated diagnostic architecture for cabin parking. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0021] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0023] Considering that more and more controllers are being integrated into one unit, a single controller can simultaneously develop multiple functions, such as vehicle control functions and cockpit functions, all of which are integrated into one controller for development. This saves controller costs and only requires the development of one fault protocol.

[0024] Currently, traditional intelligent parking and intelligent cockpits employ a distributed, independent domain approach, using two domain controllers to implement parking and cockpit functions respectively. During diagnostics, a separate diagnostic fault table is developed for each controller. However, traditional intelligent parking and intelligent cockpits require independently developed diagnostic fault tables, resulting in high complexity and workload, leading to high development costs and reduced diagnostic efficiency.

[0025] To address this issue, this application provides a dual-MCU integrated cabin and parking diagnostic method and architecture. This architecture uses the cockpit MCU as the main diagnostic node. Through the diagnostic services within the cockpit MCU combined with their respective interaction protocols, the diagnostic targets of the UDS diagnostic request are differentiated, and then interactive diagnostics are performed on the cockpit MCU, parking MCU, or SOC. Thus, the cockpit MCU uniformly sends and receives diagnostic commands and results, eliminating the need to develop separate diagnostic fault tables for cockpit and parking functions. Only one diagnostic fault table needs to be developed, reducing the complexity and workload of the diagnostic scheme, thereby lowering development costs and improving diagnostic efficiency.

[0026] Figure 1 This is a flowchart of a dual-MCU integrated cabin diagnostic method according to an embodiment of this application. The dual-MCU integrated cabin diagnostic method of this application is applied to a dual-MCU integrated cabin diagnostic architecture; the integrated cabin diagnostic architecture includes a cockpit MCU, a parking MCU, and a SOC, which are communicatively connected to each other; the cockpit MCU interacts with itself through its own diagnostic services. For example, ... Figure 2 As shown.

[0027] like Figure 1 As shown, the dual-MCU integrated cabin diagnostic method of this application embodiment may specifically include: S101. The cockpit MCU's diagnostic service receives a UDS diagnostic request sent by an external diagnostic device via the UDS protocol, judges the UDS diagnostic request, and determines the diagnostic target of the UDS diagnostic request.

[0028] S102. In response to the diagnostic target of the UDS diagnostic request being SOC diagnostics, the cockpit MCU's diagnostic service sends the diagnostic request to the SOC via the SPI protocol.

[0029] S103, SOC performs diagnosis based on the diagnostic request, obtains the corresponding SOC diagnostic result, and responds to the received diagnostic read command from the cockpit MCU by sending the SOC diagnostic result to the cockpit MCU via the SPI protocol, so that the cockpit MCU's diagnostic service can send the SOC diagnostic result to the diagnostic device via the UDS protocol.

[0030] In the aforementioned dual-MCU integrated cabin and parking diagnostic method, the cabin MCU is used as the main diagnostic node through a dual-MCU integrated cabin and parking diagnostic architecture. The diagnostic services in the cabin MCU, combined with their respective interaction protocols, distinguish the diagnostic targets of the UDS diagnostic request and then perform interactive diagnostics on the cabin MCU, parking MCU, or SOC. Thus, the cabin MCU uniformly sends and receives diagnostic commands and results, eliminating the need to develop separate diagnostic fault tables for the cabin and parking functions. Only one diagnostic fault table needs to be developed, reducing the complexity and workload of the diagnostic scheme, thereby reducing development costs and improving diagnostic efficiency.

[0031] The exemplary steps described above in the embodiments of this application are illustrated below with specific examples: S101, the cockpit MCU's diagnostic service receives a UDS diagnostic request sent by an external diagnostic device via the UDS protocol, judges the UDS diagnostic request, and determines the diagnostic target of the UDS diagnostic request.

[0032] In this embodiment, the diagnostic target is either cockpit MCU diagnostics, parking MCU diagnostics, or SOC diagnostics; that is, it determines whether the UDS diagnostic request is for diagnosing the cockpit MCU, parking MCU, or SOC. The diagnostic service in the cockpit MCU receives a UDS diagnostic request signal from an external diagnostic device and determines whether the diagnostic target of the UDS diagnostic request is for SOC function diagnostics, parking MCU diagnostics, or diagnostics of the cockpit MCU itself, in order to perform subsequent processing. For example, ... Figure 2 As shown, external diagnostic devices and diagnostic services in the cockpit MCU interact via the UDS protocol.

[0033] S102, in response to the UDS diagnostic request, the diagnostic target is SOC diagnostics, and the cockpit MCU's diagnostic service sends the diagnostic request to the SOC via the SPI protocol.

[0034] In this embodiment of the application, when the diagnostic target of the UDS diagnostic request in step S101 is SOC diagnostics, the cockpit MCU's diagnostic service sends the diagnostic request to the SOC via the SPI protocol for subsequent processing. For example, Figure 2 As shown.

[0035] S103, the SOC performs diagnosis based on the diagnostic request, obtains the corresponding SOC diagnostic result, and responds to the received diagnostic read command from the cockpit MCU by sending the SOC diagnostic result to the cockpit MCU via the SPI protocol, so that the cockpit MCU's diagnostic service can send the SOC diagnostic result to the diagnostic device via the UDS protocol.

[0036] In this embodiment, the SOC diagnostic results include surround-view perception diagnostic results, first hardware diagnostic results, and first software diagnostic results. The cockpit MCU's diagnostic service sends a diagnostic request to the SOC via the SPI protocol. The SOC performs diagnostics based on the diagnostic request, obtains the corresponding SOC diagnostic results, and upon receiving a diagnostic read instruction from the cockpit MCU, sends the SOC diagnostic results to the cockpit MCU via the SPI protocol. The cockpit MCU's diagnostic service then sends the SOC diagnostic results to the diagnostic device via the UDS protocol. For example, as... Figure 2 As shown.

[0037] It should be noted that the first software diagnostic result is diagnosed within the SOC, while the surround-sight perception diagnostic result and the first hardware diagnostic result are diagnosed outside the SOC. For example, ... Figure 2 As shown.

[0038] Specifically, for example, such as Figure 2 As shown, if the diagnostic target of the UDS diagnostic request is SOC diagnostics, the diagnostic service in the cockpit MCU will send the diagnostic request to the diagnostic application in the SOC via the SPI protocol. Subsequently, the diagnostic application in the SOC will reply to the diagnostic service in the cockpit MCU with the results of surround view perception, hardware diagnostics and software diagnostics via the SPI protocol. Finally, the diagnostic service in the cockpit MCU will reply to the diagnostic device via UDS.

[0039] In some implementations, the SOC includes a first diagnostic application; the cockpit MCU sends a diagnostic request to the first diagnostic application in the SOC via the SPI protocol; the first diagnostic application in the SOC performs SOC diagnostics to obtain the corresponding SOC diagnostic results. For example, ... Figure 2 As shown.

[0040] The dual-MCU integrated cabin diagnostic method provided in this application embodiment involves the cockpit MCU's diagnostic service receiving a UDS diagnostic request sent by an external diagnostic device via the UDS protocol. The cockpit MCU's diagnostic service then assesses the UDS diagnostic request to determine its diagnostic target. If the diagnostic target of the UDS diagnostic request is SOC diagnostics, the cockpit MCU's diagnostic service sends the diagnostic request to the SOC via the SPI protocol. The SOC performs diagnostics based on the diagnostic request, obtains the corresponding SOC diagnostic result, and, in response to receiving a diagnostic read instruction from the cockpit MCU, sends the SOC diagnostic result back to the cockpit MCU via the SPI protocol. This enables the cockpit MCU's diagnostic service to send the SOC diagnostic result to the diagnostic device via the UDS protocol. The dual-MCU integrated cabin and parking diagnostic method of this application uses a dual-MCU integrated cabin and parking diagnostic architecture, with the cabin MCU as the main diagnostic node. By combining the diagnostic services in the cabin MCU with their respective interaction protocols, the diagnostic targets of the UDS diagnostic request are distinguished and then interactively performed on the cabin MCU, parking MCU, or SOC. Thus, the cabin MCU uniformly sends and receives diagnostic commands and results, eliminating the need to develop separate diagnostic fault tables for the cabin and parking functions. Only one diagnostic fault table needs to be developed, reducing the complexity and workload of the diagnostic scheme, thereby reducing development costs and improving diagnostic efficiency.

[0041] Furthermore, in response to the UDS diagnostic request, the diagnostic target is the parking MCU diagnostic. The cockpit MCU sends the diagnostic request to the parking MCU via the UART protocol. The parking MCU performs diagnostics based on the diagnostic request, obtains the corresponding parking MCU diagnostic results, and, in response to receiving the diagnostic read command from the cockpit MCU, sends the parking MCU diagnostic results back to the cockpit MCU via the UART protocol, so that the cockpit MCU sends the parking MCU diagnostic results to the diagnostic device via the UDS protocol. The parking MCU diagnostic results include chassis CAN signal diagnostic results, second hardware diagnostic results, and second software diagnostic results. For example, such as... Figure 2 As shown.

[0042] Specifically, for example, such as Figure 2 As shown, if the diagnostic target of the UDS diagnostic request is to diagnose the parking MCU, the diagnostic service in the cockpit MCU will send the diagnostic request to the diagnostic application in the parking MCU via the UART protocol. Subsequently, the diagnostic application in the parking MCU will reply to the diagnostic service in the cockpit MCU with the results of the chassis CAN signal, hardware diagnostics and software diagnostics via the UART protocol. Finally, the diagnostic service in the cockpit MCU will reply to the diagnostic device via UDS.

[0043] It should be noted that the second software diagnostic results are diagnosed internally within the parking MCU, while the chassis CAN signal diagnostic results and the second hardware diagnostic results are diagnosed externally within the parking MCU. For example, ...Figure 2 As shown.

[0044] In some implementations, the parking MCU includes a second diagnostic application. The cockpit MCU sends diagnostic requests to the second diagnostic application in the parking MCU via the UART protocol; the second diagnostic application in the parking MCU performs parking MCU diagnostics and obtains the corresponding parking MCU diagnostic results. For example, such as... Figure 2 As shown.

[0045] Furthermore, the diagnostic target in response to the UDS diagnostic request is the cockpit MCU diagnostics. The cockpit MCU performs the diagnostics and obtains the corresponding cockpit MCU diagnostic results. The cockpit MCU sends the cockpit MCU diagnostic results to the diagnostic equipment via the UDS protocol. These cockpit MCU diagnostic results include entertainment CAN signal diagnostic results, third-party hardware diagnostic results, and third-party software diagnostic results. For example, such as... Figure 2 As shown.

[0046] Specifically, for example, such as Figure 2 As shown, if the diagnostic target of the UDS diagnostic request is the cockpit MCU itself, the diagnostic service in the cockpit MCU will reply to the diagnostic device through UDS with the results of the entertainment CAN signal, hardware diagnostics and software diagnostics.

[0047] It should be noted that the third-party software diagnostic results are diagnosed within the cockpit MCU, while the entertainment CAN signal diagnostic results and the third-party hardware diagnostic results are diagnosed externally to the cockpit MCU. For example, ... Figure 2 As shown.

[0048] In some implementations, the cockpit MCU includes a third diagnostic application. This third diagnostic application performs cockpit MCU diagnostics and obtains the corresponding cockpit MCU diagnostic results. For example, such as... Figure 2 As shown.

[0049] Optionally, the cockpit MCU's diagnostic service will send a diagnostic request to a third-party diagnostic application; the third-party diagnostic application in the cockpit MCU will then perform cockpit MCU diagnostics based on the diagnostic request and obtain the corresponding cockpit MCU diagnostic results. For example, ... ​ As shown.

[0050] Furthermore, the parking MCU and SOC transmit data via the SPI protocol; if an SPI transmission anomaly is detected, both the SOC and the parking MCU can diagnose the SPI transmission anomaly.

[0051] Specifically, the SOC and the parking MCU transmit data via the SPI protocol. If there is an SPI transmission anomaly, both the SOC and the parking MCU can detect it.

[0052] In summary, in this application, the cockpit MCU acts as the diagnostic master node. Only the diagnostic service in the cockpit MCU performs diagnostic fault code reading and receives diagnostic control commands from peripheral diagnostic devices via the UDS protocol. The diagnostics identified by the SOC, including hardware and software diagnostic results, are transmitted through the SPI link with the cockpit MCU. After receiving the diagnostic read command from the cockpit MCU, the SOC sends the corresponding diagnostic results back to the cockpit MCU via the SPI link. The diagnostics identified by the parking MCU, including hardware and software diagnostic results, are transmitted through the UART link with the cockpit MCU. After receiving the diagnostic read command from the cockpit MCU, the parking MCU sends the corresponding diagnostic results back to the cockpit MCU via the UART link. Data is transmitted between the SOC and the parking MCU via the SPI protocol. If there is an SPI transmission anomaly, both the SOC and the parking MCU can detect it.

[0053] Therefore, the parking MCU and the cockpit MCU of this application transmit data through a link, and the cockpit MCU sends and receives diagnostic commands and results in a unified manner. This reduces the complexity of the diagnostic scheme and the workload of development, and enables efficient diagnosis.

[0054] This application also provides a dual-MCU integrated diagnostic architecture for cabin parking, which includes a cockpit MCU, a parking MCU, and a SOC. The cockpit MCU, parking MCU, and SOC are interconnected and communicate with each other. The cockpit MCU interacts with each other through its own diagnostic services.

[0055] The aforementioned dual-MCU integrated cabin diagnostic architecture is used to execute the aforementioned dual-MCU integrated cabin diagnostic method.

[0056] The dual-MCU integrated cabin diagnostic architecture provided in this application embodiment involves the cockpit MCU's diagnostic service receiving a UDS diagnostic request sent by an external diagnostic device via the UDS protocol. The service then assesses the UDS diagnostic request to determine its diagnostic target. If the diagnostic target is SOC diagnostics, the cockpit MCU's diagnostic service sends the diagnostic request to the SOC via the SPI protocol. The SOC performs diagnostics based on the request, obtains the corresponding SOC diagnostic result, and, in response to receiving a diagnostic read command from the cockpit MCU, sends the SOC diagnostic result back to the cockpit MCU via the SPI protocol. This enables the cockpit MCU's diagnostic service to send the SOC diagnostic result to the diagnostic device via the UDS protocol. The dual-MCU integrated diagnostic architecture of this application uses the cockpit MCU as the main diagnostic node. By combining the diagnostic services in the cockpit MCU with their respective interaction protocols, the diagnostic targets of the UDS diagnostic request are distinguished and then interactively performed on the cockpit MCU, parking MCU, or SOC. Thus, the cockpit MCU uniformly sends and receives diagnostic commands and results, eliminating the need to develop separate diagnostic fault tables for cockpit and parking functions. Only one diagnostic fault table needs to be developed, reducing the complexity and workload of the diagnostic scheme, thereby reducing development costs and improving diagnostic efficiency.

[0057] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0058] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0059] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0060] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the deployment methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0061] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A dual-MCU integrated diagnostic method for cabin operation, characterized in that, A dual-MCU integrated diagnostic architecture for parking; the integrated diagnostic architecture includes a cockpit MCU, a parking MCU, and a SOC, which are communicatively connected to each other; the cockpit MCU interacts through its own diagnostic services; the method includes: The cockpit MCU diagnostic service receives a UDS diagnostic request sent by an external diagnostic device via the UDS protocol, judges the UDS diagnostic request, and determines the diagnostic target of the UDS diagnostic request; wherein, the diagnostic target is cockpit MCU diagnostic, parking MCU diagnostic, or SOC diagnostic. In response to the diagnostic target of the UDS diagnostic request being SOC diagnostics, the diagnostic service of the cockpit MCU sends the diagnostic request to the SOC via the SPI protocol; The SOC performs a diagnosis based on the diagnostic request, obtains the corresponding SOC diagnostic result, and in response to receiving the diagnostic read instruction from the cockpit MCU, sends the SOC diagnostic result to the cockpit MCU via the SPI protocol, so that the cockpit MCU's diagnostic service sends the SOC diagnostic result to the diagnostic device via the UDS protocol; wherein, the SOC diagnostic result includes surround-view perception diagnostic result, first hardware diagnostic result, and first software diagnostic result.

2. The method according to claim 1, characterized in that, The method further includes: In response to the UDS diagnostic request, the diagnostic target is the parking MCU diagnostic, and the cockpit MCU sends the diagnostic request to the parking MCU via the UART protocol; The parking MCU performs a diagnosis based on the diagnostic request, obtains the corresponding parking MCU diagnostic result, and in response to receiving the diagnostic read command from the cockpit MCU, sends the parking MCU diagnostic result to the cockpit MCU via the UART protocol, so that the cockpit MCU sends the parking MCU diagnostic result to the diagnostic device via the UDS protocol; wherein, the parking MCU diagnostic result includes chassis CAN signal diagnostic result, second hardware diagnostic result, and second software diagnostic result.

3. The method according to claim 2, characterized in that, The method further includes: The diagnostic target in response to the UDS diagnostic request is cockpit MCU diagnostics. The cockpit MCU is diagnosed to obtain the corresponding cockpit MCU diagnostic results. The cockpit MCU diagnostic results include entertainment CAN signal diagnostic results, third hardware diagnostic results, and third software diagnostic results. The cockpit MCU sends its diagnostic results to the diagnostic device via the UDS protocol.

4. The method according to claim 3, characterized in that, The SOC includes a first diagnostic application; the method further includes: The cockpit MCU sends diagnostic requests to the first diagnostic application in the SOC via the SPI protocol; SOC diagnosis is performed using the first diagnostic application in the SOC, and the corresponding SOC diagnosis result is obtained.

5. The method according to claim 4, characterized in that, The parking MCU includes a second diagnostic application; the method further includes: The cockpit MCU sends diagnostic requests to the second diagnostic application in the parking MCU via the UART protocol; The parking MCU is diagnosed by performing a second diagnostic application in the parking MCU, and the corresponding parking MCU diagnostic results are obtained.

6. The method according to claim 5, characterized in that, The cockpit MCU includes a third diagnostic application; the method further includes: The third diagnostic application in the cockpit MCU performs cockpit MCU diagnostics and obtains the corresponding cockpit MCU diagnostic results.

7. The method according to claim 6, characterized in that, The third diagnostic application in the cockpit MCU performs cockpit MCU diagnostics and obtains the corresponding cockpit MCU diagnostic results, including: The diagnostic service of the cockpit MCU will send diagnostic requests to a third diagnostic application; The third diagnostic application in the cockpit MCU performs cockpit MCU diagnostics based on the diagnostic request and obtains the corresponding cockpit MCU diagnostic results.

8. The method according to claim 7, characterized in that, The method further includes: The parking MCU and the SOC transmit data via the SPI protocol; If an SPI transmission anomaly is detected, both the SOC and the parking MCU can diagnose the SPI transmission anomaly.

9. The method according to claim 8, characterized in that, The method further includes: The first software diagnostic result is diagnosed inside the SOC, while the surround-view perception diagnostic result and the first hardware diagnostic result are diagnosed outside the SOC. The second software diagnostic result is diagnosed inside the parking MCU, while the chassis CAN signal diagnostic result and the second hardware diagnostic result are diagnosed outside the parking MCU. The third software diagnostic result is diagnosed inside the cockpit MCU, while the entertainment CAN signal diagnostic result and the third hardware diagnostic result are diagnosed outside the cockpit MCU.

10. A dual-MCU integrated cabin diagnostic architecture, characterized in that, The integrated cabin and parking diagnostic architecture includes a cockpit MCU, a parking MCU, and a SOC, which are interconnected and communicate with each other; the cockpit MCU interacts with each other through its own diagnostic services. The integrated cabin diagnostic architecture is applied to the integrated cabin diagnostic method with dual MCUs as described in any one of claims 1-9.

Images