Diagnostic system and method, storage medium, program product, control chip, and vehicle

Abstract

The invention discloses a diagnosis system and method, a storage medium, a program product, a control chip and a vehicle, and relates to the technical field of diagnosis. The system comprises a plurality of operating systems, the plurality of operating systems at least comprise a first operating system and a second operating system, and the first operating system is used for performing self-diagnosis to obtain first fault data and transmitting the first fault data to the second operating system; and the second operating system is used for performing self-diagnosis to obtain second fault data and receiving the first fault data transmitted by the first operating system. The system can diagnose a plurality of operating systems, and can break data islands by concentrating the fault data of the plurality of operating systems, thereby realizing unified management of the fault data of the plurality of operating systems.

Description

Technical Field

[0001] This invention relates to the field of diagnostic technology, and more particularly to a diagnostic system, method, storage medium, program product, control chip, and vehicle. Background Technology

[0002] Currently, most device diagnostics are still limited to the detection and analysis of a single operating system. With the rapid development of information technology and the increasing complexity of devices, multi-operating system devices are gradually becoming the mainstream. These devices typically integrate multiple operating systems to collaboratively complete complex tasks. Therefore, there is an urgent need for a diagnostic solution that can transcend multiple operating systems. Summary of the Invention

[0003] The purpose of this invention is to provide a diagnostic system, diagnostic method, storage medium, program product, and vehicle to enable the diagnosis of multiple operating systems, break down data silos, and achieve unified management of fault data from multiple operating systems.

[0004] In a first aspect, embodiments of the present invention provide a diagnostic system comprising: multiple operating systems, the multiple operating systems including at least a first operating system and a second operating system; the first operating system being configured to perform self-diagnosis to obtain first fault data and transmit the first fault data to the second operating system; and the second operating system being configured to perform self-diagnosis to obtain second fault data and receive the first fault data transmitted by the first operating system.

[0005] In some embodiments, the second operating system is further configured to: integrate and process the first fault data and the second fault data.

[0006] In some embodiments, the system further includes a processor for receiving and storing the first fault data and the second fault data transmitted by the kernel of the second operating system.

[0007] In some embodiments, the kernel of the first operating system is adapted to communicate with an external diagnostic device, and the first operating system is further configured to: receive and respond to diagnostic requests sent by the external diagnostic device.

[0008] In some embodiments, the first operating system is specifically configured to: when the diagnostic request is a fault code read request, query the processor to obtain fault data corresponding to the fault code request, and feed back the obtained fault data to the external diagnostic device.

[0009] In some embodiments, the first operating system is specifically configured to: when the diagnostic request is a fault clearing request, notify the processor to perform a clearing operation on the fault data corresponding to the fault clearing request, and forward the operation confirmation information fed back by the processor to the external diagnostic device.

[0010] In some embodiments, the first operating system is further configured to: store the first fault data in a local database of the first operating system.

[0011] In some embodiments, the first operating system is further configured to: when the fault data corresponding to the diagnostic request is the first fault data, perform the operation corresponding to the diagnostic request on the local database, and feed back the operation confirmation information to the external diagnostic device.

[0012] In some embodiments, the first operating system is further configured to: synchronize response information for the diagnostic request to the second operating system.

[0013] In some embodiments, the kernel of the second operating system is adapted to communicate with a remote terminal, and the second operating system is further configured to: synchronize response information to the diagnostic request to the remote terminal.

[0014] In some embodiments, the first operating system communicates with the external diagnostic device via an Ethernet DoIP protocol stack.

[0015] In some embodiments, the kernel containing the first operating system and the kernel containing the second operating system communicate with the processor via a serial peripheral interface.

[0016] In some embodiments, the processor uses full-duplex communication mode to communicate with the kernel of the first operating system and the kernel of the second operating system respectively, and supports data transfer via direct memory access (DMA).

[0017] In some embodiments, the plurality of operating systems run in a virtualization environment provided by the host operating system of the domain controller.

[0018] In some embodiments, the first operating system communicates with the second operating system through shared memory and semaphore mechanisms.

[0019] In some embodiments, the first fault data includes kernel space fault data and user space fault data of the first operating system, and the second fault data includes kernel space fault data and user space fault data of the second operating system, wherein the kernel space fault data includes hardware fault data and driver fault data, and the user space fault data includes application layer fault data and framework layer fault data.

[0020] Secondly, the present invention proposes a diagnostic method, the method comprising: receiving first fault data transmitted by a first operating system; and performing self-diagnosis on a second operating system to obtain second fault data.

[0021] In some embodiments, the method further includes: integrating the first fault data and the second fault data.

[0022] In some embodiments, the method further includes: transmitting the first fault data and the second fault data to a processor for storage.

[0023] In some embodiments, the method further includes: receiving and responding to diagnostic requests sent by an external diagnostic device through the first operating system.

[0024] In some embodiments, the method further includes: synchronizing response information for the diagnostic request to a remote terminal.

[0025] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by an executor, it implements the diagnostic method described in the second aspect of the embodiments.

[0026] Fourthly, embodiments of the present invention provide a computer program product, the computer program product including computer instructions, which, when executed by an executor, implement the diagnostic method described in the second aspect of the embodiments.

[0027] Fifthly, embodiments of the present invention provide a control chip for performing the diagnostic method described in the second aspect of the embodiments.

[0028] In a sixth aspect, embodiments of the present invention provide a vehicle comprising: the diagnostic system described in the first aspect embodiment, and / or, the computer program product described in the fourth aspect, and / or, the control chip described in the fifth aspect embodiment.

[0029] The diagnostic system, diagnostic method, storage medium, program product, and vehicle of this invention involve a first operating system performing self-diagnosis to obtain first fault data and transmitting the first fault data to a second operating system; the second operating system then performs self-diagnosis to obtain second fault data and receives the first fault data transmitted by the first operating system. This enables the diagnosis of multiple operating systems, and by centralizing the fault data of multiple operating systems, data silos can be broken down, achieving unified management of fault data from multiple operating systems.

[0030] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0031] Figure 1 This is a structural block diagram of a diagnostic system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the architecture of a diagnostic system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the architecture of a diagnostic system according to another embodiment of the present invention; Figure 4 This is a timing diagram of single-domain kernel layer fault data monitoring according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a diagnostic system according to another embodiment of the present invention; Figure 6 This is a flowchart of a dual-domain fault data collection process according to an embodiment of the present invention; Figure 7 This is a flowchart of an Ethernet diagnostic process according to an embodiment of the present invention; Figure 8 This is a flowchart of a diagnostic method according to an embodiment of the present invention; Figure 9 This is a structural block diagram of a vehicle according to an embodiment of the present invention. Detailed Implementation

[0032] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0033] The diagnostic system, method, storage medium, program product, control chip, and vehicle of the present invention are described below with reference to the accompanying drawings.

[0034] Figure 1 This is a structural block diagram of a diagnostic system according to an embodiment of the present invention.

[0035] like Figure 1 As shown, the diagnostic system 100 includes: multiple operating systems ( Figure 1 (The example uses two operating systems). The multiple operating systems include at least: a first operating system 10 and a second operating system 20. The first operating system 10 is used to perform self-diagnosis to obtain first fault data and transmit the first fault data to the second operating system 20; the second operating system 20 is used to perform self-diagnosis to obtain second fault data and receive the first fault data transmitted by the first operating system 10.

[0036] The first operating system 10 and the second operating system 20 can each be one or more. When there are multiple second operating systems 20, an intermediate operating system can be selected. Each first operating system 10 can send its first fault data to the intermediate operating system, and the second operating systems 20 other than the intermediate operating system can also send their respective second fault data to the intermediate operating system. The first operating system 10 and the second operating system 20 can be selected as needed, and there is no limitation here. For example, among the two operating systems, the first operating system 10 can be a trusted and highly secure operating system, such as the Qnx system; the second operating system 20, especially the second operating system as the intermediate operating system, can be an operating system with high interaction requirements, such as the Android system.

[0037] The diagnostic system 100 can diagnose multiple operating systems and, by centralizing the first fault data and the second fault data together, can break down data silos and achieve unified management of fault data from multiple operating systems.

[0038] In one implementation, each operating system is the host operating system of an electronic control unit (ECU) or domain controller.

[0039] In this implementation, by centralizing the fault data of multiple host operating systems, unified management of fault data can be achieved, which facilitates correlation analysis during subsequent diagnosis.

[0040] As another implementation, multiple operating systems run within a virtualized environment provided by the host operating system (which can run one or more applications) of a domain controller (such as a vehicle's cockpit domain controller, powertrain domain controller, etc.).

[0041] In this embodiment, such as Figure 2As shown, the virtualization environment provided by the host operating system can be implemented based on a SoC (System-on-a-Chip). Multiple operating systems can specifically run on multiple virtual machines (VMs) within this virtualization environment, and these VMs can communicate with each other across domains. The SoC can integrate physical hardware resources such as CPU (Central Processing Unit) cores, memory, GPU (Graphics Processing Unit), and I / O devices. These physical hardware resources can be virtualized using a hypervisor and securely allocated to each VM. The multiple operating systems can include at least two of Android, Linux, and Qnx systems. For example, there are three virtual machines, labeled VM1, VM2, and VM3. VM1 runs an Android system, allocated 4 CPU cores + memory + dedicated GPU resources, and is responsible for the central control screen, entertainment applications, voice assistant, third-party app store, etc. VM2 runs a Linux system, allocated 2 CPU cores + isolated GPU layer, and is responsible for graphics rendering with high security and real-time requirements, such as digital dashboard and autonomous driving information display. VM3 runs a Qnx system, allocated 1 CPU core, and is responsible for tasks such as gateway, vehicle network communication, diagnostic management, and functional safety. The first operating system 10 can be a trusted and highly secure operating system, such as VM3 mentioned above, and the second operating system 20 can be VM1 and / or VM2 mentioned above.

[0042] It's important to note that if only one application runs on the host operating system of a domain controller, the utilization of its physical hardware resources, such as CPU and memory, is typically extremely low, resulting in significant waste of power, space, and money. However, by running multiple virtual machines on the domain controller, hardware utilization can be increased to 70% or even higher. Running multiple applications on the host operating system of a domain controller can lead to software conflicts (such as DLL hell), and a security vulnerability or crash in one application could cause the entire domain controller to crash. By running multiple virtual machines on the domain controller, there is hardware-level isolation between the virtual machines. Each virtual machine has its own independent operating system and virtual hardware, enabling fault isolation (i.e., a blue screen or crash in one virtual machine will not affect other virtual machines) and security isolation (i.e., if one virtual machine is compromised, it is difficult to penetrate the hypervisor to attack other virtual machines due to isolation). Furthermore, virtualization environments offer advanced features that are difficult to achieve with traditional physical hardware. For example, snapshots and backups of the entire virtual machine (including its operating system, applications, and data) can be easily created, with recovery speeds far exceeding traditional file-based backups.

[0043] Correspondingly, when the host operating system performs direct diagnostics, all applications, services, and processes share the same kernel, memory pool, and hardware drivers. A crash in one application (such as a memory leak or infinite loop) can easily lead to system instability or even a system crash. In virtualization, each operating system is encapsulated in an independent virtual machine. A crash in the kernel of one operating system (such as a Windows blue screen) only affects that virtual machine itself and will not cause the host operating system or other virtual machines to crash. Direct diagnostics on the host operating system are highly complex and noisy. When system performance issues occur (such as high CPU usage or insufficient memory), tools like Task Manager and Performance Monitor need to be used on the same system for troubleshooting. However, data from all processes is mixed together, making it difficult to quickly pinpoint the root cause process. In virtualization, the hypervisor's management interface (such as vCenter) provides a clear top-level view, immediately showing which virtual machine's CPU, memory, or disk I / O usage is abnormal, greatly narrowing the scope of troubleshooting. When diagnosing directly from the host operating system, if a bug is difficult to reproduce, it's challenging to build an identical test environment without impacting the production environment. In virtualization, any virtual machine can be easily cloned or snapshotted, instantly creating a copy perfectly identical to the production environment for testing and debugging without purchasing new hardware or performing complex system installations. Therefore, compared to diagnosing directly from the host operating system, using multiple operating systems running in a virtualized environment not only optimizes resource utilization but also provides a more structured and streamlined diagnostic approach.

[0044] Based on this, the present invention also centralizes the fault data of multiple operating systems running in a virtualized environment, breaking down data silos and achieving unified management of fault data from multiple operating systems. Furthermore, compared to non-virtualized implementations, see [link to related documentation]. Figure 2 The virtualization implementation can also use any second operating system 20 as the first operating system 10 when all the first operating systems 10 fail; and use any first operating system 10 as the second operating system 20 when all the second operating systems 20 fail.

[0045] In some embodiments of the present invention, the second operating system 20 can also be used to integrate and process the second fault data and the first fault data.

[0046] Integrating the second fault data with the first fault data can include: synchronizing the second fault data with the first fault data in time, i.e., aligning the two fault data onto a unified time axis; fault data that cannot be aligned can be directly filtered out as illegal or invalid fault entries; selecting a suitable data structure model to store the time-synchronized fault data, such as a wide table model (each row represents a unique time point, and each column represents a signal or a fault state (0 indicates no fault, 1 indicates a fault)), to facilitate correlation analysis between the two fault data (specifically, time correlation analysis can be used (based on expert-defined rules, such as "if a fault code in the first fault data is 1, and a fault code in the second fault data is 1, then the two operating system faults are correlated"), statistical analysis (such as calculating correlation coefficients), machine learning methods (such as cluster analysis), etc.). Thus, the integrated fault data can be obtained.

[0047] The integrated fault data can be stored in the second operating system 20, or transferred to the first operating system 10 for storage, or sent to other devices for storage, in order to avoid fragmentation of diagnostic information caused by scattered storage and improve fault location efficiency.

[0048] For example, in a virtualized implementation, the second operating system 20 communicates with the first operating system 10 via shared memory and semaphore mechanisms to transmit first fault data. This communication method integrates a cross-domain service call framework with a dedicated virtualization communication channel, overcoming the performance bottleneck of inter-domain communication in traditional virtualization platforms. It allows direct inter-process communication across isolated domains, bypassing the traditional network protocol stack of the operating system (such as TCP / IP), thereby eliminating protocol parsing overhead. In a virtualized environment, this communication method exchanges data through a controlled memory access mechanism, circumventing physical network bandwidth limitations and achieving millisecond-level latency inter-domain data transmission.

[0049] In practical applications, the logical domain identifier addressing mechanism and dynamic service discovery interface can be combined to further simplify communication topology configuration and support point-to-point direct communication between isolated domains. Under this architecture, the efficiency of synchronous transmission of dual-domain diagnostic data is improved to the millisecond level. Furthermore, this communication method uses a more closed and secure communication channel, effectively enhancing the diagnostic system's resistance to local attacks and improving the overall system security and reliability.

[0050] For example, the first fault data received by the second operating system 12 is in TLV format, where the Type field identifies the type of fault data, the Length field identifies the length of the fault data, and the Value field identifies the fault code. This facilitates identification by the second operating system 20.

[0051] For example, the first operating system 10 is also configured to: store the first fault data in a local database (such as an SQLite database) to ensure the integrity and traceability of the fault record.

[0052] Taking a virtualized implementation, and assuming the domain controller is a cockpit domain controller, the first operating system 10 and the second operating system 20 in the diagnostic system 100 cover the full-stack architecture of the vehicle's cockpit. For example... Figure 3 As shown, for ease of distinction, the first operating system 10 is designated as the Host domain, and the second operating system 20 as the Guest domain. The two domains collaboratively monitor fault status from the hardware driver layer to the application layer. At the software level, both the Host and Guest domains can include diagnostic service modules, fault code reporting modules, kernel fault monitoring modules, and cross-domain communication modules.

[0053] The diagnostic service module provides a unified, standardized diagnostic interface for both business and non-business modules within the operating system (through which diagnostic data can be received) and manages the entire lifecycle of diagnostic data. For non-business modules (hardware connection layer), it can monitor physical connection faults such as abnormal VSWR of 4G / WiFi (Wireless Fidelity) / GPS (Global Positioning System) antennas, USB (Universal Serial Bus) HUB handshake protocol failure, and TP (Touch Panel) capacitor matrix deviation. For business modules (functional logic layer), it can monitor anomalies such as 4G / WiFi chip communication interruptions, CRC (Cyclic Redundancy Check) failures in multi-view camera video streams, DMA (Direct Memory Access) transmission timeouts in image chips, and out-of-tolerance gyroscope data update cycles. Optionally, upon startup of the fault diagnosis system, all modules in the intelligent cockpit can be forced to report their initial status.

[0054] The fault code reporting module can provide standardized fault reporting interfaces for each functional unit, such as SDK (Software Development Kit) interfaces. See also... Figure 2The application layer and framework layer modules report fault data through this interface. Faults in the application layer and framework layer can be transmitted through IPC (Inter-Process Communication). In the Guest domain, the framework layer service can also be connected through the Binder mechanism to ensure the consistency of the diagnostic interface behavior between the two domains.

[0055] The kernel fault monitoring module is used to monitor fault events in the corresponding domain's hardware driver layer in real time. The kernel fault monitoring module continuously listens to netlink (see...). Figure 2 Once the channel captures the reported fault data, it performs real-time analysis (extracting information such as DTC, status, timestamp, and detailed parameters), and then passes the analyzed structured data to the diagnostic service module for further processing.

[0056] The cross-domain communication module constructs a dual-domain data channel based on shared memory and semaphore mechanisms. Zero-copy technology is employed to achieve low-latency transmission of diagnostic data from the Guest domain to the Host domain, with data transmission latency down to the millisecond level. Data encapsulation follows a custom TLV format.

[0057] The following is combined with Figure 4 The process of monitoring single-domain kernel fault data is described using the Host domain as an example: like Figure 4 As shown, in the Host domain kernel layer fault data monitoring process, the kernel first establishes a real-time monitoring channel through a netlink socket. This mechanism actively captures hardware fault signals using the kernel event notification mechanism. When a fault code is detected, the kernel directly reports a diagnostic data packet containing key information such as fault type, fault status, and fault description to the user-space fault code monitoring thread using a predefined netlink message format.

[0058] The defined structure is as follows: Typedef struct{ unsigned int status; / / 0 for normal, 1 for abnormal unsigned int version; / / Version, for compatibility purposes unsigned int dtc_type; / / Fault code char desc

[256] ; / / Event details } dtc_event; typedef struct{ unsigned int req_type; / / 0 for connection 1 to obtain cachedmDTC char desc

[100] ; / / Information } dct_req; typedef struct _dct_msg_info { struct nlmsghdr hdr; dtc_event msgs

[1000] ; } dct_msg_info; After completing initialization, the fault code monitoring thread passes diagnostic processing tasks to a dedicated data processing thread via an asynchronous task queue. This thread first performs atomic database operations, persistently storing the fault codes and their metadata in a transactional manner in the local database. Subsequently, the data processing thread notifies the Guest domain's diagnostic service module via cross-domain communication, and ultimately, the Guest domain's diagnostic service module completes the integration and processing of the fault data.

[0059] Therefore, this diagnostic system 100 constructs a complete fault detection system covering hardware, kernel layer, system framework layer, and application layer by deploying diagnostic solutions across regions and multiple layers. Diagnostic services deployed synchronously in the Host and Guest domains define refined detection items for both hardware and software environments: on the hardware side, it captures real-time anomalies in various vehicle hardware components, such as power supply anomalies, kernel layer driver anomalies, and custom fault information at the framework and application layers. By capturing anomalies across the entire chain from underlying hardware drivers to user interaction events in real time, it achieves efficient collection of full-domain fault diagnostic data in the dual-domain architecture, thus providing reliable support for the maintenance and testing of the vehicle operating system and further improving system stability and reliability.

[0060] In some embodiments of the present invention, such as Figure 3 , Figure 5 As shown, the diagnostic system 100 also includes a processor 30, which is used to receive and store first fault data and second fault data transmitted by the second operating system 20.

[0061] In one implementation, the second operating system 20 can directly transmit the first fault data and the second fault data to the processor 30 for storage. Compared to each operating system transmitting its own fault data to the processor for storage separately, this invention first transmits the first fault data to the second operating system 20 via the first operating system 10, and then the second operating system 30 transmits the first fault data and the second fault data to the processor 30 for storage. This reduces the total number of accesses to the processor 30, lowers storage latency, saves bandwidth, reduces coordination overhead, and avoids conflicts and interference during multi-path data transmission.

[0062] As another implementation location, the second operating system 20 can transfer the integrated first fault data and second fault data to the processor 30 for storage.

[0063] In this embodiment, the kernel of the second operating system 20 has better computing power than the processor 30 (such as a microprocessor MCU), and is better able to handle data integration tasks. Compared with the direct transmission in the above embodiment, this embodiment first integrates fault data by the second operating system 20 with better computing power, which can reduce data transmission overhead, reduce processing delay, and avoid overloading the processor 30.

[0064] For example, the second operating system 20 communicates with the processor 30 via SPI (Serial Peripheral Interface).

[0065] The processor 30 can support DMA (Direct Memory Access) for data transfer, so that the second operating system 20 can directly send the first fault data and the second fault data to the storage space for storage, thereby reducing the load.

[0066] As one implementation method, see Figure 2 The Guest domain also includes a forwarding module, which encodes the first and second fault data into an SPI frame format (containing a 16-bit DTC code, an 8-bit status value, and a 32-bit timestamp) and transmits it to the processor 30. During the transmission of the first and second fault data, CRC-32 verification can be enabled to ensure the integrity of the data transmission.

[0067] See Figure 2 The processor 30 includes an SPI protocol communication module and a storage module (such as a non-volatile memory area).

[0068] The SPI protocol communication module communicates with the second operating system 20 to receive first and second fault data sent by the second operating system 20. This data is transmitted at the physical layer. Afterward, the SPI protocol communication module sends the first and second fault data to the storage module for storage, facilitating subsequent querying and management.

[0069] For example, the first fault data includes kernel space fault data and user space fault data of the first operating system 10, and the second fault data includes kernel space fault data and user space fault data of the second operating system 20. The kernel space fault data includes hardware fault data and driver fault data, and the user space fault data includes application layer fault data and framework layer fault data.

[0070] Specifically, such as Figure 6As shown, taking the virtualization implementation as an example, after the diagnostic system 100 starts, the Host domain and Guest domain independently complete the initialization of their respective core functional modules. After initialization, the two domains then enter a parallel fault monitoring process through their respective monitoring units. This monitoring process is carried out in the kernel space and user space of the two domains respectively. The kernel space focuses on monitoring faults related to the underlying hardware and kernel drivers. The monitored fault data is reported in real time to the fault listening thread in the user space through the efficient netlink interface. The user space monitors faults at the framework layer and application layer (such as services and applications). These faults are reported to the fault listening thread in the user space through a dedicated diagnostic SDK interface. The fault reporting interface can be defined as sendDiagnosticData(int DTC, int state), where DTC represents the diagnostic fault code and state indicates the fault status.

[0071] See Figure 6 After collecting the first fault data, the Host domain performs two key operations: first, persistent storage, writing the collected first fault data to a local database for long-term preservation; second, cross-domain transmission, utilizing the high-performance cross-domain communication mechanism of rpcbinder + vSock based on virtual shared memory to transmit the first fault data to the Guest domain's diagnostic service module. The Guest domain's diagnostic service module also acts as a data aggregation and processing hub. It first performs data fusion, receiving data transmitted from the Host domain and integrating it with data reported by the Guest domain itself, while strictly filtering out illegal or invalid fault entries. Finally, the integrated valid fault data is reliably transmitted to processor 30 via the SPI protocol, completing the entire multi-domain collaborative fault data collection and reporting process.

[0072] In some embodiments of the present invention, such as Figure 2 , Figure 7 As shown, the kernel of the first operating system 10 is adapted to communicate with external diagnostic devices, and the first operating system 10 is also used to: receive and respond to diagnostic requests sent by external diagnostic devices.

[0073] For example, the first operating system 10 communicates with external diagnostic devices via the Ethernet DoIP (Diagnostic communication over Internet Protocol) protocol stack.

[0074] Specifically, see Figure 3The first operating system 10 also includes an Ethernet DoIP protocol stack module. This module can perform ISO 13400 protocol parsing and encapsulation, establishing a diagnostic channel compliant with ASAM (Association for Standardization of Automation and Measuring Systems) standards. This module can also be used for basic communication, managing vehicle claims, route activation, and network heartbeat layers; parsing or generating the seven categories of services in the UDS (Unified Diagnostic Services) protocol; security control, handling the key negotiation process for secure access services; and anomaly handling, generating NRC (Negative Response Code) error codes in real time and recording protocol layer anomaly events. Ethernet diagnostics can improve the efficiency of vehicle maintenance and inspection.

[0075] In one implementation, the first operating system 10 is specifically used to: query the processor 30 to obtain the fault data corresponding to the fault code request when the diagnostic request is a fault code reading request, and feed back the obtained fault data to the external diagnostic device.

[0076] In another implementation, the first operating system 10 is specifically used to: when the diagnostic request is a fault clearing request, notify the processor 30 to perform a clearing operation on the fault data corresponding to the fault clearing request, and forward the operation confirmation information fed back by the processor 30 to the external diagnostic device.

[0077] As another implementation, the first operating system 10 can also be used to: when the fault data corresponding to the diagnostic request is the first fault data, perform the operation corresponding to the diagnostic request on the local database, and feed back the operation confirmation information to the external diagnostic device.

[0078] For example, the processor 30 may use full-duplex communication mode (such as CPOL=1, CPHA=1) to communicate with the kernel of the first operating system 10 and the kernel of the second operating system 20 respectively.

[0079] See Figure 3 The Host domain also includes a read module, which reads necessary data from the processor 30's storage module via the SPI bus, such as global diagnostic snapshots and fault data corresponding to fault code requests. CRC-32 verification can be enabled during data transfer to ensure data integrity.

[0080] See Figure 3The processor 30 also includes a control engine module, which can respond to diagnostic requests forwarded by the first operating system 10, such as reading the requested fault data from the storage module and sending it to the first operating system 10 via the SPI protocol communication module, or clearing the fault data corresponding to the fault clearing request from the storage module.

[0081] In some embodiments of the present invention, the first operating system 10 is further configured to: synchronize response information to the diagnostic request to the second operating system 20, so that the second operating system 20 updates the status view and can provide a basis for remote terminal reporting, thereby improving the scalability of the system.

[0082] In this embodiment, the kernel of the second operating system 30 is adapted to communicate with a remote terminal (such as the cloud), and the second operating system 30 is also used to: synchronize response information for the diagnostic request to the remote terminal.

[0083] See in some examples Figure 7 When an external diagnostic device initiates a DoIP request via Ethernet, the Host domain, acting as the sole access point, receives and parses the request using its built-in Ethernet DoIP protocol stack module. For the parsed fault code read request, the Host domain directly queries the processor 30 via the SPI protocol to obtain the corresponding fault data from its storage module. For the parsed fault clearing command, the Host domain also notifies the processor 30 via SPI to execute a fault state reset. During the above query and notification process, the Host domain also synchronizes key operation logs and results (such as the list of read fault codes or clearing status) to the Guest domain's diagnostic service module via rpcbinder+vSock, providing a basis for updating the status view and cloud reporting, thereby improving system scalability. Afterwards, the Host domain directly feeds back the encapsulated diagnostic response (including data returned by the processor 30 or operation confirmation) to the external diagnostic device via its DoIP protocol stack. This forms a closed-loop diagnostic process with the Host domain as the processing center, the processor 30 as the data storage / execution unit, and the Guest domain as the status monitor.

[0084] The diagnostic system 100 of this embodiment constructs a centralized data routing: the Guest domain uniformly collects dual-domain fault diagnosis data and forwards it to the processor 30 through a secure channel; the Host domain implements a DoIP server, serving as the entry point for Ethernet diagnostic commands. External diagnostic requests are all processed by the Host domain, and the diagnostic service of the Host domain interacts with the processor 30 to obtain dual-domain diagnostic data. This achieves functional decoupling, improves system stability, with the Guest domain focusing on fault diagnosis data collection and processing, and the Host domain responsible for Ethernet network communication and responding to diagnostic requests. Furthermore, Ethernet diagnostic requests are directly processed by the Host domain, eliminating the need for cross-domain forwarding and shortening response time. The processor 30 uniformly stores fault diagnosis data from both the Guest and Host domains, avoiding fragmentation of diagnostic information caused by distributed storage and improving fault location efficiency.

[0085] Figure 8 This is a flowchart of a diagnostic method according to an embodiment of the present invention.

[0086] In this embodiment, the diagnostic method is used in the second operating system 20 described above. For example... Figure 8 As shown, the diagnostic methods include: S11, receive the first fault data transmitted by the first operating system.

[0087] S12, perform self-diagnosis on the second operating system to obtain second fault data.

[0088] It should be noted that steps S11 and S12 are not in any particular order.

[0089] In some embodiments of the present invention, the method further includes: integrating the first fault data and the second fault data.

[0090] In some embodiments of the present invention, the diagnostic method further includes: transmitting first fault data and second fault data to a processor for storage.

[0091] In some embodiments of the present invention, the diagnostic method further includes: receiving and responding to a diagnostic request sent by an external diagnostic device through a first operating system.

[0092] In some embodiments of the present invention, the method further includes: synchronizing response information for a diagnostic request to a remote terminal.

[0093] It should be noted that for other specific implementations of the diagnostic method of the present invention, please refer to the specific implementation of the diagnostic system 100 in the above embodiments.

[0094] Based on the diagnostic system method of the above embodiments, the present invention proposes a computer-readable storage medium.

[0095] In this embodiment, a computer program is stored on a computer-readable storage medium, and when the computer program is executed by an executor, it implements the diagnostic method of the above embodiment.

[0096] Based on the diagnostic system method of the above embodiments, the present invention also proposes a computer program product.

[0097] In this embodiment, the computer program product includes computer instructions, which, when executed by an executor, implement the diagnostic method described in the above embodiment.

[0098] Based on the diagnostic system method of the above embodiments, the present invention also proposes a control chip.

[0099] In this embodiment, the control chip is used to execute the diagnostic method described in the above embodiment.

[0100] Figure 9 This is a structural block diagram of a vehicle according to an embodiment of the present invention.

[0101] like Figure 9 As shown, vehicle 1000 includes the diagnostic system 100 of the above embodiment.

[0102] In some embodiments of the present invention, vehicle 1000 includes the computer program product described above, and / or, a control chip.

[0103] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0104] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0105] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0106] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0107] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0108] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0109] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0110] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A diagnostic system, characterized in that, include: Multiple operating systems, wherein the multiple operating systems include at least a first operating system and a second operating system; The first operating system is used to perform self-diagnosis to obtain first fault data and transmit the first fault data to the second operating system; The second operating system is used to perform self-diagnosis to obtain second fault data and to receive the first fault data transmitted by the first operating system.

2. The diagnostic system according to claim 1, characterized in that, The second operating system is also used for: The first fault data and the second fault data are integrated and processed.

3. The diagnostic system according to claim 1, characterized in that, The system also includes: The processor is configured to receive and store the first fault data and the second fault data transmitted by the kernel of the second operating system.

4. The diagnostic system according to claim 3, characterized in that, The kernel of the first operating system is adapted to communicate with external diagnostic devices, and the first operating system is also used for: Receive and respond to diagnostic requests sent by the external diagnostic device.

5. The diagnostic system according to claim 4, characterized in that, The first operating system is specifically used for: When the diagnostic request is a fault code read request, the processor is queried to obtain the fault data corresponding to the fault code request, and the obtained fault data is fed back to the external diagnostic device.

6. The diagnostic system according to claim 4, characterized in that, The first operating system is specifically used for: When the diagnostic request is a fault clearing request, the processor is notified to clear the fault data corresponding to the fault clearing request, and the operation confirmation information fed back by the processor is forwarded to the external diagnostic device.

7. The diagnostic system according to claim 4, characterized in that, The first operating system is also used for: The first fault data is stored in the local database of the first operating system.

8. The diagnostic system according to claim 7, characterized in that, The first operating system is also used for: When the fault data corresponding to the diagnostic request is the first fault data, the operation corresponding to the diagnostic request is executed on the local database, and the operation confirmation information is fed back to the external diagnostic device.

9. The diagnostic system according to any one of claims 4-8, characterized in that, The first operating system is also used for: The response information for the diagnostic request is synchronized to the second operating system.

10. The diagnostic system according to claim 9, characterized in that, The kernel of the second operating system is adapted to communicate with remote terminals, and the second operating system is also used for: The response information for the diagnostic request will be synchronized to the remote terminal.

11. The diagnostic system according to any one of claims 4-8, characterized in that, The first operating system communicates with the external diagnostic device via the Ethernet DoIP protocol stack.

12. The diagnostic system according to any one of claims 3-8, characterized in that, The kernels of the first and second operating systems communicate with the processor via a serial peripheral interface.

13. The diagnostic system according to claim 12, characterized in that, The processor uses full-duplex communication mode to communicate with the kernels of the first operating system and the second operating system, and supports direct memory access (DMA) for data transfer.

14. The diagnostic system according to any one of claims 1-8, characterized in that, The multiple operating systems run within a virtualization environment provided by the host operating system of the domain controller.

15. The diagnostic system according to claim 14, characterized in that, The first operating system communicates with the second operating system through shared memory and semaphore mechanisms.

16. The diagnostic system according to claim 14, characterized in that, The first fault data includes kernel space fault data and user space fault data of the first operating system, and the second fault data includes kernel space fault data and user space fault data of the second operating system. The kernel space fault data includes hardware fault data and driver fault data, and the user space fault data includes application layer fault data and framework layer fault data.

17. A diagnostic method, characterized in that, The method includes: Receive first fault data transmitted by the first operating system; and Perform self-diagnosis on the second operating system to obtain second fault data.

18. The diagnostic method according to claim 17, characterized in that, The method further includes: The first fault data and the second fault data are integrated and processed.

19. The diagnostic method according to claim 17 or 18, characterized in that, The method further includes: The first fault data and the second fault data are transmitted to the processor for storage.

20. The diagnostic method according to claim 19, characterized in that, The method further includes: The first operating system receives and responds to diagnostic requests sent by external diagnostic devices.

21. The diagnostic method according to claim 20, characterized in that, The method further includes: The response information for the diagnostic request will be synchronized to the remote terminal.

22. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the executor, it implements the diagnostic method as described in any one of claims 17-21.

23. A computer program product, characterized in that, The computer program product includes computer instructions, which, when executed by an executor, implement the diagnostic method as described in any one of claims 17-21.

24. A control chip, characterized in that, Used to perform the diagnostic method as described in any one of claims 17-21.

25. A vehicle, characterized in that, include: The diagnostic system as described in any one of claims 1-16, and / or the computer program product as described in claim 23, and / or the control chip as described in claim 24.

Images