Vehicle communication interface management method and device and medium

Abstract

The invention discloses a vehicle communication interface management method and device and a medium, and is applied to a main controller in a vehicle, the main controller is a top-layer controller in the vehicle, and the method comprises the following steps: when a trigger signal of interface compatibility verification is received, forwarding a verification signal to a slave controller step by step; obtaining an interface information message of a to-be-verified controller in the slave controllers; and verifying the interface compatibility of the controller to be verified according to the interface information message. Therefore, when interface compatibility verification needs to be carried out, the verification signals are sent to the slave controllers step by step through the master controller, so that compatibility verification is carried out according to the interface information messages returned by the slave controllers, and the compatibility problem among the controller interfaces in the vehicle is rapidly identified.

Description

Technical Field

[0001] The present application relates to the field of vehicle communication technology, and in particular to a vehicle communication interface management method, device and medium. Background Art

[0002] Today's smart cars contain a variety of controllers. As vehicle configurations change, the communication interfaces between different controllers differ. For example, controller A uses version 01 of the communication interface, and controller B uses version 02 of the communication interface. This can lead to version compatibility issues between different versions of the communication interfaces.

[0003] In order to ensure normal communication between the various controllers, the version 02 communication interface is usually designed to be compatible with the version 01, so as to avoid problems when the vehicle is performing OTA (Over the Air) upgrades and other services. However, when the communication interface versions used by different controllers vary greatly, the compatibility problem is difficult to solve, and the versions used by each controller must be forced to remain consistent before the OTA upgrade can be performed. Specifically, before the OTA upgrade, it is necessary to manually compare the compatibility of the communication interfaces of each controller. Only after the compatibility problem is resolved can the upgrade task be issued.

[0004] Furthermore, after an OTA upgrade, communication anomalies can sometimes occur, requiring manual verification of the compatibility of the communication interfaces of each controller. Clearly, manual verification of communication interface compatibility is slow and costly, unable to meet the demands of rapid OTA upgrades and severely impacting the user experience.

[0005] Therefore, how to quickly verify the compatibility of all controller communication interfaces in the vehicle and ensure the normal operation of services such as OTA upgrades is an urgent problem to be solved by technical personnel in this field. Summary of the Invention

[0006] In view of this, one aspect of the present application provides a vehicle communication interface management method, which is applied to a main controller in a vehicle, where the main controller is a top-level controller in the vehicle. The method includes:

[0007] When receiving the trigger signal of the interface compatibility check, the check signal is forwarded to the slave controller step by step;

[0008] Obtaining the interface information message of the controller to be verified from the slave controller;

[0009] The interface compatibility of the controller to be verified is verified according to the interface information message.

[0010] Optionally, the verification signal includes at least a master control baseline version number of the master controller; the verification controller includes a controller whose slave control baseline version number is different from the master control baseline version number.

[0011] Optionally, the interface information message includes at least a controller unique identifier and an interface hash value.

[0012] Optionally, the interface hash value is a value calculated by hashing specific information of the controller interface;

[0013] When the controller interface is a signal interface, the specific information includes at least a signal name, a signal type, and a signal location;

[0014] When the controller interface is a service-type interface, the specific information at least includes a service signal type and a service signal name.

[0015] Optionally, verifying the interface compatibility of the controller to be verified according to the interface information message includes:

[0016] Obtain the controller unique identifier and interface hash value of the main controller;

[0017] Concatenate the controller unique identifier and interface hash value of the main controller with the controller unique identifier and interface hash value of the controller to be verified to obtain a concatenation result;

[0018] Performing signature calculation on the splicing result to obtain a signature value to be verified;

[0019] Determine whether the signature value to be verified belongs to a preset mapping list; wherein the preset mapping list is a mapping relationship between the master control baseline version number and the reference signature value;

[0020] If yes, determine whether the communication interface of the controller to be verified is compatible with that of the main controller.

[0021] Optionally, the reference signature value includes a first signature value and a second signature value;

[0022] The first signature value is a value calculated by signature based on the controller unique identifiers of the master controller and all the slave controllers and the interface hash value;

[0023] The second signature value is a value calculated based on the controller unique identifiers and interface hash values of the master controller and the slave controller, respectively.

[0024] Optionally, forwarding the verification signal to the slave controller step by step includes:

[0025] If the interface compatibility check is in the first mode supporting periodic broadcast, the verification signal further includes other interface information of the master controller in addition to the master control baseline version number, and the verification signal is forwarded to the slave controllers in a periodic broadcast form step by step according to the inter-controller communication protocol;

[0026] If the interface compatibility check is in the second mode of prohibiting periodic broadcasting, the check signal only includes the master control baseline version number, and the check signal is forwarded to the slave controllers step by step in a unicast form.

[0027] Optionally, the communication protocol includes a first protocol and a second protocol; a message length supported by the first protocol is greater than a message length supported by the second protocol;

[0028] When the communication protocol is the first protocol, the other interface information includes at least a controller unique identifier and an interface hash value of the main controller;

[0029] When the communication protocol is the second protocol, the other interface information includes a controller unique identifier of the main controller.

[0030] Optionally, the trigger signal includes a first signal and a second signal; the first signal is used to detect an interface incompatibility event and locate the controller where the incompatibility event occurs; the second signal is only used to determine the occurrence of the incompatibility event;

[0031] If the trigger signal is the first signal, the controller to be verified is a controller whose slave control baseline version number is different from the master control baseline version number;

[0032] If the trigger signal is the second signal, the controllers to be verified are all the slave controllers.

[0033] Another aspect of the present application provides a vehicle communication interface management device, which is applied to a main controller in a vehicle, wherein the main controller is a top-level controller in the vehicle, and the device includes:

[0034] The signal forwarding module is used to forward the verification signal to the slave controller step by step when receiving the trigger signal of the interface compatibility verification;

[0035] A message acquisition module, used to acquire the interface information message of the controller to be verified from the controller;

[0036] A compatibility verification module is used to verify the interface compatibility of the controller to be verified according to the interface information message.

[0037] Another aspect of the present application provides a vehicle communication interface management device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the steps of the vehicle communication interface management method are implemented.

[0038] Another aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the vehicle communication interface management method when the program is executed by a processor.

[0039] The vehicle communication interface management method, device and medium provided in the present application have the following beneficial effects: when interface compatibility verification is required, the verification signal is sent down to each slave controller step by step through the main controller, so that compatibility verification can be performed based on the interface information message returned by the slave controller, thereby quickly identifying compatibility issues between the various controller interfaces in the vehicle and ensuring the normal operation of services such as OTA upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A flow chart of a vehicle communication interface management method provided in an embodiment of the present application;

[0041] Figure 2 A schematic diagram of the architecture of a vehicle controller provided in an embodiment of the present application;

[0042] Figure 3 A flow chart of a method for determining an interface hash value provided in an embodiment of the present application;

[0043] Figure 4 A flowchart of a vehicle communication interface management method provided by another embodiment of the present application;

[0044] Figure 5 A schematic diagram of the principle of a vehicle communication interface management method provided in an embodiment of the present application;

[0045] Figure 6 A schematic diagram illustrating another vehicle communication interface management method provided in an embodiment of the present application;

[0046] Figure 7 A schematic diagram of the principle of another vehicle communication interface management method provided in an embodiment of the present application;

[0047] Figure 8 A schematic diagram of the principle of a vehicle communication interface management method provided by another embodiment of the present application;

[0048] Figure 9 A schematic diagram of the structure of a vehicle communication interface management device provided in an embodiment of the present application;

[0049] Figure 10 This is a structural diagram of a vehicle communication interface management device provided in another embodiment of the present application.

[0050] The reference numerals are as follows: 20 is a memory, 21 is a processor, 22 is a display screen, 23 is an input and output interface, 24 is a communication interface, 25 is a power supply, 26 is a communication bus, 201 is a computer program, 202 is an operating system, and 203 is data. DETAILED DESCRIPTION

[0051] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0052] It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0053] Figure 1 A flow chart of a vehicle communication interface management method provided in an embodiment of the present application is shown as follows: Figure 1 As shown, the method includes:

[0054] S10: upon receiving a trigger signal for interface compatibility verification, forwarding the verification signal to the slave controller step by step;

[0055] First, it should be noted that the vehicle communication interface management method provided in this application applies to the vehicle's highest-level master controller, i.e., the top-level controller. In specific embodiments, the master controller is the core component of the vehicle controller, at the highest level, responsible for global decision-making, task allocation, and cross-domain coordination.

[0056] Figure 2 A schematic diagram of the architecture of a vehicle controller provided in an embodiment of the present application is shown in FIG. Figure 2As shown, in an optional embodiment, the controllers on the vehicle can be roughly divided into a master controller and a slave controller, wherein the slave controller can include a domain controller and a sub-controller, and the domain controller has a higher control level than the sub-controller. Of course, the control level can also be divided into more layers based on control logic relationships, that is, the control level is not limited to this.

[0057] In a specific embodiment, the master controller can support networking, diagnostic agent and OTA upgrade management, and the slave controller can support network communication protocols such as Ethernet, Controller Area Network (CAN), Flexray bus, Local Interconnect Network (LIN), etc. Figure 2 As shown, in an optional embodiment, the main controller is communicatively connected to the domain controller, and the domain controller is communicatively connected to each sub-controller.

[0058] In addition, it should be noted that the vehicles to which the vehicle communication interface management method provided in the embodiments of the present application can be applied may include but are not limited to sedans, sport utility vehicles (SUVs), multi-purpose vehicles (MPVs), off-road vehicles, pickup trucks or other power-driven non-track-borne vehicles.

[0059] In a specific embodiment, when the master controller receives the trigger signal of the interface compatibility check, it forwards the check signal to the slave controller step by step. Figure 2 As shown, in an optional embodiment, forwarding can be performed step by step based on the control hierarchy. That is, the master controller sends the verification signal to the domain controller, and the domain controller forwards the verification signal to the sub-controller. This application does not limit the form of step-by-step forwarding, as long as each slave controller can receive the verification signal.

[0060] It is worth noting that in a specific embodiment, the trigger signal can be a passive trigger signal or an active trigger signal, wherein the passive trigger signal is sent to the controller by an external device, and the active trigger signal may include but is not limited to normal power-on of the entire vehicle, wake-up from sleep mode of the entire vehicle, software update, driving mode switching (for example, seat mode switching, etc.).

[0061] When the trigger signal is sent by an external device, in order to ensure the safety of the entire vehicle system, the identity of the external device must be verified first. Only when the identity verification is passed can the verification signal be sent down to each slave control level by level.

[0062] S11: Obtaining the interface information message of the controller to be verified from the controller;

[0063] In an optional embodiment, after receiving the verification signal sent by the main controller, the slave controller determines that there is an interface compatibility verification task, and then encapsulates its own interface version information into an interface information message and returns it to the main controller step by step.

[0064] At this point, the master controller obtains the interface information message of the controller to be verified from the slave controllers in step S11. Specifically, after the master controller issues the verification signal, it obtains the interface message information returned from the controller to be verified within a preset time period. The controller to be verified can be a portion of the controllers undergoing interface compatibility verification or all slave controllers, which is not limited in this application.

[0065] S12: Verify the interface compatibility of the controller to be verified according to the interface information message.

[0066] Furthermore, after obtaining the interface information message returned by the controller to be verified, the interface compatibility of the controller to be verified is verified based on the interface information message. The interface information message refers to a message carrying interface version information, that is, the interface information message returned by the controller to be verified carries its own interface version information message.

[0067] When reporting interface information messages, the controller to be verified encapsulates its own interface version information into a message and sends it to the upper-level controller with which it communicates. The upper-level controller then forwards the message to the next higher-level controller, and finally to the master controller. In other words, similar to sending messages down one level at a time, interface information messages are reported to the master controller one level at a time.

[0068] For example, Figure 2 As shown, when any sub-controller determines that its slave control baseline version number is different from the master control baseline version number, it encapsulates the interface version information stored locally into a message and sends it to the domain controller connected to itself, which then forwards it to the master controller.

[0069] It should be noted that all controllers on the vehicle, i.e., the master controller and the slave controller, store version information of their respective controller interfaces. In addition to the baseline version number, the interface version information may also include but is not limited to the controller unique identifier, interface type, and number of interfaces.

[0070] Therefore, the vehicle communication interface management method provided in the embodiment of the present application, when interface compatibility verification is required, sends verification signals to each slave controller step by step through the main controller, so as to perform compatibility verification based on the interface information message returned by the slave controller, thereby realizing rapid identification of compatibility issues between the various controller interfaces in the vehicle and ensuring the normal operation of services such as OTA upgrades.

[0071] In an optional embodiment, the verification signal includes at least a master control baseline version number of the master controller; the verification controller includes a controller whose slave control baseline version number is different from the master control baseline version number.

[0072] In an optional embodiment, the verification signal includes at least the master baseline version number of the master controller. It is understandable that when performing controller interface verification, if the baseline version numbers of the controllers are the same, the controller interfaces are compatible. If the baseline version numbers are different, the communication interfaces are not necessarily incompatible and further verification is required. Therefore, the method provided in the embodiment of the present application carries the master baseline version number in the verification signal so that the slave controller can compare its own slave baseline version number with the master baseline version number.

[0073] It should be noted that after the master controller issues a verification signal, it retrieves messages from the slave controllers within a preset time period. This means it obtains interface message information from the slave controllers to be verified. The controllers to be verified can be all slave controllers, including those with the same and different slave baseline version numbers as the master. This means that interface compatibility is verified for all controllers.

[0074] Of course, the controllers to be verified may also include only controllers whose slave control baseline version numbers differ from the master control baseline version numbers. In this case, only the interface compatibility of the controllers to be verified is verified. It is understandable that, based on the baseline version number verification, only the interface compatibility of the controllers to be verified is verified, which can greatly improve the verification efficiency.

[0075] In an optional embodiment, it is understood that when the main controller verifies the interface compatibility of the controller to be verified, it needs to know which controller uploaded the interface information message, and the controller unique identifier (UniqueIdentifier) can be used to distinguish and identify different controllers. Therefore, the interface information message includes at least the controller unique identifier,

[0076] At present, the description forms of in-vehicle communication interfaces mainly include XML format, JSON format and some customized IDL format files. The core content is still text files, which contain various interface definitions. In order to quickly identify whether there are differences in the interface definitions of different versions, the previous practice is to count the detailed contents of each communication interface file and then compare the differences in their plain text. Obviously, this method will expose detailed information of the interface, leading to information leakage, network attacks, system control risks, data tampering risks, business interruption, identity authentication and authorization risks, etc.

[0077] Therefore, to address the aforementioned technical issues, the communication interface management method provided in the embodiments of this application proposes a scaling mapping solution. Specifically, the specific information in the interface definition file is hashed to calculate an interface hash value, allowing the compatibility between interfaces to be determined based on the interface hash value. Therefore, the interface information message reported by the controller to be verified includes not only the controller's unique identifier but also the interface hash value.

[0078] It should be noted that all vehicle controllers, namely the master and slave controllers, internally store their own interface version information. The interface hash value is calculated by the backend when the communication interface data is released, and the calculation results are transmitted and stored to the corresponding controllers one by one. Furthermore, it should be noted that in addition to the controller's unique identifier and interface hash value, the interface information message may also include, but is not limited to, the controller name, number of interfaces, interface type, and service type.

[0079] In an optional embodiment, the interface hash value is a value calculated by hashing specific information of the controller interface. In a specific embodiment, the specific information selected is different for different types of interfaces. In an optional embodiment, the controller interfaces are divided into signal interfaces and service interfaces.

[0080] When the controller interface is a signal interface, the specific information used to calculate the interface hash value includes at least the signal name, signal type, and signal location. In a specific embodiment, signal-type communication interfaces are primarily organized using message format encapsulation, with messages associated with the corresponding in-vehicle controller's transceiver relationship. Each message includes at least key information, namely, the signal name, signal type, and signal location. Furthermore, the interface hash value is derived by extracting this specific information and performing a hash calculation.

[0081] It should be noted that when extracting specific information, at least key information must be included. In addition to key information, other information may also be included, such as the controller name. This specific information can be adjusted based on actual business needs and is not limited in this application. Furthermore, it should be noted that hash calculation algorithms such as SHA256 and CRC32 can be used.

[0082] Table 1 is a statistical schematic table of interface version information of a signal interface provided in an embodiment of the present application. In an optional embodiment, after associating the message relationship with the sending and receiving relationship, an interface version information table as shown in Table 1 can be obtained, where n is the number of received messages, m is the number of sent messages, and h is the interface hash value.

[0083] Table 1 Interface version information statistics of signal interfaces

[0084]

[0085]

[0086] For service-type communication interfaces, each controller can support one or more service types. Each service type contains one or more service interfaces, and each service interface is composed of different types of service signal types and service signal names. Therefore, in an optional embodiment, the specific information of the service-class interface includes at least the service signal type and service signal name. That is, the interface hash value is calculated based on at least the service signal type and service signal name. Similarly, the hash algorithm can include but is not limited to the SHA256 algorithm and the CRC32 algorithm.

[0087] Table 2 is a statistical diagram of interface version information of a service class interface provided in an embodiment of the present application. In Table 2, x is the number of services, y is the number of interfaces, and H is the interface hash value.

[0088] Table 2 Statistics of interface version information of service class interfaces

[0089] Controller Name Number of services Number of interfaces Interface Hash value ECU11 x1 y1 H1 ECU12 x2 y2 H2 ECU13 x3 y3 H3 ECU14 x4 y4 H4 ECU15 x5 y5 H5

[0090] Figure 3 A flow chart of a method for determining an interface hash value provided in an embodiment of the present application. In an optional embodiment, the communication interface definition document of the vehicle controller can be obtained, and the interface hash values of all interfaces can be calculated. Specifically, Figure 3 As shown, determine the interface hash value, including:

[0091] S30: Obtaining a communication interface definition document of a vehicle controller; the vehicle controller includes a master controller and a slave controller;

[0092] S31: Determine whether the current interface to be calculated is a service class interface; if so, proceed to step S32; if not, proceed to step S33;

[0093] S32: Extracting specific information of the service class interface and performing hash settlement; and distributing the calculated interface hash value to the corresponding controller; wherein the specific information of the service class interface includes at least the service signal type and the service signal name;

[0094] S33: extracting specific information of the signal interface for hash settlement; and distributing the calculated interface hash value to the corresponding controller; wherein the specific information of the signal interface includes at least the signal name, signal type and signal location.

[0095] In a specific embodiment, whenever communication interface data is released, the communication interface version information of all controllers in the vehicle is calculated, the interface hash value is calculated, and a strict set of version pairing information is maintained in the background. That is, the baseline version number of the controller is associated with the corresponding interface hash value. Furthermore, during production line electrical inspection upgrades or OTA upgrades, the NVM inside each controller will store the corresponding baseline version number and interface hash value association for subsequent interface compatibility verification.

[0096] Figure 4 A flow chart of a vehicle communication interface management method provided in another embodiment of the present application is provided as an embodiment. Figure 4 As shown, based on the interface information message, the interface compatibility of the controller to be verified is verified, including:

[0097] S40: Obtain the controller unique identifier and interface hash value of the main controller;

[0098] S41: Concatenate the controller unique identifier and interface hash value of the main controller with the controller unique identifier and interface hash value of the controller to be verified to obtain a concatenation result;

[0099] In a specific embodiment, when the main controller receives an interface information message from a controller to be verified, it extracts the controller unique identifier and interface hash value of the controller to be verified from the interface information. It also extracts its own controller unique identifier and interface hash value. Furthermore, the extracted information is sent to an internal software version settlement module for compatibility verification.

[0100] Specifically, the extracted information is first concatenated in step S41. In an optional embodiment, a lexicographical concatenation method can be used. For example, the concatenation result is "A1, hash1, A2, hash2...An, hashn", where A1 through An are unique controller identifiers and hash1 through hashn are interface hash values. It should be noted that this application does not limit the concatenation method and can be adjusted based on actual business needs.

[0101] S42: Calculate the signature of the concatenated result to obtain the signature value to be verified;

[0102] Furthermore, a digital signature is calculated on the splicing result using the public key stored in the main controller, ultimately obtaining a string of digital signature values sign, that is, obtaining the signature value sign to be verified. It should be noted that the signature algorithm can be implemented using asymmetric public key calculation or other signature or encryption algorithms, such as SM1, SM4, SM7, etc., and this application does not limit this.

[0103] S43: Determine whether the signature value to be verified belongs to a preset mapping list; wherein the preset mapping list is a mapping relationship between the master baseline version number and the reference signature value; if so, proceed to step S44; otherwise, proceed to step S45;

[0104] S44: Determine whether the communication interface between the controller to be verified and the main controller is compatible.

[0105] S44: Determine that the communication interface between the controller to be verified and the main controller is incompatible.

[0106] Table 3 is a preset mapping list provided in an embodiment of the present application. In the software version settlement module of the main controller, a communication interface version information compatibility mapping table is maintained, that is, a preset mapping list. As shown in Table 3, the list stores the mapping relationship between the main control baseline version number and the benchmark signature value.

[0107] Table 3 Preset mapping list

[0108] Master baseline version number Base signature value of the service class interface Base signature value of the signal interface ver1.1 sign01, sign02…sign0n sign11, sign12…sign1n

[0109] In an optional embodiment, the preset mapping list can be shown in Table 3, which distinguishes the baseline signature values corresponding to service-class interfaces and signal-class interfaces. It is understandable that the same controller communication interface may or may not be compatible under different baseline version numbers. Therefore, when verifying interface compatibility, signature values are calculated for different interfaces under different baseline version numbers.

[0110] In a specific embodiment, after the signature value to be verified is calculated, it is determined whether it exists in the preset mapping list. If so, it is determined that the interface to be verified is compatible with the interface of the main controller; otherwise, it is determined to be incompatible.

[0111] In a specific embodiment, for some practical applications, the primary requirement for verifying the compatibility of vehicle controller communication interfaces is to quickly determine whether any controllers on the vehicle are incompatible. Of course, in some practical applications, it is necessary not only to determine whether an incompatibility has occurred, but also to identify the specific controller that is incompatible, that is, to locate the incompatible controller.

[0112] Therefore, in order to meet different business needs, in some optional embodiments, the reference signature value is set to two categories, specifically including a first signature value and a second signature value. The first signature value is a value calculated by signature based on the controller unique identifier and interface hash value of the master controller and all slave controllers. Based on the above embodiment, when calculating the signature value, it is necessary to concatenate the controller unique identifier and interface hash value. Therefore, the first signature value refers to the value calculated by signature after concatenating the controller unique identifier and interface hash value of the master controller and all slave controllers.

[0113] It can be understood that when it is necessary to quickly determine whether interface incompatibility occurs on the entire vehicle, the controllers to be verified are all slave controllers, that is, all slave controllers report their own interface information messages to the master controller. At this time, the master controller concatenates its own controller unique identifier and interface hash value with the controller unique identifier and interface hash value of all slave controllers to obtain the signature value to be verified. When the signature value to be verified is the same as the first signature value, it indicates that there are no incompatible controllers, that is, no incompatibility event has occurred. If it is different from the first signature value, it indicates that an incompatibility event has occurred.

[0114] In an optional embodiment, in order to meet the business requirements of not only determining the occurrence of an incompatible event but also locating the incompatible controller, the baseline signature value includes a second signature value, which refers to a value calculated based on the unique controller identifiers and interface hash values of the master controller and the slave controllers. In a specific embodiment, in order to determine the controller in which the incompatible event occurs, the signature value between any slave controller and the master controller is calculated in advance, for example, the master controller is A and the slave controllers are B1 to Bn, then the signature value is calculated based on the unique controller identifiers and interface hash values of the master controller A and the controller B1, the master controller A and the controller B2... the master controller A and the controller Bn, respectively, and thus n second signature values can be obtained.

[0115] When locating incompatible controllers, after the main controller receives the interface information message returned by the controller to be verified, it is combined with the controller to be verified in pairs, that is, the controller unique identifier and interface hash value of the main controller are concatenated and signature calculated one by one with the controller unique identifier and interface hash value of the controller to be verified, and it is determined whether the calculation result belongs to the second signature value. If so, it indicates that the corresponding controller to be verified is compatible with the main controller interface. Otherwise, it is determined to be incompatible, thereby achieving accurate positioning of the incompatible controller.

[0116] As an optional embodiment, forwarding the verification signal to the slave controller step by step includes:

[0117] If the interface compatibility check is in the first mode supporting periodic broadcast, the check signal also includes other interface information of the master controller in addition to the master baseline version number. The check signal is forwarded to the slave controllers in a periodic broadcast form according to the communication protocol between the controllers.

[0118] If the interface compatibility check is in the second mode of prohibiting periodic broadcasting, the check signal only includes the master control baseline version number, and the check signal is forwarded to the slave controllers step by step in a unicast form.

[0119] In a specific embodiment, interface compatibility verification is mainly divided into two different modes, namely, the first mode that supports periodic broadcasting, for example, the first mode is used in the research and development stage. In the first mode, the verification signal sent down can include other interface information of the main controller in addition to the main controller baseline version number, thereby exposing the interface version information to the network, making it easier for R&D personnel to view controller information.

[0120] In the first mode, the verification signal includes more interface information. When the verification signal is sent, it needs to be broadcast periodically based on the communication protocol used between the controllers. It is understood that in the first mode, the verification signal is also sent in the form of a message. However, some communication protocols between controllers may support limited message lengths, so the message needs to be converted according to the communication protocol before being sent.

[0121] In the second mode, periodic broadcasts of verification signals are prohibited. For example, this is the case during mass production. In the second mode, periodic broadcasts of controller interface information are prohibited to prevent security risks. In this mode, the verification signal only carries the master baseline version number, allowing the slave controller to determine whether its own slave baseline version number is the same as the master baseline version number. Verification signals are sent in a unicast fashion, forwarded level by level.

[0122] Based on the above embodiment, when forwarding the verification signal according to the communication protocol, the communication protocol of the controller interface can be divided into a first protocol and a second protocol, and the message length supported by the first protocol is greater than the message length supported by the second protocol. The first protocol may include, but is not limited to, Ethernet, Flexray, and CANFD. The second protocol may include, but is not limited to, CAN and LIN protocols.

[0123] In a specific embodiment, when the vehicle controller sends verification signals step by step, if the first protocol is converted to the second protocol, it cannot carry more interface version information, so the sent information needs to be adjusted. Specifically, in an optional embodiment, when the communication protocol is the first protocol, the other interface information includes at least the controller unique identifier of the main controller and the interface hash value.

[0124] Table 4 is a table of the verification signal message format under a first protocol provided by an embodiment of the present application. As shown in Table 4, under the first protocol, the verification signal is transmitted as message M1, and message M1 includes at least the master control baseline version number, the controller unique identifier of the master controller, and the interface hash value, where the interface hash value includes the service interface hash value and the signal interface hash value. In addition, message M1 may also include the number of received messages and the number of sent messages for the signal interface, as well as the number of services and interfaces for the service interface.

[0125] Table 4 Verification signal message format under the first protocol

[0126]

[0127] In another optional embodiment, when the communication protocol of the control device supports a second protocol with a shorter message length, the message M1 shown in Table 4 needs to be converted into a shorter message M2. Table 5 shows a verification signal message format table under a second protocol provided in an embodiment of the present application. In a specific embodiment, under the second protocol, other interface information includes the unique controller identifier of the master controller. As shown in Table 5, message M2 includes the master control baseline version number and the unique controller identifier.

[0128] Table 5 Verification signal message format under the second protocol

[0129] Message length 1 Byte 2Byte Message content Controller unique identifier Master baseline version number

[0130] It is understandable that the message length supported under the second protocol is limited. Therefore, message M1 needs to be converted into message M2. In order to ensure that the slave controller can compare the master baseline version number with its own slave baseline version number to see if they are the same, message M2 needs to include at least the controller unique identifier and the master baseline version number.

[0131] In an optional embodiment, when the controller to be verified encapsulates its own interface version information into an interface information message and reports it to the master controller, it also needs to report it according to the communication protocol. Specifically, when the communication protocol is the first protocol, the interface information message is reported as message M1. That is, in addition to the controller's unique identifier and interface hash value, the interface information message also includes the number of received messages and the number of sent messages for signal interfaces, as well as the number of services and interfaces for service interfaces.

[0132] When the communication protocol is the second protocol, the interface information message is reported as message M3. Table 6 is a table of interface signal message formats under the second protocol provided in an embodiment of the present application. As shown in Table 6, the interface information message M3 sent by the controller to be verified includes the controller unique identifier, the baseline version number (i.e., the slave control baseline version number), and the interface hash value.

[0133] Table 6 Interface signal message format under the second protocol

[0134] Message length 1 Byte 2Byte 4Byte Message content Controller unique identifier Baseline version number Interface Hash value

[0135] It is worth noting that the message lengths corresponding to the interface hash values calculated by message M1 and message M3 are different. That is, the interface hash value message length under the first protocol is greater than the interface hash value message length under the second protocol. In a specific embodiment, the longer the interface hash value message length, the higher the accuracy of the hash algorithm used, in order to improve the accuracy of the compatibility check. In an optional embodiment, different contents and incompatible interfaces may have the same calculation results using hash algorithms of the same precision, which may cause errors in the compatibility check. Therefore, hash algorithms of different precisions are used as much as possible to ensure that the interface hash values corresponding to different interfaces are different, thereby improving the accuracy of the compatibility check.

[0136] In addition, it should be noted that, based on the baseline version number verification, the main controller needs to further verify the interface compatibility of the controller to be verified and upload the interface hash value. Therefore, the interface signal message includes at least the controller unique identifier and the interface hash value.

[0137] Therefore, when sending a verification signal, if the communication protocol between the controllers is the first protocol, it is sent as message M1. If the communication protocol is the second protocol, it is sent as message M2. When reporting an interface signal message, if the communication protocol between the controllers is the first protocol, it is reported as message M1. If the communication protocol is the second protocol, it is reported as message M3.

[0138] Figure 5 A schematic diagram of the principle of a vehicle communication interface management method provided in an embodiment of the present application is shown as follows: Figure 5 As shown, when the main controller receives the trigger signal of the interface compatibility check, the main controller will receive the message M1 or message M2, and the domain controller will synchronously forward it to the network segment where the sub-controller is located. If the forwarded target network segment does not support the complete message M1 format, the message M1 will be converted into message M2.

[0139] Upon receiving message M1 or message M2, the domain controller and sub-controller compare their own slave control baseline version number with the master control baseline version number in message M1 or message M2. They check whether the locally stored slave control baseline version number is inconsistent with the master control baseline version number in message M1 or message M2 sent by the master controller. If inconsistent, they encapsulate their own interface version information into interface information message M1 or interface information message M3 and report it step by step.

[0140] It should be noted that if Figure 5 As shown, when the trigger signal is sent by an external device, the identity of the external device needs to be verified first. Only after the identity verification is passed can the message M1 or message M2 be sent.

[0141] Figure 6This is a schematic diagram of another vehicle communication interface management method provided by an embodiment of the present application. It is worth noting that when the interface compatibility check is in the first mode supporting periodic broadcasting, the main controller is as follows Figure 5 When the interface compatibility check is in the second mode of prohibiting periodic broadcast, the message M1 or message M2 is sent step by step in the form of periodic broadcast shown in FIG. Figure 6 The unicast format shown sends verification signals R1 step by step, and verification signals R1 can only carry the master baseline version number. If the domain controller or sub-controller determines that its own slave baseline version number is different from the master baseline version number, it returns the interface information message M1 or interface information message M3 step by step to the master controller.

[0142] Based on the above embodiment, when the main controller determines that an incompatible event has occurred and determines an incompatible controller interface, that is, when the signature value to be verified does not exist in the preset mapping list, the local storage space of the main controller records the relevant version difference information, which is convenient for locating the version difference information through diagnosis and other means.

[0143] In addition, in an optional embodiment, if the main controller detects that the connection with the cloud service is normal, it can actively report the difference information to the cloud, and the cloud will determine whether an OTA upgrade is required or whether to ignore the difference. The main controller then informs the relevant domain controller or sub-controller of the compatibility anomaly based on the cloud's determination result.

[0144] Table 7 is a verification result message format table under a first protocol provided in an embodiment of the present application. When the main controller sends incompatible interface information, in an optional embodiment, as shown in Figure 7, if the controllers support the first protocol, the verification result message M4 includes the controller unique identifier, baseline version number, service interface hash value and signal interface hash value.

[0145] Table 7 Verification result message format under the first protocol

[0146]

[0147] Table 8 is a verification result message format table under a second protocol provided in an embodiment of the present application. In an optional embodiment, as shown in Figure 7, if the second protocol is supported between controllers, that is, the message length supported by the second protocol is smaller than the message length supported by the first protocol, the verification result message M5 includes the controller unique identifier, the baseline version number, and one of the service interface hash value and the signal interface hash value.

[0148] Table 8 Verification result message format under the second protocol

[0149]

[0150] Figure 7 A schematic diagram of the principle of another vehicle communication interface management method provided in the embodiment of the present application is shown as follows: Figure 7 As shown, in a specific embodiment, for network nodes supporting a first protocol such as Ethernet, Flexray, or CAN FD, when an incompatible interface exists, the master controller sends a notification message M4 to a specific slave controller. For network nodes supporting only a second protocol such as CAN or LIN, the master controller sends a notification message M5 to a specific slave controller. Furthermore, upon receiving the incompatibility notification, the domain controller or sub-controller records the relevant incompatibility identifier in local storage to facilitate problem location through diagnostics and other means.

[0151] Based on the above embodiments, in order to meet the actual business needs of only verifying compatibility, or both verifying compatibility and locating incompatible controllers, while improving verification efficiency, in an optional embodiment, the trigger signal for triggering the interface compatibility check is divided into a first signal and a second signal, wherein the first signal is used to detect an interface incompatibility event and locate the controller where the incompatibility event occurs, and the second signal is used only to confirm the occurrence of the incompatibility event.

[0152] When the trigger signal is the first signal, the business requirement at this time is to determine the incompatibility event and locate the incompatible controller. On this basis, in order to quickly locate the incompatible controller, the controller to be verified is a controller whose slave control baseline version number is different from the master control baseline version number. In a specific embodiment, when each slave controller receives the verification signal sent by the master controller, it internally verifies the baseline version number. When it finds that its own slave control baseline version number is different from the master control baseline version number, it encapsulates its own interface version information into an interface information message and reports it to the master controller. That is, only the controller whose slave control baseline version number is different from the master control baseline version number needs to report the interface information message.

[0153] Therefore, on the basis of verifying the baseline version number of the slave controller, only the interface compatibility between the controller to be verified and the master controller is verified, which greatly reduces the amount of calculation and thus improves the verification accuracy.

[0154] In another optional embodiment, when the trigger signal is the second signal, that is, the business requirement focuses on quickly determining an incompatibility event, the controllers to be verified are all slave controllers. Accordingly, after all slave controllers report interface information messages, the master controller concatenates its own controller unique identifier and interface hash value with the controller unique identifiers and interface hash values of all slave controllers, and performs a signature calculation to determine whether the calculation result matches the second signature value, thereby determining whether an incompatibility event has occurred.

[0155] In an optional embodiment, the trigger signal can be further divided into active trigger signals and passive trigger signals. Active trigger signals include but are not limited to normal vehicle power-on, vehicle sleep wake-up, software update, and driving mode switching (for example, seat mode switching). Passive trigger signals are signals triggered by external devices.

[0156] Figure 8 This is a schematic diagram of the principle of a vehicle communication interface management method provided by another embodiment of the present application. Figure 8 As shown in the passive trigger signal principle box, for the passive trigger signal, in order to ensure the safety of the vehicle system, the external device needs to be authenticated in advance. Specifically, the external device sends a diagnostic signal to the main controller for identity authentication.

[0157] In a specific embodiment, after authentication is successful, the master controller returns the identity authentication result to the external device. Only after identity authentication is successful can the external device send control instructions to the master controller. Furthermore, the master controller calls the version settlement software interface and actively broadcasts the trigger signal type of the current vehicle to each slave controller in the vehicle.

[0158] For example, Figure 8 As shown in the figure, after receiving a trigger signal from an external device, the main controller broadcasts the trigger signal type a preset number of times to the network segment where the subordinate domain controllers are located. Specifically, the broadcast occurs every preset interval, for example, once every 2 seconds. It is important to note that after sending the first trigger signal type, the main controller returns the corresponding response to the external device. For domain controllers, the trigger signal type is synchronously forwarded to the network segment where the subordinate sub-controllers are located.

[0159] like Figure 8 As shown in the active trigger signal principle box, for the active trigger signal, when the vehicle is normally powered on or awakened from sleep, the vehicle status self-check will be performed inside the main controller, that is, the automatic active trigger signal. Once the self-check is completed, the trigger signal type will be broadcast once to the network segment where the lower-level domain controller is located. After receiving the broadcast signal, the domain controller will forward it to the network segment where the lower-level sub-controller is located.

[0160] Understandably, with a passive trigger signal, not all vehicle controllers are necessarily powered on and in working order, and therefore may not receive the trigger signal. Therefore, a periodic broadcast is used to deliver the signal. With an active trigger signal, all vehicle controllers are powered on and capable of receiving signals. Therefore, to avoid wasting resources, a unicast signal is used.

[0161] In the above embodiment, the vehicle communication interface management method is described in detail. The present application also provides a corresponding embodiment of a vehicle communication interface management device.

[0162] Figure 9 This is a structural diagram of a vehicle communication interface management device provided in an embodiment of the present application, such as Figure 9 As shown, the device includes:

[0163] The signal forwarding module 90 is used to forward the verification signal to the slave controller step by step when receiving the trigger signal of the interface compatibility verification;

[0164] The message acquisition module 91 is used to obtain the interface information message of the controller to be verified from the controller;

[0165] The compatibility checking module 92 is used to check the interface compatibility of the controller to be checked according to the interface information message.

[0166] In addition, the vehicle communication interface management device provided in the embodiment of the present application also includes:

[0167] The main control information acquisition module is used to obtain the controller unique identifier and interface hash value of the main controller;

[0168] A splicing module is used to splice the controller unique identifier and interface hash value of the main controller with the controller unique identifier and interface hash value of the controller to be verified to obtain a splicing result;

[0169] The signature calculation module is used to calculate the signature of the splicing result to obtain the signature value to be verified;

[0170] A determination module is used to determine whether the signature value to be verified belongs to a preset mapping list; wherein the preset mapping list is a mapping relationship between the main control baseline version number and the reference signature value; if it does, it is determined that the communication interface of the controller to be verified is compatible with the main controller.

[0171] a first forwarding submodule, configured to forward the verification signal to the slave controllers in a periodic broadcast format, step by step, according to an inter-controller communication protocol, if the interface compatibility verification is in a first mode supporting periodic broadcasting and the verification signal further includes other interface information of the master controller in addition to the master baseline version number;

[0172] The second forwarding submodule is configured to forward the verification signal to the slave controllers in a unicast manner step by step if the interface compatibility verification is in the second mode prohibiting periodic broadcasting and the verification signal only includes the master baseline version number.

[0173] Figure 10 This is a structural diagram of a vehicle communication interface management device provided by another embodiment of the present application, such as Figure 10As shown, the vehicle communication interface management device includes: a memory 20 for storing computer programs;

[0174] The processor 21 is configured to implement the steps of the vehicle communication interface management method mentioned in the above embodiment when executing a computer program.

[0175] The vehicle communication interface management device provided in this embodiment may include but is not limited to a vehicle controller and a domain controller.

[0176] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0177] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory, and non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 20 is at least used to store the following computer program 201, wherein, after the computer program is loaded and executed by the processor 21, it can implement the relevant steps of the vehicle communication interface management method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include but is not limited to the relevant data involved in the vehicle communication interface management method, etc.

[0178] In some embodiments, the vehicle communication interface management device may further include a display screen 22 , an input / output interface 23 , a communication interface 24 , a power supply 25 , and a communication bus 26 .

[0179] Those skilled in the art will understand that Figure 10 The structure shown in the figure does not constitute a limitation to the vehicle communication interface management device, and may include more or fewer components than shown in the figure.

[0180] The vehicle communication interface management device provided in an embodiment of the present application includes a memory and a processor. When the processor executes the program stored in the memory, it can implement the vehicle communication interface management method in the above embodiment.

[0181] It should be noted that although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that these operations be performed in the particular order shown or performed sequentially, or that all illustrated operations be performed to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product, or packaged into multiple software products.

Claims

1. A vehicle communication interface management method, characterized in that: A main controller applied to a vehicle, wherein the main controller is a top-level controller in the vehicle, the method comprises: When receiving the trigger signal of the interface compatibility check, the check signal is forwarded to the slave controller step by step; Obtaining the interface information message of the controller to be verified from the slave controller; The interface compatibility of the controller to be verified is verified according to the interface information message.

2. The vehicle communication interface management method according to claim 1, characterized in that: The verification signal at least includes a master control baseline version number of the master controller; the verification controller includes a controller whose slave control baseline version number is different from the master control baseline version number.

3. The vehicle communication interface management method according to claim 2, characterized in that: The interface information message includes at least a controller unique identifier and an interface hash value.

4. The vehicle communication interface management method according to claim 3, wherein: The interface hash value is a value calculated by hashing specific information of the controller interface; When the controller interface is a signal interface, the specific information includes at least a signal name, a signal type, and a signal location; When the controller interface is a service-type interface, the specific information at least includes a service signal type and a service signal name.

5. The vehicle communication interface management method according to claim 3, characterized in that: Verifying the interface compatibility of the controller to be verified according to the interface information message includes: Obtain the controller unique identifier and interface hash value of the main controller; Concatenate the controller unique identifier and interface hash value of the main controller with the controller unique identifier and interface hash value of the controller to be verified to obtain a concatenation result; Performing signature calculation on the splicing result to obtain a signature value to be verified; Determine whether the signature value to be verified belongs to a preset mapping list; wherein the preset mapping list is a mapping relationship between the master control baseline version number and the reference signature value; If yes, determine whether the communication interface of the controller to be verified is compatible with that of the main controller.

6. The vehicle communication interface management method according to claim 5, characterized in that: The reference signature value includes a first signature value and a second signature value; The first signature value is a value calculated by signature based on the controller unique identifiers of the master controller and all the slave controllers and the interface hash value; The second signature value is a value calculated based on the controller unique identifiers and interface hash values of the master controller and the slave controller, respectively.

7. The vehicle communication interface management method according to claim 2, characterized in that: Forward the verification signal to the slave controller step by step, including: If the interface compatibility check is in the first mode supporting periodic broadcast, the verification signal further includes other interface information of the master controller in addition to the master control baseline version number, and the verification signal is forwarded to the slave controllers in a periodic broadcast form step by step according to the inter-controller communication protocol; If the interface compatibility check is in the second mode of prohibiting periodic broadcasting, the check signal only includes the master control baseline version number, and the check signal is forwarded to the slave controllers step by step in a unicast form.

8. The vehicle communication interface management method according to claim 7, characterized in that: The communication protocol includes a first protocol and a second protocol; the message length supported by the first protocol is greater than the message length supported by the second protocol; When the communication protocol is the first protocol, the other interface information includes at least a controller unique identifier and an interface hash value of the main controller; When the communication protocol is the second protocol, the other interface information includes a controller unique identifier of the main controller.

9. The vehicle communication interface management method according to claim 1, wherein: The trigger signal includes a first signal and a second signal; the first signal is used to detect an interface incompatibility event and locate the controller where the incompatibility event occurs; the second signal is only used to determine the occurrence of the incompatibility event; If the trigger signal is the first signal, the controller to be verified is a controller whose slave control baseline version number is different from the master control baseline version number; If the trigger signal is the second signal, the controllers to be verified are all the slave controllers.

10. A vehicle communication interface management device, characterized in that: A main controller applied to a vehicle, the main controller being a top-level controller in the vehicle, comprises: The signal forwarding module is used to forward the verification signal to the slave controller step by step when receiving the trigger signal of the interface compatibility verification; A message acquisition module, used to acquire the interface information message of the controller to be verified from the controller; A compatibility verification module is used to verify the interface compatibility of the controller to be verified according to the interface information message.

11. A vehicle communication interface management device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps of the vehicle communication interface management method according to any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the vehicle communication interface management method according to any one of claims 1 to 9 are implemented.

Images