Vehicle Ethernet diagnosis method and system

Abstract

The invention discloses a vehicle Ethernet diagnosis method and system, and the method and system are applied to a master control system-on-chip, the master control system-on-chip comprises a main processor and a remote processor, and the main processor communicates with the remote processor through a remote processor message passing protocol. The method comprises the following steps: the main processor sends a diagnosis request to the remote processor through the remote processor message passing protocol, and the remote processor determines a communication component to be diagnosed and a corresponding diagnosis operation according to the diagnosis type information in response to the diagnosis request, the remote processor executes the diagnosis operation on the communication component to be diagnosed; the remote processor generates a diagnosis result according to the diagnosis operation; and the remote processor sends the diagnosis result to the main processor through the remote processor message passing protocol, so that a fault in a vehicle network can be accurately positioned.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a vehicle Ethernet diagnostic method and system. Background Art

[0002] Modern vehicles are typically equipped with multiple Electronic Control Units (ECUs), responsible for diverse functions such as engine control, body control, infotainment systems, and advanced driver assistance systems. These ECUs require extensive data exchange to enable collaborative operation. As the number of ECUs increases, so does the complexity of communication between them. Traditional vehicle buses (such as CAN and LIN) are limited in bandwidth, data transmission speed, and network topology flexibility, making them incapable of meeting these high data transmission demands.

[0003] With the increasing use of Ethernet in vehicles, ensuring network stability and reliability has become a critical issue. Network failures can disrupt data transmission between ECUs, impacting the vehicle's normal operation and safety. Therefore, effective monitoring and diagnostic mechanisms, tailored to the characteristics of Ethernet, are needed to promptly detect and resolve network failures and ensure the normal operation of vehicle systems. Summary of the Invention

[0004] The embodiments of the present application provide a vehicle Ethernet diagnostic method and system that can quickly and accurately locate faults in a vehicle network.

[0005] In a first aspect, an embodiment of the present application provides a vehicle Ethernet diagnostic method, which is applied to a main control system-on-chip, wherein the main control system-on-chip includes a main processor and a remote processor, and the main processor and the remote processor communicate via a remote processor messaging protocol. The method includes:

[0006] The main processor sends a diagnostic request to the remote processor through a remote processor messaging protocol, where the diagnostic request carries diagnostic type information;

[0007] In response to the diagnosis request, the remote processor determines the communication component to be diagnosed and the corresponding diagnostic operation according to the diagnosis type information, where the communication component to be diagnosed is used to implement Ethernet communication between the remote processor and the outside;

[0008] The remote processor performs a diagnostic operation on the communication component to be diagnosed, the diagnostic operation being used to determine whether the communication component to be diagnosed has a fault;

[0009] The remote processor generates a diagnostic result based on the diagnostic operation;

[0010] The remote processor sends the diagnostic results to the main processor via the remote processor messaging protocol.

[0011] In a second aspect, an embodiment of the present application provides a vehicle Ethernet diagnostic system, which is applied to a main control system-on-chip, wherein the main control system-on-chip includes a main processor and a remote processor, and the main processor and the remote processor communicate through a remote processor messaging protocol, wherein the main processor is configured to send a diagnostic request to the remote processor through the remote processor messaging protocol, and the diagnostic request carries diagnostic type information;

[0012] The remote processor is configured to respond to the diagnostic request and determine the communication component to be diagnosed and the corresponding diagnostic operation according to the diagnostic type information, wherein the communication component to be diagnosed is configured to implement Ethernet communication between the remote processor and the outside world;

[0013] a remote processor for performing a diagnostic operation on the communication component to be diagnosed, the diagnostic operation being used to determine whether the communication component to be diagnosed has a fault;

[0014] a remote processor for generating a diagnostic result based on the diagnostic operation;

[0015] The remote processor is configured to send diagnostic results to the main processor via a remote processor messaging protocol.

[0016] In a third aspect, an embodiment of the present application provides a vehicle Ethernet diagnostic device, which includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the above-mentioned vehicle Ethernet diagnostic method is implemented.

[0017] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the above-mentioned vehicle Ethernet diagnostic method is implemented.

[0018] In a fifth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the above-mentioned vehicle Ethernet diagnostic method.

[0019] In an embodiment of the present application, a communication bridge is established between the main processor and the remote processor through the remote processor messaging protocol, which can transmit information in a timely manner and avoid the impact of delays on fault location; the main processor initiates a diagnostic request for the communication component to be diagnosed, instructing the remote processor to determine the communication component to be diagnosed and the corresponding diagnostic operation, perform specific fault detection, and evaluate whether its function is normal; after performing the diagnostic operation, the remote processor analyzes and summarizes the results to form a clear diagnostic result; the remote processor messaging protocol is used to return the diagnostic result to the main processor to ensure that the main processor can obtain accurate and real-time diagnostic result information; that is, through real-time data exchange between the main processor and the remote processor, it can ensure that the vehicle responds quickly and accurately locates the problem when a fault occurs, thereby improving the performance, reliability and safety of the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 1 is a flow chart of a vehicle Ethernet diagnostic method provided by an embodiment of the present application;

[0022] Figure 2 This is a schematic diagram of a process for creating a remote processor message passing kernel driver device provided by an embodiment of the present application;

[0023] Figure 3 This is a schematic diagram of a diagnostic process provided by an embodiment of the present application;

[0024] Figure 4 It is a structural diagram of the vehicle Ethernet diagnostic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating the examples of the present application.

[0026] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0027] In order to solve the problems in the prior art, the embodiments of the present application provide a vehicle Ethernet diagnostic method and system. The vehicle Ethernet diagnostic method provided by the embodiments of the present application is first introduced below.

[0028] Figure 1 It is a flow chart of the vehicle Ethernet diagnostic method provided in an embodiment of the present application.

[0029] like Figure 1 As shown, Figure 1 The process includes the following steps S101 to S105.

[0030] This method is applied to the main control system-on-chip (SOC), a highly integrated wireless transceiver chip solution. The SOC includes multiple processors, including a main processor and a remote processor. The main control SOC chip integrates multiple network MAC peripherals. Each MAC port can be connected to an external PHY chip to achieve external Ethernet communication. The main processor and remote processor communicate using the remote processor message passing protocol.

[0031] S101: The main processor sends a diagnostic request to the remote processor through a remote processor messaging protocol.

[0032] The diagnosis request carries diagnosis type information.

[0033] The main processor is typically a more powerful processor that is responsible for the overall control and management of the system.

[0034] The Remote Processor Message Passing (RPMSG) protocol provides an inter-processor message passing mechanism that enables asynchronous and synchronous communication between a host processor and remote processors.

[0035] A remote processor is an auxiliary processor in the system that is used to perform specific tasks such as signal processing, control tasks, etc.

[0036] In a multi-processor system, the main processor (usually an application processor) needs to communicate with remote processors (such as microcontrollers, DSPs, etc.) to perform diagnostic tasks.

[0037] A diagnostic request is a request message used to diagnose whether there are faults in the physical layer and data link layer of a vehicle network. The diagnostic request contains information such as the request type, target address, and data length.

[0038] As an example and not limitation, the diagnostic request may include the link status of the Media Access Control (MAC) interface, the link status of the physical layer interface chip (PHY) interface, the number of sent and received messages of the MAC interface, the number of sent and received messages of the PHY chip, the quality of the cable connecting the PHY chip and the other end, etc.

[0039] S102 : In response to the diagnosis request, the remote processor determines the communication component to be diagnosed and the corresponding diagnosis operation according to the diagnosis type information.

[0040] The communication component to be diagnosed is used to implement Ethernet communication between the remote processor and the outside. As an example and not limitation, the communication component to be diagnosed can be a component that reflects whether there is a fault in the physical layer and data link layer of the vehicle network, such as a MAC interface, a PHY chip, etc.

[0041] As can be understood, the MAC layer is the second layer in the Open Systems Interconnection (OSI) model. The MAC layer is responsible for establishing, maintaining, and terminating data link connections on the physical medium.

[0042] It can be understood that the PHY chip (Physical Layer Interface Chips) is a key component in network communication. It is responsible for implementing the functions of the first layer in the OSI model, namely the physical layer.

[0043] S103: The remote processor performs a diagnostic operation on the communication component to be diagnosed.

[0044] The diagnostic operation is used to determine whether there is a fault in the communication component to be diagnosed.

[0045] It can be understood that the remote processor receives the diagnostic request sent by the main processor, parses the content of the diagnostic request, extracts the specific content of the request, such as the identification of the communication component to be diagnosed, the type of diagnostic operation to be performed, etc., determines which diagnostic operations need to be performed, that is, performs corresponding diagnostic operations on the communication component to be diagnosed according to the content of the request.

[0046] By way of example and not limitation, a diagnostic operation can involve the remote processor invoking a corresponding diagnostic function based on the request, or executing specific diagnostic code. During the diagnostic operation, the remote processor collects diagnostic data. This data includes hardware status, sensor readings, error logs, and more.

[0047] As an example and not a limitation, if diagnostic data needs to be read, the data is read from the relevant PHY chip or MAC control unit; if diagnostic parameters need to be set, the parameters are written into the corresponding control unit.

[0048] Specific diagnostic operations vary depending on different application scenarios and are not listed here one by one.

[0049] S104: The remote processor generates a diagnosis result according to the diagnosis operation.

[0050] The diagnosis result is used to indicate whether the communication component to be diagnosed has a fault, which is concluded after the communication component to be diagnosed is diagnosed according to the diagnosis operation.

[0051] The diagnostic results may include the unique identifier of the communication component to be diagnosed (such as the ID of the communication component to be diagnosed, the serial number of the communication component to be diagnosed, etc.), the status of the communication component to be diagnosed (such as normal status, faulty status, unknown status), performance data of the communication component to be diagnosed, the error log corresponding to the communication component to be diagnosed, and other information.

[0052] For example, the communication component to be diagnosed is a MAC interface, the diagnostic operation may be to diagnose the link status of the MAC interface, and the corresponding diagnostic result may be that the link status of the MAC interface is normal.

[0053] For another example, the communication component to be diagnosed is a PHY interface, the diagnostic operation may be to diagnose the link status of the PHY interface, and the corresponding diagnostic result may be that the link status of the PHY interface is a fault state.

[0054] It is understandable that, depending on the communication component to be diagnosed, the corresponding diagnostic results are also different, and they are not listed here one by one.

[0055] S105 : The remote processor sends the diagnosis result to the main processor through the remote processor message transmission protocol.

[0056] In combination with the above, when the remote processor completes the diagnostic operation and obtains the diagnostic results, it can encapsulate the diagnosis into a message and send the encapsulated diagnostic results back to the main processor through the remote processor messaging kernel driver (Remote Processor Messaging KernelDriver, rpmsg-kdrv) device (which can also be understood as the RPMSG module).

[0057] It can also be understood that during the diagnosis process, the main processor can send different types of diagnostic requests to the remote processor as needed. The remote processor performs corresponding operations based on the received diagnostic requests and returns the diagnostic results to the main processor via the RPMSG protocol.

[0058] A communication bridge is established between the main processor and the remote processor through the remote processor messaging protocol, which can transmit information in a timely manner and avoid the impact of delays on fault location; the main processor initiates a diagnostic request for the communication component to be diagnosed, instructing the remote processor to determine the communication component to be diagnosed and the corresponding diagnostic operation, perform specific fault detection, and evaluate whether its function is normal; after performing the diagnostic operation, the remote processor analyzes and summarizes the results to form a clear diagnostic result; the remote processor messaging protocol is used to return the diagnostic result to the main processor to ensure that the main processor can obtain accurate and real-time diagnostic result information; that is, through real-time data exchange between the main processor and the remote processor, it can ensure that the vehicle responds quickly and accurately locates the problem when a fault occurs, thereby improving the performance, reliability and safety of the vehicle.

[0059] In one implementation, the main processor runs a Linux operating system, the remote processor runs a real-time operating system, and a remote processor message passing kernel driver device is created in the main processor and the remote processor, including: the main processor starts a boot program, and the boot program is used to control the startup of the remote processor; under the control of the boot program, the remote processor loads Ethernet firmware and performs Ethernet firmware initialization operations, wherein the initialized Ethernet firmware is used to create a remote processor message passing kernel driver device; the remote processor creates a remote processor message passing kernel driver device in the main processor and the remote processor according to the remote processor message passing kernel driver protocol.

[0060] As you can see from the above, the main processor is the central processing unit responsible for running the Linux operating system, and typically has strong computing power and high processing capabilities. The remote processor is usually a real-time processor responsible for handling real-time tasks and is suitable for application scenarios with high latency requirements.

[0061] A real-time operating system (RTOS) is an operating system suitable for real-time applications, with determinism and high response speed.

[0062] A boot loader is software used to initialize and start the operating system or firmware to ensure that the system can start normally.

[0063] Ethernet firmware refers to the firmware running on the remote processor, which is responsible for the implementation of network communication and usually contains the code of the network protocol stack.

[0064] The Remote Processor Messaging Kernel Driver (rpmsg-kdrv) is a kernel driver used to communicate between different processor cores in the Linux operating system. It is implemented based on the Virtio framework and is specifically designed for inter-core communication in heterogeneous multi-core processing systems.

[0065] Creating a remote processor messaging kernel driver in both the main and remote processors creates a stable, bidirectional communication channel, enabling the main and remote processors to send and receive messages, such as for real-time monitoring, fault diagnosis, and control command transmission. This communication mechanism supports asynchronous processing, enabling messages to be sent and processed even when an immediate response is not required. Furthermore, it allows multiple tasks or threads to interact simultaneously through messaging, improving data processing efficiency.

[0066] At startup, the main processor loads the RPMSG kernel driver and initializes related hardware resources. Similarly, the remote processor also initializes its RPMSG module and prepares to receive messages from the main processor.

[0067] It is understood that during the communication process, both the main processor and the remote processor initialize the RPMSG module, and the rpmsg-kdrv device can be created in the RPMSG module. The main processor packages the message to be sent (diagnostic request) into a data packet and transmits the message to the remote processor via the rpmsg-kdrv device (which can also be understood as the RPMSG module). After receiving the message, the remote processor processes it. If a response is required, the remote processor can return the response message to the main processor via the rpmsg-kdrv device (which can also be understood as the RPMSG module).

[0068] In other words, the remote processor messaging kernel driver device (rpmsg-kdrv device) can also be understood as a driver provided in the operating system that allows interaction between the device and the kernel; it can also be understood as a software component used to implement message sending and receiving between the main processor and the remote processor, usually divided into multiple devices to support different communication channels.

[0069] The main processor starts the bootloader, which is responsible for initializing the main processor and controlling the startup of the remote processor. Alternatively, the bootloader executes on the main processor and initializes and configures the remote processor through a hardware interface or protocol (such as JTAG or a serial port) to ensure it can receive commands. Under the control of the bootloader, the remote processor loads the Ethernet firmware and initializes it to prepare for subsequent network communication. The Ethernet firmware implements the RPMSG protocol, enabling the main and remote processors to exchange messages over the network. The creation of the rpmsg-kdrv device enables the respective operating systems to call this interface to read, write, and process data.

[0070] This method enables the main processor and remote processor to work together. In other words, through the cooperation of the bootloader and Ethernet firmware, effective communication between the two is achieved, ensuring that the system can run stably and in real time in a multi-processor environment.

[0071] In one implementation, a remote processor message passing kernel driver device includes a first remote processor message passing kernel driver device and a second remote processor message passing kernel driver device; the remote processor creates a remote processor message passing kernel driver device in a main processor and a remote processor according to a remote processor message passing kernel driver protocol, including: the main processor creates a virtual I / O device, and the virtual I / O device is used to interact with Ethernet firmware; the virtual I / O device uses a virtual I / O device remote processor message passing bus driver to detect whether the first remote processor message passing kernel driver device is created in the remote processor; and when it is detected that the first remote processor message passing kernel driver device is created in the remote processor, a second remote processor message passing kernel driver device is created in the main processor.

[0072] The first remote processor message transmission kernel driver device can be understood as a driver program implemented on the remote processor for mainly receiving and sending messages.

[0073] The second remote processor message passing kernel driver device can be understood as a driver implemented on the main processor, which is intended to interact with the first remote processor message passing driver.

[0074] Virtual I / O Device (Virtio) is a paravirtualization technology used primarily in virtual machines and virtualized environments to improve I / O device performance. It provides a standardized interface that allows front-end drivers in virtual machines to communicate efficiently with back-end devices on the host machine. Virtio's primary goal is to reduce cross-platform compatibility issues and improve driver development efficiency.

[0075] The Virtual I / O Device Remote Processor Messaging Bus (virtio_rpmsg_bus) driver is the driver responsible for managing the communication and interaction between the Virtual I / O Device and the Remote Processor Messaging Device.

[0076] As you can see, the host processor interacts with the Ethernet firmware by creating a virtual I / O device, providing a unified interface for the operating system. The virtual I / O device acts as a logical device on the host processor, and the driver is responsible for handling calls to the Ethernet firmware, such as sending and receiving messages.

[0077] The virtual I / O device uses a remote processor message passing bus driver to detect the remote processor and detect whether the remote processor has a first remote processor message passing kernel driver device. Once the first remote processor message passing kernel driver device of the remote processor is confirmed to be available, the main processor will create a second remote processor message passing kernel driver device.

[0078] In other words, the main processor registers the second driver device with the operating system kernel, enabling both parties to establish an effective data channel via the RPMSG protocol. This step ensures that the driver on the main processor can manage the communication with the remote processor.

[0079] By creating a second device corresponding to the first remote processor messaging kernel driver device, the host processor can effectively communicate bidirectionally with the remote processor, following the RPMSG protocol to ensure efficient and reliable delivery of information.

[0080] The above methods constitute the communication mechanism between the main processor and the remote processor through remote processor message passing, enabling the two processors to exchange data efficiently. Through virtual I / O devices and corresponding drivers, the system can dynamically detect and establish the necessary communication channels to support the needs of applications and real-time operating systems.

[0081] In one implementation, according to the boot program, the remote processor loads the Ethernet firmware and performs Ethernet firmware initialization operations, including: performing media access control layer initialization operations to configure the Ethernet media access control port; performing physical layer interface chip initialization operations to adapt the driver of the physical layer interface chip; performing media independent interface initialization operations, the media independent interface is used to support communication between the media access control layer and the physical layer; performing remote configuration service operations to remotely configure the Ethernet, and the Ethernet remote configuration service is implemented based on the inter-process communication mechanism.

[0082] Combining relevant principles, we can know that the Media Access Control (MAC) layer refers to a layer in the Ethernet protocol, which is responsible for controlling how to send and receive data frames on the network medium, handling address identification and data flow coordination.

[0083] A physical layer interface (PHY) chip is a hardware component responsible for converting between digital and analog signals, connecting network media (such as cables).

[0084] The Media Independent Interface (MII) is a standardized interface that allows communication between the MAC layer and the PHY chip to achieve flexible network hardware configuration.

[0085] Remote configuration service is a service that allows remote processors to configure and manage network parameters on an Ethernet network, usually involving remote management and settings through an inter-processor communication (IPC) mechanism.

[0086] The Inter-Processor Communication (IPC) mechanism is a method for exchanging information between different processors (main processor and remote processors) to ensure efficient data transmission.

[0087] It is understood that the MAC layer is initialized so that it can capture, process, and send Ethernet data frames. By configuring registers, setting MAC addresses, and initializing frame queues, the MAC layer can begin monitoring network traffic and manage the sending and receiving of data packets.

[0088] As you can understand, configuring an Ethernet media access control port sets specific network interface parameters for the MAC layer. During initialization, network-related parameters such as speed, duplex mode (half-duplex or full-duplex), and flow control characteristics are set. These configurations affect data transmission efficiency and capacity.

[0089] As you can understand, initializing the physical layer interface chip configures the PHY chip to convert digital and analog signals. This step includes resetting the PHY chip, configuring its operating mode, and ensuring it can effectively connect to the MAC layer and network media. Typically, interaction with the PHY chip is done through protocols such as SPI or MDIO.

[0090] It is understood that the driver of the physical layer interface chip is adapted and loaded with the driver program related to the physical layer interface chip to achieve a higher level of management and control. The driver provides an interactive interface with the hardware, allowing the operating system or firmware to effectively control the settings of the PHY chip, monitor its status, and handle errors.

[0091] As you can understand, performing media independent interface initialization and setting up the MII facilitates communication between the MAC and PHY layers. Configuring the MII interface allows the MAC layer to interact with different types of PHY chips in a unified manner. The MII ensures hardware flexibility and allows for use in diverse network environments.

[0092] As can be appreciated, remote configuration service operations for remotely configuring Ethernet networks allow remote processors to dynamically configure network parameters via an IPC mechanism. Through the IPC interface, the remote processor can receive configuration instructions from the host processor, such as network address assignment and routing settings. This mechanism ensures clear command transmission and feedback in a multi-processing environment.

[0093] Together, these methods ensure the correct initialization of Ethernet hardware on the remote processor, enabling network connectivity. This specific hardware configuration or initialization enables the system to efficiently respond to network events and supports remote management and configuration via IPC mechanisms, enriching the system's functionality and reliability.

[0094] The following combination Figure 2 Let’s introduce the above methods in an overall way.

[0095] Figure 2 This is a flow chart of a process for creating a remote processor message passing kernel driver device provided by an embodiment of the present application. Figure 2 As shown, Figure 2 The process includes the following steps S201 to S210.

[0096] S201: The main processor starts the boot program.

[0097] When the system starts, the main processor first starts the bootloader.

[0098] S202: Load and start the remote processor according to the boot program control.

[0099] The bootloader first controls the remote processor to load the Ethernet firmware and then starts the remote processor.

[0100] S203: The main processor loads and runs the Linux operating system.

[0101] The main processor then loads and runs the Linux operating system.

[0102] S204: The remote processor configures the Ethernet MAC port.

[0103] S205: The remote processor adapts the driver of the PHY chip.

[0104] The remote processor loads the Ethernet firmware, configures the Ethernet MAC port in the Ethernet firmware, adapts the driver of the PHY chip, and sets the MII interface to ensure normal network data transmission.

[0105] In other words, the remote processor runs Ethernet firmware, which is an application based on FreeRTOS, a small real-time operating system kernel that provides rich features for embedded systems. The Ethernet firmware running on the remote processor acts as a central Ethernet processing unit, providing a remote configuration infrastructure for other processors running different operating systems.

[0106] S206: The remote processor creates an rpmsg-kdrv device and initializes the remote configuration service.

[0107] The Ethernet firmware supports the RPMSG-KDRV protocol and can create multiple RPMSG-KDRV devices that provide CPSW0 resource management and debugging services for each connected remote CPU.

[0108] For example, the firmware instantiates the rpmsg-kdrv device mpu_1_0_ethswitch-device-0, which creates a corresponding rpmsg-kdrv device on the main processor.

[0109] The Ethernet firmware initializes a remote configuration service that can remotely configure the Ethernet. The remote configuration service in the Ethernet firmware is implemented based on the IPC inter-core communication mechanism and can provide Ethernet services for remote processors such as Linux drivers.

[0110] S207: The main processor creates a Virtio device.

[0111] After the main processor starts the Linux operating system, it will perform a series of system driver initializations in the Linux system. Then the Linux kernel will create a default Virtio device for interacting with the firmware in the remote processor.

[0112] S208. The main processor detects the rpmsg-kdrv device in the remote processor.

[0113] The vitio_rpmsg_bus driver will detect the rpmsg-kdrv device on the remote processor side.

[0114] S209: The main processor creates an rpmsg-kdrv device.

[0115] If it is detected that the rpmsg device has been successfully created on the remote processor, a corresponding rpmsg-kdrv device will be created.

[0116] The host processor then announces the presence of the remote RPMSG service by sending a Name Service Announcement message containing the service name (i.e., device name), source address, and destination address. This message is processed by the RPMSG bus, which dynamically creates and registers an RPMsg device representing the remote service. Once the relevant RPMsg driver is registered, it is immediately detected by the bus and messages can be exchanged with the remote processor.

[0117] S210: The main processor creates an Ethernet device.

[0118] Finally, an Ethernet device is created on the main processor to provide a device interface for operating Ethernet for the diagnostic application on the main processor.

[0119] In conjunction with the above, during the diagnosis process, the main processor sends a diagnostic request to the remote processor via the Ethernet communication interface based on the diagnostic requirements. The diagnostic request contains information such as the request type, target address, and data length.

[0120] After receiving the diagnostic request, the remote processor performs the corresponding diagnostic operation based on the request type. If diagnostic data needs to be read, it reads the data from the relevant PHY chip or MAC control unit; if diagnostic parameters need to be set, they are written to the corresponding control unit.

[0121] The remote processor packages the execution results into RPMSG messages and returns them to the main processor through the Ethernet communication interface. After receiving the diagnosis results, the main processor parses and processes them.

[0122] In one implementation, in response to a diagnostic request, the remote processor determines the communication component to be diagnosed and the corresponding diagnostic operation based on the diagnostic type information, including: the remote processor reads target diagnostic data from the communication component to be diagnosed based on the diagnostic type information, the target diagnostic data including media access control layer diagnostic data and / or physical layer interface chip diagnostic data; determines the communication component to be diagnosed and the corresponding diagnostic operation based on the target diagnostic data, the communication component to be diagnosed including the media access control layer interface and / or the physical layer interface chip.

[0123] It is understood that the remote processor can use a specific reading mechanism (such as MII or MDI protocol) to collect diagnostic data from the MAC layer and PHY chip. This process can be obtained through embedded registers or management interfaces (such as Management Data Input / Output, MDIO), such as reading error counts, performance counters and current status indicators.

[0124] By way of example and not limitation, on some network interface cards, a command may be executed to read the receive error count and transmit error count of the MAC layer, or to read the connection status (eg, whether the link is active) of the PHY chip.

[0125] In conjunction with the above, the target diagnostic data includes data about the status of the communication component to be diagnosed, including its working status, error logs, transmission status, etc. This data can be used to determine whether the device is normal or not.

[0126] The target diagnostic data includes media access control layer diagnostic data and / or physical layer interface chip diagnostic data.

[0127] By way of example and not limitation, data obtained from the MAC layer may indicate the number of packets received per second and the number of packets dropped due to network collisions, while data obtained from the PHY chip may indicate the strength of the electrical signal or whether the connection is stable.

[0128] It is understandable that the remote processor can set a series of preset rules or conditions. For example, if the packet loss rate of the MAC layer exceeds a certain threshold, it may indicate network congestion or hardware failure; if the PHY chip shows poor link quality (such as extremely low signal strength), it may indicate a poor connection or cable problem.

[0129] By way of example and not limitation, if the MAC layer data read shows significant TX errors but the PHY chip does not have any connection errors, it may mean that the data processing capability is limited; conversely, if the PHY chip shows no connection but the MAC layer does not issue any errors, it may mean a problem with the network cable or interface.

[0130] By reading and analyzing the target diagnostic data of the communication component to be diagnosed through the remote processor, the health status of the network interface can be effectively monitored and judged, ensuring that the problem can be quickly located when a network failure occurs, thereby improving diagnostic efficiency and network availability.

[0131] In one implementation, when the communication component to be diagnosed is a media access control layer interface, the remote processor performs a diagnostic operation on the communication component to be diagnosed, including at least one of the following: the remote processor obtains link status data of the media access control layer interface, and determines whether the media access control layer and the physical layer interface chip are connected through a media independent interface based on the link status data of the media access control layer interface; the remote processor obtains the number of sent and received messages of the media access control layer interface, and determines whether there is a fault in the data link layer based on the number of sent and received messages of the media access control layer interface.

[0132] The link status of the MAC interface can show whether the MAC and PHY can be correctly connected through the MII interface. This diagnostic parameter can be used to diagnose whether there are problems with the hardware circuit or whether there are deficiencies in the software settings.

[0133] By way of example and not limitation, the link status data of the interface, such as "Link Up" or "Link Down", can be obtained by reading the management register of the MAC layer or using the MII protocol. If the MAC layer register returns "Link Up", it indicates that the connection between the MAC interface and the PHY chip is normal.

[0134] The number of packets sent and received on the MAC interface can display the number of packets sent and received by the data link layer, allowing you to diagnose whether the problem is at the data link layer or the network layer.

[0135] As you can understand, the MAC layer usually has counters to record the number of data packets sent and received. By reading these counters, you can obtain statistical data within a certain period of time.

[0136] For example, if the number of sent packets recorded by the MAC layer in the past minute is 1000 and the number of received packets is 950, this indicates that the interface is working properly.

[0137] By comparing the number of sent and received packets, you can determine whether there is packet loss or unsuccessful delivery. If the number of sent packets is significantly higher than the number of received packets, it may indicate a data link layer failure or network problem.

[0138] For example, if the MAC layer sends 1,000 packets but only receives 800, the significant loss could indicate network congestion, equipment failure, or network misconfiguration.

[0139] By diagnosing the link status of the MAC interface and the number of sent and received messages on the MAC interface, the health status of the media access control layer and physical layer interface chips can be accurately assessed, which helps to accurately locate faults.

[0140] In one implementation, when the communication component to be diagnosed is a physical layer interface chip, the remote processor performs a diagnostic operation on the communication component to be diagnosed, including at least one of the following: the remote processor obtains link status data of the physical layer interface chip, and determines whether the link status between the physical layer interface chip and the opposite end meets a preset status based on the link status data of the physical layer interface chip; the remote processor obtains the number of sent and received messages of the physical layer interface chip, and determines whether there is a fault in the physical layer based on the number of sent and received messages of the physical layer interface chip; the remote processor obtains the cable connection data between the physical layer interface chip and the opposite end, and determines whether there is a fault in the cable connected to the physical layer interface chip based on the cable connection data.

[0141] The link status of the PHY interface can display the link status between the PHY chip and the other end. This parameter can detect whether the in-vehicle Ethernet cable connecting the PHY and the other end is normal and whether the PHY configurations of the PHY and the other end match. For example, if one is set to master mode, the other must be set to slave mode to ensure a normal link.

[0142] It is understood that physical layer interface chips typically have status registers that allow external devices to query their link status. Link status data includes whether the link is established (Link Up / Down) and the current connection characteristics (such as speed and duplex mode).

[0143] For example, by accessing the status register of the physical layer, a "link established" status is obtained, indicating that the connection with the opposite end device is normal.

[0144] By setting a preset state (e.g., the link should be in the "Link Established" state, the speed should be 1Gbps, etc.), the link status obtained by query is compared. If the preset state is "Link Established" and the state obtained from the physical layer is "Link Down", it should be determined that a fault may exist.

[0145] The number of sent and received messages of the PHY chip can show the number of messages received and sent to the physical layer, thereby diagnosing whether the problem is the physical layer or the data link layer.

[0146] As you can understand, the physical layer chip has internal statistical registers that record the number of packets sent and received. These registers can quantify the activity and effectiveness of the interface over a specified period of time.

[0147] For example, if you read the physical layer counters and see that 2000 packets were sent and 1900 were received in the past minute, the interface is operating normally. However, if 2000 packets were sent but only 1500 were received, the packet loss rate is too high and a significant discrepancy may indicate a physical layer failure.

[0148] The quality of the cable connecting the PHY chip and the opposite end can be used to diagnose whether the cable connecting the PHY and the opposite end is loose or defective.

[0149] The physical layer diagnostic function can be used to obtain parameters about the connection, such as cable type, length, and transmitted signal quality.

[0150] For example, when reading cable connection information, if the cable length exceeds the specification limit or the signal attenuation rate is high, it may indicate a cable problem. The obtained cable connection parameters are compared with standards or predefined thresholds. If the cable characteristics do not meet the standards or the signal quality indicators show abnormalities, it may indicate cable damage or failure. If the cable connection data indicates poor signal quality, it may cause errors in information transmission, affecting overall network performance.

[0151] Through the above steps, the health of the physical layer interface chip can be comprehensively evaluated to ensure the normal operation of the equipment and network, ensure the rapid location and resolution of problems, and improve network reliability.

[0152] In one implementation, the remote processor performs a diagnostic operation on the communication component to be diagnosed, further comprising: the remote processor writes preset diagnostic parameters in the communication component to be diagnosed, the preset diagnostic parameters being used to determine whether the communication component to be diagnosed has a fault; and the communication component to be diagnosed receives and stores the preset diagnostic parameters.

[0153] Preset diagnostic parameters refer to predefined parameters or configurations used to guide the communication component to be diagnosed to perform specific diagnostic tasks.

[0154] As an example and not a limitation, the preset diagnostic parameters may include a test mode, a threshold, a time limit, etc. The specific diagnostic parameters may be set according to actual conditions and are not limited here.

[0155] The remote processor writes preset diagnostic parameters into the communication component to be diagnosed, that is, transmits specific instructions and configurations required to perform diagnosis to the communication component to be diagnosed.

[0156] By way of example and not limitation, the remote processor transmits a data packet containing preset diagnostic parameters via a network or data bus. These parameters instruct the communication component to perform a corresponding inspection operation. For example, the remote processor transmits a "Start Network Test" command with parameters including a "test period of 5 seconds and a maximum packet loss rate of 2%," instructing the communication component to perform a network connectivity test.

[0157] The communication component to be diagnosed receives and stores preset diagnostic parameters, ensuring that the communication component to be diagnosed can correctly understand and use the diagnostic parameters sent by the remote processor.

[0158] The communication component to be diagnosed receives data through its receiving port and stores these parameters in internal registers or caches for subsequent diagnostic operations. For example, after receiving the "Start Network Test" command, the communication component to be diagnosed saves the parameters as "Network Test Mode: Active, Period: 5 seconds, Packet Loss Threshold: 2%" to prepare for subsequent testing.

[0159] Through this method, the remote processor can effectively interact with the communication component being diagnosed, instructing it to perform specific diagnostic operations. The preset diagnostic parameters written by the remote processor provide the necessary information for the diagnostic process, and the communication component receiving and storing these parameters ensures that these parameters are correctly executed. This mechanism helps to promptly detect and diagnose faults, improving system reliability and maintenance efficiency.

[0160] In one implementation, the main processor sends a diagnostic request to the remote processor through a remote processor messaging protocol, including: the main processor periodically obtains the network status; when the network status is a preset network status, the main processor sends a diagnostic request to the remote processor, and the preset network status includes at least one of the following: network disconnection status, network packet loss status, and network unstable status.

[0161] The network status is used to describe various conditions of the network connection, which can include normal state, disconnected state, packet loss state, and unstable state.

[0162] The preset network status is used to determine whether the current state of the network meets specific conditions and to respond based on these conditions.

[0163] The main processor periodically obtains the network status and can continuously monitor the network condition so as to respond when an abnormality is detected.

[0164] It can also be understood that the main processor regularly monitors the network status. When it finds abnormalities in the messages sent and received in the network, such as network disconnection, network packet loss, network instability, etc., it will send a diagnostic request to the remote processor, requesting diagnosis: the link status of the MAC interface, the link status of the PHY interface, the number of messages sent and received by the MAC interface, the number of messages sent and received by the PHY chip, the quality of the cable connecting the PHY chip and the other end, etc.

[0165] By way of example and not limitation, the main processor uses a timer mechanism to periodically query or collect network status information. This query can be accomplished by interacting with a network interface or monitoring module. For example, every 5 seconds, the main processor may send a network status query command to obtain the current network connection status, such as link status, packet loss rate, and latency.

[0166] The main processor compares the obtained network status with preset standards, such as "network disconnection", "network packet loss", or "network instability". For example, if the main processor finds that the current network packet loss rate exceeds 2%, it identifies this status as "network packet loss status".

[0167] When a network anomaly is detected, a diagnostic request is proactively initiated so that the remote processor can perform relevant fault detection.

[0168] The main processor regularly monitors the network status and proactively initiates diagnostic requests when specific preset abnormal conditions are detected. This ensures that network problems can be discovered and debugged in a timely manner, improving network availability and maintenance efficiency. At the same time, it can also avoid frequent diagnostic requests when the network status is normal, saving resources.

[0169] It can be understood that the above method is applicable to various PHY chip diagnostic requests and various MAC diagnostic requests. According to actual needs, the corresponding diagnostic requirements can be realized by adding corresponding diagnostic interfaces, which are not listed here one by one.

[0170] The following combination Figure 3 To give an overall introduction to the diagnostic process involved in the above method.

[0171] Figure 3 This is a schematic diagram of a diagnostic process provided in an embodiment of the present application.

[0172] like Figure 3 As shown, the "remote configuration server" in the remote processor is implemented based on a server-client architecture, with the remote processor acting as a server and the main processor acting as a remote client.

[0173] The remote processor running Ethernet firmware plays the role of a server, accepting and processing commands from the client, performing PHY and MAC related diagnostic operations on behalf of the client, and returning the execution results to the remote client.

[0174] The remote client obtains the diagnostic results from the server and analyzes and diagnoses them to achieve the purpose of real-time monitoring.

[0175] The main processor acts as a remote client and sends diagnostic requests to the remote processor. The diagnostic service implements Ethernet diagnosis by operating the Ethernet interface exposed to the application.

[0176] The diagnostic request is then sent to the remote configuration server in the remote processor via RPMSG. The RPMSG client driver is compatible with the remote configuration server running on the Ethernet firmware. This driver is used to exchange control messages with the Ethernet firmware to establish the data connection of the diagnostic channel.

[0177] When the remote processor receives a diagnostic request from the main processor, it identifies and processes the diagnostic request passed by RPMSG. If it is a MAC-side diagnosis, it diagnoses the relevant parameters in the MAC driver. If it is a PHY diagnostic request, it performs the operation in the PHY driver. The diagnostic results are then fed back to the main processor through RPMSG, and the main processor processes the feedback results.

[0178] This approach enables the vehicle network to be monitored, quickly locating problem points and significantly improving accuracy and efficiency. Furthermore, the solution offers excellent scalability and flexibility, adapting to different vehicle models and diagnostic requirements.

[0179] Based on the vehicle Ethernet diagnostic method provided in the above embodiment, the present application also provides a specific implementation of a vehicle Ethernet diagnostic system. Please refer to the following embodiments.

[0180] The vehicle Ethernet diagnostic system provided in the embodiment of the present application is applied to a main control system-level chip, which includes a main processor and a remote processor. The main processor and the remote processor communicate through a remote processor message transmission protocol;

[0181] The main processor is used to send a diagnostic request to the remote processor through a remote processor message transmission protocol, where the diagnostic request carries diagnostic type information.

[0182] The remote processor is used to respond to the diagnosis request and determine the communication component to be diagnosed and the corresponding diagnostic operation according to the diagnosis type information. The communication component to be diagnosed is used to realize Ethernet communication between the remote processor and the outside.

[0183] The remote processor is used to perform a diagnostic operation on the communication component to be diagnosed, where the diagnostic operation is used to determine whether there is a fault in the communication component to be diagnosed.

[0184] A remote processor is configured to generate a diagnostic result based on the diagnostic operation.

[0185] The remote processor is configured to send diagnostic results to the main processor via a remote processor messaging protocol.

[0186] As an implementation of the present application, the main processor runs a Linux operating system, and the remote processor runs a real-time operating system. The main processor is further configured to start a boot program, which is configured to control the startup of the remote processor. Under the control of the boot program, the remote processor is further configured to load Ethernet firmware and perform Ethernet firmware initialization operations. The initialized Ethernet firmware is used to create a remote processor message passing kernel driver device.

[0187] The remote processor is further configured to create a remote processor messaging kernel driver device in the main processor and the remote processor according to the remote processor messaging kernel driver protocol.

[0188] This method enables the main processor and remote processor to work together. In other words, through the cooperation of the bootloader and Ethernet firmware, effective communication between the two is achieved, ensuring that the system can run stably and in real time in a multi-processor environment.

[0189] As an implementation method of the present application, a remote processor message passing kernel driver device includes a first remote processor message passing kernel driver device and a second remote processor message passing kernel driver device; the remote processor is also used to create a remote processor message passing kernel driver device in the main processor and the remote processor according to the remote processor message passing kernel driver protocol, including: the main processor is used to create a virtual I / O device, and the virtual I / O device is used to interact with the Ethernet firmware; the virtual I / O device uses the virtual I / O device remote processor message passing bus driver to detect whether the first remote processor message passing kernel driver device is created in the remote processor; when it is detected that the first remote processor message passing kernel driver device is created in the remote processor, the second remote processor message passing kernel driver device is created in the main processor.

[0190] By creating a second device corresponding to the first remote processor messaging kernel driver device, the host processor can effectively communicate bidirectionally with the remote processor, following the RPMSG protocol to ensure efficient and reliable delivery of information.

[0191] As an implementation method of the present application, according to the boot program, the remote processor is also used to load Ethernet firmware and perform Ethernet firmware initialization operations, including: performing media access control layer initialization operations to configure the Ethernet media access control port; performing physical layer interface chip initialization operations to adapt the driver of the physical layer interface chip; performing media independent interface initialization operations, the media independent interface is used to support communication between the media access control layer and the physical layer; performing remote configuration service operations to remotely configure Ethernet, and the Ethernet remote configuration service is implemented based on the inter-process communication mechanism.

[0192] Together, these methods ensure the correct initialization of Ethernet hardware on the remote processor, enabling network connectivity. This specific hardware configuration or initialization enables the system to efficiently respond to network events and supports remote management and configuration via IPC mechanisms, enriching the system's functionality and reliability.

[0193] As an implementation method of the present application, the remote processor is also used to, in response to a diagnostic request, determine the communication component to be diagnosed and the corresponding diagnostic operation based on the diagnostic type information, including: the remote processor reads target diagnostic data from the communication component to be diagnosed, the target diagnostic data including media access control layer diagnostic data and / or physical layer interface chip diagnostic data; and determines whether there is a fault in the media access control layer and / or the physical layer interface chip based on the target diagnostic data.

[0194] By reading and analyzing the target diagnostic data of the communication component to be diagnosed through the remote processor, the health status of the network interface can be effectively monitored and judged, ensuring that the problem can be quickly located when a network failure occurs, thereby improving diagnostic efficiency and network availability.

[0195] As an implementation method of the present application, when the communication component to be diagnosed is a media access control layer interface, the remote processor is also used to perform diagnostic operations on the communication component to be diagnosed, including at least one of the following: the remote processor obtains link status data of the media access control layer interface, and determines whether the media access control layer and the physical layer interface chip are connected through a media independent interface based on the link status data of the media access control layer interface; the remote processor obtains the number of sent and received messages of the media access control layer interface, and determines whether there is a fault in the data link layer based on the number of sent and received messages of the media access control layer interface.

[0196] By diagnosing the link status of the MAC interface and the number of sent and received messages on the MAC interface, the health status of the media access control layer and physical layer interface chips can be accurately assessed, which helps to accurately locate faults.

[0197] As an implementation method of the present application, when the communication component to be diagnosed is a physical layer interface chip, the remote processor is also used to perform diagnostic operations on the communication component to be diagnosed, including at least one of the following: the remote processor obtains the link status data of the physical layer interface chip, and determines whether the link status between the physical layer interface chip and the opposite end meets the preset status based on the link status data of the physical layer interface chip; the remote processor obtains the number of sent and received messages of the physical layer interface chip, and determines whether there is a fault in the physical layer based on the number of sent and received messages of the physical layer interface chip; the remote processor obtains the cable connection data between the physical layer interface chip and the opposite end, and determines whether there is a fault in the cable connected to the physical layer interface chip and the pair based on the cable connection data.

[0198] Through the above steps, the health of the physical layer interface chip can be comprehensively evaluated to ensure the normal operation of the equipment and network, ensure the rapid location and resolution of problems, and improve network reliability.

[0199] As an implementation method of the present application, the remote processor is also used to perform diagnostic operations on the communication component to be diagnosed, and also includes: the remote processor writes preset diagnostic parameters in the communication component to be diagnosed, and the preset diagnostic parameters are used to determine whether there is a fault in the communication component to be diagnosed; the communication component to be diagnosed receives and stores the preset diagnostic parameters.

[0200] Through this method, the remote processor can flexibly and efficiently interact with the communication component being diagnosed, instructing it to perform specific diagnostic operations. The preset diagnostic parameters written by the remote processor provide the necessary information for the diagnostic process, and the communication component receiving and storing these parameters ensures that these parameters are correctly executed. This mechanism facilitates the timely detection and diagnosis of faults, improving system reliability and maintenance efficiency.

[0201] As an implementation method of the present application, the main processor is also used to send a diagnostic request to the remote processor through the remote processor messaging protocol, including: the main processor periodically obtains the network status; when the network status is a preset network status, the main processor sends a diagnostic request to the remote processor, and the preset network status includes at least one of the following: network disconnection status, network packet loss status, and network unstable status.

[0202] The main processor regularly monitors the network status and proactively initiates diagnostic requests when specific situations are detected. This ensures that network problems can be discovered and debugged in a timely manner, improving network availability and maintenance efficiency. At the same time, it can also avoid frequent diagnostic requests when the network status is normal, saving resources.

[0203] Figure 4 It is a structural diagram of the vehicle Ethernet diagnostic device provided in an embodiment of the present application.

[0204] The vehicle Ethernet diagnostic device may include a processor 2001 and a memory 2002 storing computer program instructions.

[0205] Specifically, the processor 2001 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0206] The memory 2002 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 2002 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 2002 may include removable or non-removable (or fixed) media. Where appropriate, the memory 2002 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 2002 is a non-volatile solid-state memory.

[0207] In certain embodiments, the memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0208] The processor 2001 implements any one of the vehicle Ethernet diagnostic methods in the above embodiments by reading and executing computer program instructions stored in the memory 2002 .

[0209] In one example, the vehicle Ethernet diagnostic device may further include a communication interface 2003 and a bus 2000. Figure 4 As shown, the processor 2001, the memory 2002, and the communication interface 2003 are connected via a bus 2000 and communicate with each other.

[0210] The communication interface 2003 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0211] Bus 2000 includes hardware, software or both, and the parts of online data flow metering equipment are coupled to each other. For example, but not limitation, bus can include accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 2000 can include one or more buses. Although the present application embodiment describes and shows specific bus, the application considers any suitable bus or interconnection.

[0212] In addition, in conjunction with the vehicle Ethernet diagnostic method in the above embodiments, embodiments of the present application may provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any of the vehicle Ethernet diagnostic methods in the above embodiments is implemented.

[0213] An embodiment of the present application also provides a computer program product, including a computer program, which, when processed and executed, implements any one of the vehicle Ethernet diagnostic methods in the above embodiments.

[0214] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0215] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), suitable firmware, plug-ins, function cards, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. Programs or code segments can be stored in machine-readable media, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0216] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0217] Aspects of the present disclosure have been described above with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It is also understood that each box in the block diagram and / or flowchart and the combination of the boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0218] The above is only a specific implementation method of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited to this. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A vehicle Ethernet diagnostic method, characterized in that: Applied to a main control system-on-chip, the main control system-on-chip includes a main processor and a remote processor, the main processor and the remote processor communicate via a remote processor message passing protocol, the method comprising: The main processor sends a diagnostic request to the remote processor through the remote processor messaging protocol, wherein the diagnostic request carries diagnostic type information; In response to the diagnostic request, the remote processor determines a communication component to be diagnosed and a corresponding diagnostic operation according to the diagnostic type information, wherein the communication component to be diagnosed is used to implement Ethernet communication between the remote processor and the outside; The remote processor performs the diagnostic operation on the communication component to be diagnosed, wherein the diagnostic operation is used to determine whether the communication component to be diagnosed has a fault; The remote processor generates a diagnostic result according to the diagnostic operation; The remote processor sends the diagnostic result to the main processor through the remote processor messaging protocol.

2. The method according to claim 1, characterized in that The main processor runs a Linux operating system, and the remote processor runs a real-time operating system. The method further includes: The main processor starts a boot program, and the boot program is used to control the startup of the remote processor; Under the control of the boot program, the remote processor loads Ethernet firmware and performs Ethernet firmware initialization operations, wherein the initialized Ethernet firmware is used to create a remote processor message passing kernel driver device; The remote processor creates the remote processor messaging kernel driver device in the main processor and the remote processor according to the remote processor messaging kernel driver protocol.

3. The method according to claim 2, characterized in that The remote processor message delivery kernel driver device includes a first remote processor message delivery kernel driver device and a second remote processor message delivery kernel driver device; The remote processor creates the remote processor message passing kernel driver device in the main processor and the remote processor according to the remote processor message passing kernel driver protocol, including: The main processor creates a virtual I / O device, where the virtual I / O device is used to interact with the Ethernet firmware; The virtual I / O device uses the virtual I / O device remote processor message passing bus driver to detect whether a first remote processor message passing kernel driver device is created in the remote processor; In the case of detecting that a first remote processor message passing kernel driver device is created in the remote processor, a second remote processor message passing kernel driver device is created in the main processor.

4. The method according to claim 2, characterized in that The remote processor loads the Ethernet firmware according to the boot program and performs Ethernet firmware initialization operations, including: Perform media access control layer initialization operations and configure Ethernet media access control ports; Perform physical layer interface chip initialization operations and adapt the driver of the physical layer interface chip; Performing a medium independent interface initialization operation, wherein the medium independent interface is used to support communication between the media access control layer and the physical layer; A remote configuration service operation for remotely configuring Ethernet is performed, wherein the remote configuration service of Ethernet is implemented based on an inter-process communication mechanism.

5. The method according to any one of claims 1 to 4, characterized in that In response to the diagnostic request, the remote processor determines the communication component to be diagnosed and the corresponding diagnostic operation according to the diagnostic type information, including: The remote processor reads target diagnostic data from the communication component to be diagnosed according to the diagnostic type information, wherein the target diagnostic data includes media access control layer diagnostic data and / or physical layer interface chip diagnostic data; The communication component to be diagnosed and the corresponding diagnostic operation are determined according to the target diagnostic data, where the communication component to be diagnosed includes a media access control layer interface and / or a physical layer interface chip.

6. The method according to claim 5, characterized in that In a case where the communication component to be diagnosed is a media access control layer interface, the remote processor performs the diagnostic operation on the communication component to be diagnosed, including at least one of the following: The remote processor obtains link status data of the media access control layer interface, and determines whether the media access control layer and the physical layer interface chip are connected through a media independent interface according to the link status data of the media access control layer interface; The remote processor obtains the number of sent and received messages of the media access control layer interface, and determines whether there is a fault in the data link layer according to the number of sent and received messages of the media access control layer interface.

7. The method according to claim 5, characterized in that In a case where the communication component to be diagnosed is a physical layer interface chip, the remote processor performs the diagnostic operation on the communication component to be diagnosed, including at least one of the following: The remote processor obtains link status data of the physical layer interface chip, and determines whether the link status between the physical layer interface chip and the opposite end meets a preset status according to the link status data of the physical layer interface chip; The remote processor obtains the number of sent and received messages of the physical layer interface chip, and determines whether there is a fault in the physical layer according to the number of sent and received messages of the physical layer interface chip; The remote processor obtains the cable connection data between the physical layer interface chip and the opposite end, and determines whether there is a fault in the cable connected between the physical layer interface chip and the opposite end according to the cable connection data.

8. The method according to any one of claims 1 to 4, characterized in that Before the remote processor performs the diagnostic operation on the communication component to be diagnosed, the method further includes: The remote processor writes preset diagnostic parameters into the communication component to be diagnosed, wherein the preset diagnostic parameters are used to determine whether the communication component to be diagnosed has a fault; The communication component to be diagnosed receives and stores the preset diagnostic parameters.

9. The method according to claim 1, characterized in that The main processor sends a diagnostic request to the remote processor through the remote processor messaging protocol, including: The main processor periodically obtains the network status; When the network state is a preset network state, the main processor sends a diagnostic request to the remote processor, and the preset network state includes at least one of the following: a network disconnection state, a network packet loss state, and a network unstable state.

10. A vehicle Ethernet diagnostic system, characterized in that: Applied to the main control system-level chip, the main control system-level chip includes a main processor and a remote processor, the main processor and the remote processor communicate through the remote processor message passing protocol; wherein, The main processor is configured to send a diagnostic request to the remote processor via the remote processor messaging protocol, wherein the diagnostic request carries diagnostic type information; The remote processor is configured to respond to the diagnostic request and determine a communication component to be diagnosed and a corresponding diagnostic operation according to the diagnostic type information, wherein the communication component to be diagnosed is configured to implement Ethernet communication between the remote processor and an external device; The remote processor is configured to perform the diagnostic operation on the communication component to be diagnosed, wherein the diagnostic operation is configured to determine whether the communication component to be diagnosed has a fault; The remote processor is configured to generate a diagnostic result according to the diagnostic operation; The remote processor is configured to send the diagnosis result to the main processor via the remote processor messaging protocol.

Images