CN115701034A - Bus control method and related device - Google Patents

Bus control method and related device Download PDF

Info

Publication number
CN115701034A
CN115701034A CN202110845858.8A CN202110845858A CN115701034A CN 115701034 A CN115701034 A CN 115701034A CN 202110845858 A CN202110845858 A CN 202110845858A CN 115701034 A CN115701034 A CN 115701034A
Authority
CN
China
Prior art keywords
node
protocol type
message
bus
vehicle
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110845858.8A
Other languages
Chinese (zh)
Inventor
袁江
包森林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202110845858.8A priority Critical patent/CN115701034A/en
Priority to PCT/CN2022/107590 priority patent/WO2023005866A1/en
Publication of CN115701034A publication Critical patent/CN115701034A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Abstract

The embodiment of the application discloses a bus control method and a related device, which are used for improving the communication efficiency of a bus control system. The method in the embodiment of the application comprises the following steps: the first node receives a first message sent by the second node, the first node identifies the bus protocol type of the second node according to the first message, the first node sends a second message to the second node based on the bus protocol type, and the protocol type of the second message is consistent with the bus protocol type of the second node.

Description

Bus control method and related device
Technical Field
The present disclosure relates to the field of communications, and in particular, to a bus control method and a related apparatus.
Background
A Controller Area Network (CAN) is a serial communication network that supports distributed control and implements control. The controller area network (CAN fd) protocol includes a CAN protocol and a flexible data rate.
At present, a CAN protocol and a CANFD protocol are two field bus protocols commonly used by an automobile computer control system. The whole vehicle is communicated with the external diagnostic equipment through the vehicle-mounted gateway, and a CAN bus is provided outside the vehicle and CAN support two protocols of CAN and CANFD.
Because the bus protocol type of the whole vehicle CAN be changed along with the adjustment of the whole vehicle architecture, and one CAN bus cannot be compatible with the CAN protocol and the CANFD protocol at the same time, the vehicle-mounted gateway CAN only reconfigure the bus type of the vehicle-mounted gateway according to the protocol type of the vehicle-mounted diagnostic equipment, thereby influencing the diagnosis efficiency of the vehicle-mounted diagnostic equipment on the whole vehicle.
Disclosure of Invention
The embodiment of the application provides a bus control method and a related device, which are used for improving the communication efficiency of a bus system.
In a first aspect of the embodiments of the present application, a bus control method is provided, where the method may be executed by a first node, or may be executed by a component of the first node, such as a processor, a chip, or a chip system of the first node, or may be implemented by a logic module or software that can implement all or part of functions of a network device, where the first node includes a bus controller including a vehicle-mounted gateway. A first aspect provides a bus control method including: after the first node receives the first packet sent by the second node, the first packet may indicate a bus protocol type of the first node, for example, a frame format and an identification bit of the first packet may indicate the bus protocol type of the first node, so that the first node may recognize the bus protocol type of the second node according to the first packet, and after the first node recognizes the bus protocol type of the second bus, the first node may send a second packet to the second node according to the bus protocol type of the second node, where the protocol type of the second packet is consistent with the bus protocol type of the second node.
In the embodiment of the application, the first node automatically identifies the bus protocol type of the second node according to the message sent by the second node, so that the first node can send the service message again according to the bus protocol type of the second node, and the communication efficiency of the first node and the second node is improved.
Based on the first aspect, in a possible implementation manner, before a first node receives a first packet sent by a second node, the first node sends at least one third packet to the second node, where the third packet is used to detect a bus protocol type of the second node, specifically, the first node sends the third packet based on a first bus protocol to the second node, the first node determines whether to receive a response packet, and if not, the first node sends the third packet based on a second bus protocol to the second node, where the first packet received by the first node may be a response packet, that is, when the first packet is a response packet, the first packet is used to respond to the third packet according to the bus protocol type of the third packet.
In the embodiment of the application, the first node sends the detection message to the second node, so that the first node determines the bus protocol type of the second node according to the response message responding to the detection message, when the second node in the network system changes, the bus protocol type of the second node can be automatically identified, the bus protocol type of the first node does not need to be modified, and the communication efficiency of the network system is improved.
In a possible embodiment according to the first aspect, the bus protocol type comprises a CAN protocol or a CANFD protocol. The first node comprises an onboard gateway and the second node comprises an onboard electronic control, ECU, component or an offboard diagnostic device.
When the embodiment of the application is applied to a vehicle diagnosis scene, the vehicle-mounted gateway can automatically identify the bus protocol type supported by the under-vehicle diagnostic apparatus according to the message sent by the under-vehicle diagnostic apparatus, and the diagnosis efficiency of the vehicle is improved.
Further, when the embodiment of the application is applied to a vehicle-mounted network scene, when the system architecture of the whole vehicle is expanded or modified, the vehicle-mounted gateway can determine the bus protocol type of the vehicle-mounted ECU component at the opposite end by sending the detection message, and the bus protocol type of the vehicle-mounted gateway does not need to be modified for direct communication, so that the communication efficiency of the vehicle is improved.
Based on the first aspect, in a possible implementation manner, in the process that the first node identifies the bus protocol type of the second node according to the first packet, the first node identifies the bus protocol type of the second node according to the FDF flag in the first packet. Specifically, the first node analyzes the first message through the CAN controller, and the first node identifies the bus protocol type of the first message according to the FDF identifier in the analyzed message, wherein if the FDF identifier exists in the first message, the bus protocol type of the first message is the CANFD protocol, and if the FDF identifier does not exist, the bus protocol type of the first message is the CAN protocol.
In the embodiment of the application, the first node can identify the bus protocol type of the message according to the FDF identifier in the message, so that the scheme realizability is improved.
Based on the first aspect, in a possible implementation manner, after the first node identifies the bus protocol type of the second node according to the first packet, the first node records the bus protocol type of the second node. Specifically, the first node stores the bus protocol type of the second node in the memory of the first node, so that the first node sends the service packet to the second node again is directly based on the bus protocol type of the second node.
In this embodiment of the present application, the first node may store the bus protocol type of the second node, so that the next service packet of the first node may query the bus protocol type of the second node, thereby improving the communication efficiency between the first node and the second node.
Based on the first aspect, in a possible implementation manner, before the first node sends the second packet to the second node based on the bus protocol type, the method further includes: the first node queries the second node for the bus protocol type.
A second aspect of the embodiments of the present application provides a bus control method, which may be executed by a second node, or may be executed by a component of the second node, such as a processor, a chip, or a chip system of the second node, or may be implemented by a logic module or software that can implement all or part of functions of a network device, where the second node includes an on-board ECU component and an off-board diagnostic device. The bus control method provided by the second aspect comprises the following steps: the method comprises the following steps: after the second node sends the first packet to the first node, the first packet may indicate a bus protocol type of the first node, for example, a frame format and an identification bit of the first packet may indicate the bus protocol type of the first node, so that the first node may identify the bus protocol type of the second node according to the first packet, after the first node identifies the bus protocol type of the second node, the first node may send a subsequent second packet to the second node according to the bus protocol of the second node, the second node receives the second packet sent by the first node, and the second packet is consistent with the bus protocol type of the second node.
In the embodiment of the application, the second node sends the first message to the first node, so that the first node can identify the bus protocol type of the second node according to the first message, and thus the communication efficiency of the first node and the second node is improved.
Based on the second aspect, in a possible implementation manner, before the second node sends the first packet to the first node, the second node receives at least one third packet sent by the first node, specifically, the second node receives a third packet based on the first bus protocol sent by the first node, the second node determines whether to identify the first bus protocol type of the packet, if the first bus protocol type of the packet cannot be identified, the second node does not respond to the packet, and when the second node receives the third packet based on the second bus protocol sent by the first node, if the second bus protocol type of the packet can be identified, the second node sends a response packet of the packet to the second node. Therefore, the third packet is used to detect the bus protocol type of the second node, and the first packet is used to respond to the third packet according to the bus protocol type of the third packet.
In the embodiment of the application, the second node responds to the detection message sent by the first node, and when the second node in the network system changes, the first node can automatically identify the bus protocol type of the second node according to the response message without modifying the bus protocol type of the first node, so that the communication efficiency of the network system is improved.
Based on the second aspect, in one possible implementation, the bus protocol type includes a CAN protocol or a CANFD protocol. The first node comprises an onboard gateway and the second node comprises an onboard electronic control, ECU, component or an offboard diagnostic device.
A third aspect of the present embodiment provides a bus control apparatus, where the apparatus includes an interface unit and a processing unit, where the interface unit is configured to receive a first packet sent by a second node, the processing unit is configured to identify a bus protocol type of the second node according to the first packet, and the interface unit is further configured to send a second packet to the second node based on the bus protocol type, and the protocol type of the second packet is consistent with the bus protocol type of the second node.
In a possible implementation manner, before receiving the first packet sent by the second node, the interface unit is further configured to send at least one third packet to the second node, where the third packet is used to detect a bus protocol type of the second node, and the first packet is used to respond to the third packet according to the bus protocol type of the third packet.
In one possible implementation, the bus protocol type includes a CAN protocol or a CANFD protocol, the first node includes an onboard gateway, and the second node includes an onboard electronic control ECU component or an offboard diagnostic device.
In a possible implementation manner, the processing unit is specifically configured to identify the bus protocol type of the second node according to the FDF flag in the first message.
In a possible implementation manner, after the bus protocol type of the second node is identified according to the first packet, the processing unit is further configured to record the bus protocol type of the second node.
In a possible implementation manner, before sending the second packet to the second node based on the bus protocol type, the processing unit is further configured to query the bus protocol type of the second node.
A fourth aspect of the present embodiment provides a bus controller, including an interface unit and a processing unit, where the interface unit is configured to send a first packet to a first node, where the first packet is used by the first node to identify a bus protocol type of a second node, and the interface unit is further configured to receive a second packet sent by the first node, where the second packet is consistent with the bus protocol type of the second node.
In a possible implementation manner, before the interface unit sends the first packet to the first node, the interface unit is further configured to receive at least one third packet sent by the first node, where the third packet is used to detect a bus protocol type of the second node, and the first packet is used to respond to the third packet according to the bus protocol type of the third packet.
In one possible embodiment, the bus protocol type includes a CAN protocol or a CANFD protocol. The first node comprises an onboard gateway and the second node comprises an onboard electronic control, ECU, component or an offboard diagnostic device.
A fifth aspect of the embodiments of the present application provides a bus control apparatus, including a processor, coupled with a memory, and configured to store instructions that, when executed by the processor, cause the bus control apparatus to perform the method according to the first aspect or any one of the possible implementation manners of the first aspect, or cause the bus control apparatus to perform the method according to any one of the possible implementation manners of the second aspect or the second aspect.
A sixth aspect of the present embodiment provides a bus control system, including: a first node and a second node, the first node being configured to perform the method according to the first aspect or any one of the possible implementations of the first aspect, and the second node being configured to perform the method according to the second aspect or any one of the possible implementations of the second aspect.
A seventh aspect of the embodiments of the present application provides a vehicle, including an onboard gateway and an onboard component, where the onboard gateway is configured to perform the method performed by the first node in the first aspect or any one of the possible implementations of the first aspect, and the onboard component is configured to perform the method performed by the second node in any one of the possible implementations of the second aspect or the second aspect.
An eighth aspect of embodiments of the present application provides a computer-readable storage medium, on which instructions are stored, which, when executed, cause a computer to perform the method according to the first aspect or any one of the possible implementations of the first aspect, or cause a computer to perform the method according to the second aspect or any one of the possible implementations of the second aspect.
A ninth aspect of the embodiments of the present application provides a computer program product, where the computer program product includes instructions that, when executed, cause a computer to implement the method according to the first aspect or any one of the possible implementations of the first aspect, or cause a computer to implement the method according to the second aspect or any one of the possible implementations of the second aspect.
It is understood that the advantageous effects achieved by any one of the bus control devices, the bus control system, the computer readable medium, or the computer program product provided above may refer to the advantageous effects in the corresponding method, and are not described herein again.
Drawings
Fig. 1 is a schematic diagram of a communication system architecture according to an embodiment of the present application;
fig. 2 is a schematic diagram of a bus control method according to an embodiment of the present disclosure;
FIG. 3 is a schematic diagram of another bus control method according to an embodiment of the present disclosure;
FIG. 4 is a schematic diagram of another bus control method according to an embodiment of the present disclosure;
FIG. 5 is a schematic diagram of another bus control method according to an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of a bus controller according to an embodiment of the present disclosure;
fig. 7 is a schematic structural diagram of another bus controller according to an embodiment of the present disclosure;
fig. 8 is a schematic structural diagram of a bus control system according to an embodiment of the present disclosure;
fig. 9 is a schematic structural diagram of a vehicle according to an embodiment of the present application.
Detailed Description
The embodiment of the application provides a bus control method, which is used for improving the diagnosis efficiency of an external diagnosis device on a whole vehicle.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims, if any, of the preceding figures are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
In the embodiments of the present application, the words "exemplary" or "such as" are used herein to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.
Hereinafter, some terms in the present application are explained so as to be easily understood by those skilled in the art.
A Controller Area Network (CAN) belongs to the field bus category, and is a serial communication network that effectively supports distributed control or real-time control. Compared with many RS-485 distributed control systems, the CAN bus-based distributed control system has obvious advantages in the aspects of real-time data communication among nodes of a network and the like.
An on-board diagnostics (OBD) is a system for detecting a failure of a vehicle system, and when the vehicle system has a failure, a failure indicator lamp (MIL)) or a Check Engine (Check Engine) warning lamp is turned on, and a power assembly control module (PCM) stores failure information into a memory, and a vehicle exterior diagnostic device can read a failure code from the PCM through a certain program, so that a maintenance person can quickly and accurately determine the nature and the part of the failure according to the prompt of the failure code.
An Electronic Control Unit (ECU) is used to detect, analyze and manage a failure of the entire vehicle. The ECU typically has fault self-diagnostic and protective functions, and when a system fails, it can automatically record a fault code in memory and take protective measures to read a replacement program from the intrinsic program to maintain the operation of the engine. Meanwhile, the fault information can be displayed on an instrument panel, so that the vehicle owner can find the vehicle fault in time.
A system architecture to which the method provided in the embodiment of the present application is applicable is described below with reference to a system of a finished vehicle shown in fig. 1 as an example.
The system architecture provided by the embodiment of the application comprises a first node and a second node, wherein the first node takes a vehicle-mounted gateway as an example, and the second node takes a vehicle-mounted Electronic Control Unit (ECU) component as an example.
Referring to fig. 1, fig. 1 is a schematic diagram of a system architecture of a vehicle-mounted network according to an embodiment of the present disclosure. The vehicle-mounted network system architecture comprises a vehicle-mounted gateway and at least one opposite terminal device, wherein the opposite terminal device comprises a vehicle-mounted Electronic Control Unit (ECU) component or an external diagnostic device, and the external diagnostic device comprises a Controller Area Network (CAN) diagnostic instrument and a CAN FD diagnostic instrument. The vehicle-mounted gateway is connected with the opposite-end equipment through a CAN network, the bus protocol of the CAN network comprises a CAN protocol and a CAN FD protocol, specifically, the vehicle-mounted gateway provides one or more CAN buses externally, wherein the CAN messages or the CAN FD messages are passed on the CAN buses and depend on the ECU component of the opposite end, and when the ECU component of the opposite end is changed, the bus control method provided by the embodiment of the application CAN automatically adapt to the change of the communication protocol.
In an application scenario of the embodiment of the present application, the vehicle-mounted gateway serves as an edge node of a finished vehicle, and provides 1 path of CAN bus for finished vehicle diagnosis, as shown in fig. 1, the vehicle-mounted gateway is connected to the external diagnostic device through the vehicle-mounted diagnostic system OBD, the external diagnostic device is divided into a CAN diagnostic apparatus and a CANFD diagnostic apparatus according to types of bus protocols supported by the external diagnostic device, at present, the CAN diagnostic apparatus is mostly used by a vehicle management, and the CANFD diagnostic apparatus is mostly used by a vehicle manufacturer. The OBD channel of the whole vehicle is set with a channel supporting the CAN protocol in order to support the CAN diagnostic instrument when the whole vehicle leaves a factory by a vehicle manufacturer, the whole vehicle software needs to be refreshed through the channel of the CAN protocol before the whole vehicle leaves the factory by the vehicle manufacturer, and due to the fact that the channel transmission rate of the CAN protocol is lower than the channel transmission rate of the CAN protocol, the refreshing time of the whole vehicle software is long, and the refreshing efficiency of the whole vehicle software is affected.
In another application scenario of the embodiment of the application, the vehicle-mounted gateway and the vehicle-mounted component are connected through a CAN network, as shown in fig. 1, the vehicle-mounted gateway is connected with a plurality of vehicle-mounted ECU components, and different vehicle-mounted ECU components communicate with the vehicle-mounted gateway through different bus protocols, for example, in fig. 1, the vehicle-mounted ECU component 1 communicates with the vehicle-mounted gateway based on the CAN protocol, and the vehicle-mounted ECU component 2 communicates with the vehicle-mounted gateway based on the CANFD protocol. When the architecture of the whole vehicle is expanded or modified, the current vehicle-mounted gateway needs to refresh software again according to the bus protocol type supported by the replaced vehicle-mounted component so as to adjust the bus protocol type of the original channel. For example, when the vehicle-mounted ECU component needs to be replaced during factory maintenance of the entire vehicle, the newly replaced vehicle-mounted ECU component may not belong to the same manufacturer as the original component, the bus protocol type of the newly replaced vehicle-mounted ECU component may be changed, and at this time, a maintainer needs to update the vehicle-mounted gateway to match the bus protocol type of the newly replaced vehicle-mounted ECU component, so that plug and play of the newly replaced component cannot be realized, and thus the difficulty of maintenance operation is increased.
Referring to fig. 2, fig. 2 is a flowchart illustrating a bus control method according to an embodiment of the present disclosure. An embodiment of the present application provides a bus control flow including:
201. the first node receives a first message sent by the second node.
In this embodiment of the application, a first node receives a first packet sent by a second node, where the first packet may be a packet actively sent by the second node, or may also be a response packet sent by the second node and used for responding to the first node.
In a possible implementation manner, the content carried by the first packet includes an Acknowledgement (ACK) identifier, a Cyclic Redundancy Check (CRC) identifier, or a Remote Transmission Request (RTR) identifier, where the ACK identifier is used to indicate that the packet is received by the target node, the CRC identifier is used to check correctness of the packet, and the RTR identifier is used to distinguish a data frame or a remote frame. The type of the first message includes a CAN message and a CANFD message, the CANFD message is compared with the CAN message, and the content carried by the CANFD message further includes an FD format (FDF) flag, an Error State Indicator (ESI), and a Bit Rate Switch (BRS) flag, where the FDF flag is used to distinguish the CAN message from the CANFD message, the ESI is used to indicate an error state of a node, and the BRS flag is used to switch a data transmission rate.
Referring to fig. 3, fig. 3 is a flowchart illustrating a bus control method according to an embodiment of the present disclosure. In an example shown in fig. 3, the first node is a vehicle-mounted gateway, the second node is an off-board diagnostic device, and the off-board diagnostic device is divided into a CAN diagnostic apparatus and a CANFD diagnostic apparatus according to the types of supported bus protocols, where the CAN diagnostic apparatus CAN only recognize messages based on the CAN protocol, and the CANFD diagnostic apparatus. In steps 301 to 302 shown in fig. 3, the vehicle-mounted gateway sends a first message to the vehicle-mounted gateway, and the vehicle-mounted gateway receives the first message sent by the vehicle-mounted diagnosis device, where the first message may be a CAN protocol-based message sent by a CAN diagnostic apparatus, or a CANFD protocol-based message sent by a CANFD diagnostic apparatus, and is not limited specifically.
In the embodiment shown in fig. 2 of the present application, only a scenario in which the first packet is a packet actively sent by the first node is described, and a scenario in which the first packet is a response packet is described in detail in the embodiment shown in fig. 4 later.
202. And the first node identifies the bus protocol type of the second node according to the first message.
In this embodiment of the application, after receiving a first packet sent by a second node, a first node identifies a bus protocol type of the second node according to the first packet, and specifically, the first node parses the first packet and determines the bus protocol type of the first packet according to an FDF identifier of the first packet.
After the first node recognizes the bus protocol type of the first packet, the first node records the bus protocol type of the second node, and specifically, the first node stores the bus protocol type of the second node in a memory of the first node. And before the first node sends the service message to the second node again, the first node inquires the bus protocol type of the second node and sends the service message to the second node according to the bus protocol type of the second node.
Referring to fig. 3, fig. 3 is a flowchart illustrating a bus control method according to an embodiment of the present disclosure. In one embodiment shown in fig. 3, the first node is a vehicle-mounted gateway, the second node is an off-board diagnostic device, and in steps 303 to 304, after the vehicle-mounted gateway receives a first message sent by the on-board diagnostic device, the vehicle-mounted gateway parses the first message through a CAN controller, and identifies whether a bus protocol type of the first message is a CAN protocol or a CANFD protocol according to an FDF identifier of the first message. After the vehicle-mounted gateway identifies the bus protocol type of the first message, the vehicle-mounted gateway can determine the bus protocol type of the vehicle exterior diagnosis equipment according to the bus protocol type of the first message, record the bus protocol type of the vehicle exterior diagnosis equipment and store the bus protocol type of the vehicle exterior diagnosis equipment.
203. And the first node sends a second message to the second node, wherein the bus protocol type of the second message is consistent with that of the first message.
In the embodiment of the application, the first node sends the second message to the second node, where the second message is consistent with the total protocol type of the second node, the second message may be a service message sent by the first node to the second node, and before the first node sends the second message to the second node, the first node queries the bus protocol type of the second node.
Referring to fig. 3, fig. 3 is a flowchart illustrating a bus control method according to an embodiment of the present disclosure. In one embodiment as shown in fig. 3, the first node is an onboard gateway and the second node is an offboard diagnostic device. In steps 305 to 308 shown in fig. 3, the vehicle-mounted gateway sends the second message to the vehicle-mounted diagnostic device, before the vehicle-mounted gateway sends the second message to the vehicle-mounted diagnostic device, the vehicle-mounted gateway queries the bus protocol type of the vehicle-mounted diagnostic device in the memory, the vehicle-mounted network gateway sends the total protocol type queried by the vehicle-mounted diagnostic device to the CAN controller, and the vehicle-mounted gateway sends the second message to the vehicle-mounted diagnostic device through the CAN controller.
According to the embodiment of the application, the first node can automatically identify the bus protocol type of the second node according to the message sent by the second node, and the communication efficiency of the first node and the second node is improved. Further, when the embodiment of the application is applied to a vehicle diagnosis scene, the vehicle-mounted gateway can automatically identify the bus protocol type supported by the under-vehicle diagnostic apparatus according to the message sent by the under-vehicle diagnostic apparatus, so that the diagnosis efficiency of the vehicle is improved.
Referring to fig. 4, fig. 4 is a schematic flowchart illustrating another bus control method according to an embodiment of the present disclosure. Another bus control flow provided by the embodiment of the present application includes:
401. the first node sends at least one third message to the second node, and the third message is used for detecting the bus protocol of the second node.
In this embodiment of the present application, a first node sends at least one third packet to a second node, where the third packet may be used to detect a bus protocol type supported by the second node, and the first node may send multiple third packets to the second node, where the multiple third packets are sent in different bus protocol types, and the different bus protocol types are used to detect a bus protocol type supported by the second node.
Referring to fig. 5, fig. 5 is a flowchart illustrating another bus control method according to an embodiment of the present disclosure. In one example shown in fig. 5, the first node is an in-vehicle gateway and the second node is an in-vehicle ECU component. Different vehicle-mounted ECU components support different bus protocol types, and the bus protocol types of the vehicle-mounted ECU components include a CAN protocol and a CANFD protocol, for example, in the entire vehicle architecture shown in fig. 1, the bus protocol type supported by the vehicle-mounted ECU component 1 is the CAN protocol, and the bus protocol type supported by the vehicle-mounted ECU component 2 is the CANFD protocol. In steps 501 to 504 shown in fig. 5, when a replacement occurs in the in-vehicle ECU component, the in-vehicle gateway cannot determine the bus protocol type supported by the newly replaced in-vehicle ECU component. In this scenario, the vehicle-mounted gateway sends a third message to the vehicle-mounted ECU component, where the third message includes a detection message based on the CAN protocol type or a detection message based on the CANFD protocol, and specifically, the vehicle-mounted gateway may send the detection message based on the CAN protocol to the vehicle-mounted ECU component first, and if the vehicle-mounted gateway does not receive a response message of the detection message based on the CAN protocol, the vehicle-mounted gateway sends the detection message based on the CANFD protocol to the vehicle-mounted ECU component again.
402. And the second node sends a first message to the first node, wherein the first message is used for responding to the third message according to the protocol type of the third message.
In this embodiment of the present application, the second node sends the first packet to the first node, where the first packet is used to respond to the third packet according to a protocol type of the third packet, that is, the first packet is a response packet of the third packet.
In an example of the present application, the first message includes a response message based on a CAN protocol or a response message based on a CANFD protocol.
Referring to fig. 5, fig. 5 is a flowchart illustrating another bus control method according to an embodiment of the present disclosure. In one example shown in fig. 5, the first node is an in-vehicle gateway and the second node is an in-vehicle ECU component. In steps 501 to 504 shown in fig. 5, the vehicle-mounted gateway sends a third message to the vehicle-mounted ECU component, where the third message is a detection message based on the CAN protocol, and after the vehicle-mounted gateway sends the detection message based on the CAN protocol to the vehicle-mounted ECU component, the vehicle-mounted gateway determines whether to receive the first message responding to the detection message, and if the first message responding to the detection message is not received within a preset time period, the vehicle-mounted gateway sends the detection message based on the CANFD protocol to the vehicle-mounted ECU component, and if the vehicle-mounted gateway receives the first message responding to the detection message, the vehicle-mounted gateway may determine the bus protocol type of the second node according to the first message.
403. The first node identifies the bus protocol type of the second node according to the first message.
In this embodiment of the application, after receiving a first packet sent by a second node, a first node identifies a bus protocol type of the second node according to the first packet, and specifically, the first node analyzes the first packet and determines the bus protocol type of the first packet according to an FDF identifier of the first packet.
After the first node recognizes the bus protocol type of the first packet, the first node records the bus protocol type of the second node, and specifically, the first node stores the bus protocol type of the second node in a memory of the first node. And before the first node sends the service message to the second node again, the first node inquires the bus protocol type of the second node and sends the service message to the second node according to the bus protocol type of the second node.
Referring to fig. 5, fig. 5 is a flowchart illustrating a bus control method according to an embodiment of the present disclosure. In one embodiment as shown in fig. 5, the first node is an in-vehicle gateway and the second node is an in-vehicle ECU component. In steps 505 to 506 shown in fig. 5, after the vehicle-mounted gateway receives the first message sent by the vehicle-mounted diagnostic device, the vehicle-mounted gateway analyzes the first message through the CAN controller, and identifies whether the bus protocol type of the first message is the CAN protocol or the CANFD protocol according to the FDF identifier of the first message, if the FDF identifier exists in the first message, the bus protocol type of the vehicle-mounted ECU component is the CANFD protocol, and if the FDF identifier does not exist in the first message, the bus protocol type of the vehicle-mounted ECU component is the CAN protocol. And after the bus protocol type of the vehicle-mounted ECU component is identified by the vehicle-mounted gateway, the bus protocol type of the vehicle-mounted ECU component is stored.
404. And the first node sends a second message to the second node, wherein the protocol type of the second message is consistent with the bus protocol type of the second node.
In the embodiment of the application, the first node sends the second message to the second node, the second message is consistent with the total protocol type of the second node, the second message can be a service message sent by the first node to the second node, and the first node queries the bus protocol type of the second node before the second message sent by the first node to the second node.
Referring to fig. 5, fig. 5 is a flowchart illustrating a bus control method according to an embodiment of the present disclosure. In one embodiment as shown in fig. 5, the first node is an in-vehicle gateway and the second node is an in-vehicle ECU component. In steps 507 to 510 shown in fig. 5, the vehicle-mounted gateway sends the second message to the vehicle-mounted ECU component, queries the bus protocol type of the vehicle-mounted ECU component before sending the second message, and sends the second message to the vehicle-mounted ECU component according to the bus protocol type of the vehicle-mounted ECU component.
In the embodiment of the application, the first node sends the detection message to the second node, so that the first node determines the bus protocol type of the second node according to the response message responding to the detection message, when the second node in the network system changes, the bus protocol type of the second node can be automatically identified, the bus protocol type of the first node does not need to be modified, and the communication efficiency of the network system is improved.
Further, when the embodiment of the application is applied to a vehicle-mounted network and when the system architecture of the whole vehicle is expanded or modified, the vehicle-mounted gateway can determine the bus protocol type of the vehicle-mounted ECU component at the opposite end by sending the detection message, and direct communication is performed without modifying the bus protocol type of the vehicle-mounted network gateway, so that the communication efficiency of the vehicle is improved.
The bus control method provided by the embodiment of the present application is described above, and the related devices related to the embodiment of the present application are described below with reference to the accompanying drawings.
Referring to fig. 6, fig. 6 is a schematic structural diagram of a bus control device according to an embodiment of the present disclosure. The bus control apparatus is used for implementing the steps corresponding to the first node or the second node in the embodiments, as shown in fig. 6, the bus control apparatus 600 includes an interface unit 601 and a processing unit 602.
In one embodiment, the bus control device 600 is configured to implement the steps corresponding to the first node in the above embodiments:
an interface unit 601, configured to receive a first packet sent by a second node; for a specific implementation manner, reference may be made to the detailed description of step 201 in the implementation shown in fig. 2 and the detailed description of step 301 to step 302 in the embodiment shown in fig. 3, or the detailed description of step 401 in the embodiment shown in fig. 4 and the detailed description of step 501 to step 504 in the embodiment shown in fig. 5, which are not described again here.
A processing unit 602, configured to identify a bus protocol type of the second node according to the first packet; for a specific implementation manner, reference may be made to the detailed description of step 202 in the implementation shown in fig. 2 and the detailed description of step 303 to step 307 in the embodiment shown in fig. 3, or the detailed description of step 403 in the embodiment shown in fig. 4 and the detailed description of step 505 to step 509 in the embodiment shown in fig. 5, which are not described again here.
The interface unit 601 is further configured to send a second packet to the second node based on the bus protocol type, where the protocol type of the second packet is consistent with the bus protocol type of the second node, and the specific implementation may refer to the detailed description of step 203 in the implementation shown in fig. 2 and the detailed description of step 308 in the embodiment shown in fig. 3, or refer to the detailed description of step 404 in the embodiment shown in fig. 4 and the detailed description of step 510 in the embodiment shown in fig. 5, which is not described again here.
In a possible implementation manner, the interface unit 601 is further configured to send at least one third packet to the second node, where the third packet is used to detect a bus protocol type of the second node, and the first packet is used to respond to the third packet according to the bus protocol type of the third packet.
In one possible embodiment, the bus protocol type includes a CAN protocol or a CANFD protocol, the first node includes an onboard gateway, and the second node includes an onboard electronic control ECU component or an offboard diagnostic device.
In a possible implementation manner, the processing unit 602 is specifically configured to identify the bus protocol type of the second node according to the FDF flag in the first message.
In a possible implementation manner, after the first node identifies the bus protocol type of the second node according to the first packet, the processing unit 602 is further configured to record the bus protocol type of the second node.
In a possible implementation manner, before the first node sends the second packet to the second node based on the bus protocol type, the processing unit 602 is further configured to query the bus protocol type of the second node.
In one embodiment, the bus control device 600 is configured to implement the steps corresponding to the second node in the foregoing embodiments:
the interface unit 601 is configured to send a first packet to a first node, where the first packet is used for the first node to identify a bus protocol type of a second node, and the interface unit 601 is further configured to receive a second packet sent by the first node, where the second packet is consistent with the bus protocol type of the second node.
For specific implementation of the interface unit 601 and the processing unit 602, reference may be made to the detailed description of step 201 to step 203 in the implementation shown in fig. 2 and the detailed description of step 301 to step 308 in the embodiment shown in fig. 3, or to the detailed description of step 401 to step 404 in the embodiment shown in fig. 4 and the detailed description of step 501 to step 510 in the embodiment shown in fig. 5, which is not described again here.
In a possible implementation manner, before the interface unit 601 sends the first packet to the first node, the interface unit 601 is further configured to receive at least one third packet sent by the first node, where the third packet is used to detect a bus protocol type of the second node, and the first packet is used to respond to the third packet according to the bus protocol type of the third packet.
In one possible embodiment, the bus protocol type includes a CAN protocol or a CANFD protocol. The first node comprises an onboard gateway and the second node comprises an onboard electronic control, ECU, component or an offboard diagnostic device.
Optionally, the communication device may further include a storage unit, which is used for storing data or instructions (also referred to as codes or programs), and the units may interact with or be coupled with the storage unit to implement corresponding methods or functions. For example, the processing unit 602 may read data or instructions in the storage unit, so that the communication device implements the method in the above-described embodiments.
It should be understood that the division of the units in the above communication device is only a division of logical functions, and the actual implementation may be wholly or partially integrated into one physical entity or may be physically separated. And the units in the communication device can be realized in the form of software called by the processing element; or may be implemented entirely in hardware; part of the units can also be realized in the form of software called by a processing element, and part of the units can be realized in the form of hardware. For example, each unit may be a processing element separately set up, or may be implemented by being integrated in a chip of the communication apparatus, or may be stored in a memory in the form of a program, and a function of the unit may be called and executed by a processing element of the communication apparatus. In addition, all or part of the units can be integrated together or can be independently realized. The processing element described herein may in turn be a processor, which may be an integrated circuit having signal processing capabilities. In the implementation process, the steps of the method or the units above may be implemented by integrated logic circuits of hardware in a processor element or in a form called by software through the processor element.
In one example, the units in any of the above communication devices may be one or more integrated circuits configured to implement the above methods, such as: one or more Application Specific Integrated Circuits (ASICs), or one or more microprocessors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs), or a combination of at least two of these integrated circuit forms. As another example, when a unit in a communication device may be implemented in the form of a processing element scheduler, the processing element may be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor that may invoke a program. As another example, these units may be integrated together and implemented in the form of a system-on-a-chip (SOC).
Referring to fig. 7, fig. 7 is a schematic diagram of a bus control apparatus according to an embodiment of the present disclosure, for implementing the operation of the first node in the foregoing embodiment. As shown in fig. 7, the bus control apparatus includes: a processor 710 and an interface 730, the processor 710 being coupled to the interface 730.
The interface 730 is configured to receive a first packet sent by a second node, and a specific implementation manner may refer to the detailed description of step 201 in the implementation shown in fig. 2 and the detailed descriptions of step 301 to step 302 in the embodiment shown in fig. 3, or the detailed description of step 401 in the embodiment shown in fig. 4 and the detailed descriptions of step 501 to step 504 in the embodiment shown in fig. 5, which is not described again here.
The processor 710 is configured to identify a bus protocol type of the second node according to the first packet, and the specific implementation manner may refer to the detailed description of step 202 in the implementation shown in fig. 2 and the detailed description of step 303 to step 307 in the embodiment shown in fig. 3, or the detailed description of step 403 in the embodiment shown in fig. 4 and the detailed description of step 505 to step 509 in the embodiment shown in fig. 5, which is not described herein again.
The interface 730 is further configured to send a second packet to the second node based on the bus protocol type, where the protocol type of the second packet is consistent with the bus protocol type of the second node, and the specific implementation manner may refer to the detailed description of step 203 in the implementation shown in fig. 2 and the detailed description of step 308 in the embodiment shown in fig. 3, or the detailed description of step 404 in the embodiment shown in fig. 4 and the detailed description of step 510 in the embodiment shown in fig. 5, which is not described again here.
Interface 730 is used to enable communication with other devices. Interface 730 may be a transceiver or an input-output interface. The interface 730 may be, for example, an interface circuit.
Optionally, the communication device further comprises a memory 720 for storing instructions to be executed by the processor 710 or for storing input data required by the processor 710 to execute the instructions or for storing data generated by the processor 710 after executing the instructions.
The method performed by the first node in the above embodiments may be implemented by the processor 710 calling a program stored in a memory (which may be the memory 720 in the network device or the terminal, or may be an external memory). That is, the first node may include a processor 710, and the processor 710 may execute the method performed by the first node in the above method embodiment by calling a program in a memory. The processor here may be an integrated circuit with signal processing capabilities, such as a CPU. The controller or server may be implemented by one or more integrated circuits configured to implement the above method. For example: one or more ASICs, or one or more microprocessors DSP, or one or more FPGAs, etc., or a combination of at least two of these integrated circuit forms. Alternatively, the above implementations may be combined.
Specifically, the functions/implementation processes of the interface unit 601 and the processing unit 602 in fig. 6 can be implemented by the processor 710 in the bus control apparatus 700 shown in fig. 7 calling the computer executable instructions stored in the memory 720. Alternatively, the function/implementation procedure of the processing unit 602 in fig. 6 may be implemented by the processor 710 in the bus control apparatus 700 shown in fig. 7 calling a computer executing instruction stored in the memory 720, the function/implementation procedure of the interface unit 601 in fig. 6 may be implemented by the interface 730 in the bus control apparatus 700 shown in fig. 7, and the function/implementation procedure of the interface unit 601 may be implemented by the processor calling a program instruction in the memory to drive the interface 730.
The interface unit 601 in the bus control device 600 corresponds to the interface 730 in the bus control device 700, and the processing unit 602 in the bus control device 600 may correspond to the processor 710 in the bus control device 700.
Referring to fig. 8, fig. 8 is a schematic diagram of a bus control system according to an embodiment of the present disclosure, where the bus control system 800 includes a first node 801 and a second node 802, the first node 801 may be a first node in the foregoing method embodiment, and the second node 802 may be a second node in the foregoing method embodiment.
Referring to fig. 9, fig. 9 is a schematic structural diagram of a vehicle according to an embodiment of the present application, where the vehicle 900 includes a vehicle-mounted gateway 901 and a vehicle-mounted component 902, the vehicle-mounted gateway 901 may be a first node in the foregoing method embodiment, and the vehicle-mounted component 902 may be a second node in the foregoing method embodiment.
In another embodiment of the present application, a computer-readable storage medium is further provided, in which a computer executes instructions, and when a processor of the device executes the computer to execute the instructions, the device executes the method performed by the first node in the above method embodiment.
In another embodiment of the present application, there is also provided a computer program product comprising computer executable instructions stored in a computer readable storage medium. When the processor of the device executes the computer-executable instructions, the device performs the steps of the method performed by the first node in the above-described method embodiment.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

Claims (12)

1. A bus control method, comprising:
a first node receives a first message sent by a second node;
the first node identifies the bus protocol type of the second node according to the first message;
and the first node sends a second message to a second node based on the bus protocol type, wherein the protocol type of the second message is consistent with the bus protocol type of the second node.
2. The method of claim 1, wherein before the first node receives the first packet sent by the second node, the method further comprises:
the first node sends at least one third message to the second node, the third message is used for detecting the bus protocol type of the second node, and the first message is used for responding to the third message according to the bus protocol type of the third message.
3. The method of claim 1 or 2, wherein the bus protocol type comprises a CAN protocol or a CANFD protocol, the first node comprises an onboard gateway, and the second node comprises an onboard electronic control ECU component or an offboard diagnostic device.
4. The method according to any of claims 1 to 3, wherein the first node identifying the bus protocol type of the second node from the first packet comprises:
and the first node identifies the bus protocol type of the second node according to the FDF mark in the first message.
5. The method according to any of claims 1 to 4, wherein after the first node identifies the bus protocol type of the second node from the first packet, the method further comprises:
and the first node records the bus protocol type of the second node.
6. The method according to any of claims 1 to 5, wherein before the first node sends a second packet to a second node based on the bus protocol type, the method further comprises:
the first node queries the second node for the bus protocol type.
7. A bus controller, characterized in that it comprises means or modules for performing the method of any of the preceding claims 1 to 6.
8. A bus controller comprising a processor coupled with a memory, the processor to store instructions that when executed by the processor cause the bus controller to perform the method of any of claims 1 to 6.
9. A bus control system, comprising: a first node and a second node, the first node being configured to perform the method of any of claims 1 to 6.
10. A vehicle comprising an onboard gateway and onboard means, said onboard gateway being adapted to perform the method performed by the first node of any one of claims 1 to 6.
11. A computer readable storage medium having instructions stored thereon that, when executed, cause a computer to perform the method of any of claims 1 to 6.
12. A computer program product comprising instructions therein, which when executed, cause a computer to implement the method of any of claims 1 to 6.
CN202110845858.8A 2021-07-26 2021-07-26 Bus control method and related device Pending CN115701034A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202110845858.8A CN115701034A (en) 2021-07-26 2021-07-26 Bus control method and related device
PCT/CN2022/107590 WO2023005866A1 (en) 2021-07-26 2022-07-25 Bus control method and related apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110845858.8A CN115701034A (en) 2021-07-26 2021-07-26 Bus control method and related device

Publications (1)

Publication Number Publication Date
CN115701034A true CN115701034A (en) 2023-02-07

Family

ID=85086285

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110845858.8A Pending CN115701034A (en) 2021-07-26 2021-07-26 Bus control method and related device

Country Status (2)

Country Link
CN (1) CN115701034A (en)
WO (1) WO2023005866A1 (en)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8788139B2 (en) * 2011-03-21 2014-07-22 Webtech Wireless Inc. Multi-protocol vehicle diagnostic interface device and method
CN108207039B (en) * 2016-12-19 2021-05-14 比亚迪股份有限公司 Safe transmission method of vehicle-mounted data, external equipment and vehicle-mounted gateway
CN111835627B (en) * 2019-04-23 2022-04-26 华为技术有限公司 Communication method of vehicle-mounted gateway, vehicle-mounted gateway and intelligent vehicle
US10496575B1 (en) * 2019-06-12 2019-12-03 National Chin-Yi University Of Technology Multi-protocol determining method based on CAN bus
CN110661847B (en) * 2019-08-28 2022-06-24 北京经纬恒润科技股份有限公司 Vehicle diagnosis method and apparatus

Also Published As

Publication number Publication date
WO2023005866A1 (en) 2023-02-02

Similar Documents

Publication Publication Date Title
US10986008B2 (en) Abnormality detection in an on-board network system
US11296965B2 (en) Abnormality detection in an on-board network system
CN105745871B (en) Vehicle having an ethernet bus system and method for operating such a bus system
US9705699B2 (en) Method and apparatus for reducing load in can communication
US10581739B2 (en) System for verification of unregistered device based on information of Ethernet switch and method for the same
CN112805645B (en) Vehicle remote diagnosis method and related device
US6643465B1 (en) Method for checking a ring optical network line for data transmission between a plurality of network subscribers in a motor vehicle
JP2005529419A (en) Method and apparatus for telematic services for vehicles
CN113093687B (en) Fault diagnosis system and method based on domain controller
US10673986B2 (en) Operation method of communication node for selective wake-up in vehicle network
US10594587B2 (en) Operation method of communication node for diagnosing vehicle network
KR101450166B1 (en) Method and apparatus for updating routing information in in-vehicle communication network
CN111108725A (en) Method for monitoring communication on a communication bus and electronic device for connection to a communication bus
CN105005539A (en) Authenticating data at a microcontroller using message authentication codes
CN108919788A (en) A kind of remote monitoring system and method for the automobile bench test based on vehicle-mounted CAN bus
JP3227309U (en) System and method for error recording mechanism in a controller area network bus
CN112511396A (en) Whole vehicle communication monitoring method and device
US10341170B2 (en) Method for diagnosing link status in network
CN102710479B (en) Automobile gateway system for inverse resolution of communication protocols
CN115225481B (en) Gateway diagnosis route configuration method and device, vehicle-mounted gateway, vehicle and medium
CN115701034A (en) Bus control method and related device
US20220329614A1 (en) Method for monitoring communication on a communication bus, electronic device for connection to a communication bus, and central monitoring device for connection to a communication bus
CN110177032B (en) Message routing quality monitoring method and gateway controller
CN114115178A (en) Vehicle radar diagnosis method and system based on domain controller
CN112235195B (en) Method for processing reported data and related equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination