Configuration method and device for CAN matrix to adapt to multiple vehicle types and vehicle

Abstract

The invention provides a configuration method and device for adapting a CAN matrix to multiple vehicle types and a vehicle. The method comprises the following steps: determining the type of a vehicle in response to vehicle power-on; calling an enabling interface of a target Ipdu group in a communication layer based on the vehicle type; the messages in the collection matrix are indexed to a corresponding Ipdu group in the communication layer according to the vehicle type, the CAN channel and the receiving and transmitting direction; the collection matrix is a matrix formed by integrating messages of a plurality of vehicle types; activating RteWrite and RteRead interfaces corresponding to the vehicle type in the runtime environment layer, and acquiring a CAN signal in the message from the communication layer by a functional interface of the application layer based on a preset mapping relation in the runtime environment layer; the mapping relationship is a mapping established by analyzing the interface information of each vehicle type in the ARXML file provided by the vehicle factory and the DBC file formed by the collection matrix. Therefore, the development and maintenance efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, in particular to a CAN matrix adaptation multi-vehicle configuration method and device and vehicle. BACKGROUND

[0002] In the development process of an automobile, when a vehicle manufacturer develops different vehicle models, due to differences in model positioning, function configuration, performance requirements, etc., the CAN bus communication matrices in different vehicle models often exhibit the characteristics of partial element overlap and partial element difference in the matrix. For example, different vehicle models may share some basic messages (such as power system state messages), but there are significant differences in the ID, data length, sending period, signal definition, etc. of some function messages (such as high-level driving assistance system exclusive messages).

[0003] Based on this, the CAN matrices of different vehicle models need to be configured independently, resulting in a long development cycle and high maintenance cost in the later stage. SUMMARY

[0004] Therefore, the present application provides a CAN matrix adaptation multi-vehicle configuration method and device, aiming to solve the problem that the CAN matrices of different vehicle models need to be configured independently, resulting in a long development cycle and high maintenance cost in the later stage.

[0005] In a first aspect, the present application provides a CAN matrix adaptation multi-vehicle configuration method, comprising:

[0006] In response to the power-on of a vehicle, the vehicle model is determined;

[0007] Based on the vehicle model, the enablement interface of a target Ipdu group in the communication layer is called; the target Ipdu group is one or more of the Ipdu groups included in the communication layer; the messages in the union matrix are indexed to the corresponding Ipdu group in the communication layer according to the vehicle model, CAN channel and transmission direction; the union matrix is a matrix formed by integrating the messages of multiple vehicle models;

[0008] The RteWrite and RteRead interfaces in the runtime environment layer corresponding to the vehicle model are activated, and the function interface of the application layer acquires the CAN signals in the messages from the communication layer based on the preset mapping relationship in the activated runtime environment layer; the mapping relationship is to analyze the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and the DBC file formed by the union matrix, and to establish the mapping between the function interface of the application layer of each vehicle model and the CAN signals of the communication layer.

[0009] Optionally, the construction step of the union matrix comprises:

[0010] Obtaining the original messages of multiple vehicle models;

[0011] Based on whether the original messages are shared across multiple vehicle models, messages from multiple vehicle models are integrated to form a message matrix;

[0012] Based on preset naming rules, each message in the message matrix is ​​named to form a collection matrix; the naming rules include the vehicle functions adapted to the message, the application module corresponding to the message, and the vehicle model to which the message is applicable.

[0013] Optionally, the step of integrating messages from multiple vehicle models to form a message matrix based on whether the original messages are shared across multiple vehicle models includes:

[0014] If the original message is a message shared by multiple vehicle models, then the message is a shared message, and only one copy of each shared message is retained in the message matrix;

[0015] If the original message is not a message shared by multiple vehicle models, then the message is saved directly to the message matrix as an independent message.

[0016] Optionally, the step of forming a DBC file from the set matrix includes:

[0017] In response to operations on the set matrix on the visual interface, a processed set matrix is ​​obtained; the operations include one or more of the following: adding or deleting messages in the set matrix, and adding or deleting vehicle models in message naming;

[0018] The processed set matrix is ​​subjected to conflict checking, which includes one or more of the following: uniqueness check of the CAN ID of the corresponding message for each vehicle model, non-overlapping bit field check of the CAN signal in each message, and consistency check of the original message corresponding to the shared message.

[0019] If the uniqueness check, the bit width non-overlap check, and the consistency check all pass, the processed set matrix is ​​converted into a DBC file.

[0020] Optionally, the conflict check on the processed set matrix includes:

[0021] The uniqueness of the CAN ID of the message included in each vehicle model in the set matrix is ​​checked. If the CAN ID of the message included in the vehicle model is not unique in the message included in the vehicle model, the first conflict warning is output.

[0022] Based on the start bit and bit width of the CAN signal in each message in the collection matrix, the bit fields of the CAN signal in the message are checked for overlap. If there is overlap of signal bit fields in the same message, a second collision warning is output.

[0023] Based on the multiple original messages corresponding to the shared message, it is determined whether the multiple original messages are the same; if they are different, a third conflict warning is issued, and the shared message is deleted from the set matrix. Each original message corresponding to the shared message is named and stored as an independent message in the set matrix.

[0024] Optionally, the method further includes:

[0025] Based on the CAN channels and transmit / receive directions included in each vehicle model, create Ipdu groups for the receive or transmit directions of each channel included in each vehicle model in the communication layer;

[0026] The messages in the collection matrix are indexed to one or more corresponding Ipdu groups according to vehicle type, CAN channel, and transmit / receive direction.

[0027] Optionally, the method further includes:

[0028] In response to at least one change received by the vehicle's diagnostic service update interface, the change is updated to the set matrix pre-stored in the ECU's erasable and rewritable memory.

[0029] Optionally, the mapping relationship is established by parsing the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and forming a DBC file with the collection matrix, and establishing a mapping between the application layer functional interfaces and the communication layer CAN signals of each vehicle model, including:

[0030] Obtain ARXML files for multiple car models provided by the car manufacturer;

[0031] Parse the interface information of each vehicle model in the ARXML file, establish and store the mapping relationship between the application layer functional interfaces of each vehicle model and the CAN signals parsed from the DBC file.

[0032] Secondly, this application provides a CAN matrix adapter for multiple vehicle models, comprising:

[0033] A determining unit is configured to determine the vehicle model in response to vehicle power-on.

[0034] The calling unit is used to call the enable interface of the target IPdu group in the communication layer based on the vehicle model; the target IPdu group is one or more IPdu groups included in the communication layer; the messages in the set matrix are indexed to the corresponding IPdu group in the communication layer according to the vehicle model, CAN channel and transmit / receive direction; the set matrix is ​​a matrix formed by integrating messages from multiple vehicle models;

[0035] The acquisition unit is used to activate the RteWrite and RteRead interfaces corresponding to the vehicle model in the runtime environment layer. The application layer function interface obtains the CAN signal in the message from the communication layer based on the preset mapping relationship in the activated runtime environment layer. The mapping relationship is to parse the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and the DBC file formed by the set matrix to establish the mapping between the application layer function interface and the CAN signal of the communication layer of each vehicle model.

[0036] Thirdly, this application provides a vehicle that adopts a CAN matrix configuration method for adapting to multiple vehicle models as described in any of the above claims.

[0037] This application provides a configuration method, device, and vehicle for CAN matrix adaptation to multiple vehicle models. When executing the method, in response to vehicle power-on, the vehicle model is determined; based on the vehicle model, the enable interface of the target IPdu group in the communication layer is invoked; the target IPdu group is one or more IPdu groups included in the communication layer; messages in the aggregation matrix are indexed to the corresponding IPdu group in the communication layer according to vehicle model, CAN channel, and transmit / receive direction; the aggregation matrix is ​​a matrix formed by integrating messages from multiple vehicle models; the RteWrite and RteRead interfaces corresponding to the vehicle model in the runtime environment layer are activated; the application layer function interface obtains the CAN signal from the message based on the preset mapping relationship in the activated runtime environment layer; the mapping relationship is established by parsing the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and the DBC file formed by the aggregation matrix, establishing a mapping between the application layer function interface and the CAN signal of the communication layer for each vehicle model. In this way, the application integrates messages from multiple vehicle models into a set matrix, and indexes each message in the set matrix according to vehicle model, CAN channel, and transmit / receive direction to the corresponding Ipdu group in the communication layer. That is, the communication layer is divided into multiple Ipdu groups based on vehicle model, CAN channel, and transmit / receive direction. Then, after the vehicle is powered on, the corresponding Ipdu group can be automatically matched according to the identified vehicle model and the request from the application layer's functional interface. This achieves dynamic configuration of the communication layer, eliminating the need to develop a separate CAN matrix for each vehicle model. Furthermore, the mapping relationship at the runtime environment layer is established by parsing the DBC file formed by the set matrix and the ARXML file provided by the vehicle manufacturer, thus establishing a mapping between the application layer's functional interfaces and the communication layer's CAN signals. This breaks through the fixed mapping pattern, realizing a dynamic and flexible mapping relationship between the application layer and the communication layer for each vehicle model, adapting to the configuration needs of multiple vehicle models, reducing system development and maintenance costs, and improving configuration efficiency and scalability. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 A flowchart illustrating a configuration method for adapting a CAN matrix to multiple vehicle models, provided in an embodiment of this application;

[0040] Figure 2 This is a schematic diagram of a CAN matrix adapter for multiple vehicle models provided in an embodiment of this application. Detailed Implementation

[0041] During the automotive R&D process, when automakers develop different models, differences in model positioning, functional configurations, and performance requirements often result in overlapping and differing elements in the CAN bus communication matrices used in different vehicles. For example, different models may share some basic messages (such as powertrain status messages), but some functional messages (such as messages specific to advanced driver assistance systems) differ significantly in terms of ID, data length, transmission cycle, and signal definition. This leads to numerous problems during R&D and maintenance. On the one hand, the development of CAN matrices for different models requires multiple teams to work in parallel, necessitating repeated design, coding, and testing for messages with similar functions. This not only wastes manpower and time but may also lead to version inconsistencies due to poor teamwork. On the other hand, in the later maintenance phase, matrix iterations for each type of vehicle must be conducted independently. As the model range expands, the cost of repeated maintenance increases linearly, significantly hindering the improvement of R&D efficiency.

[0042] Therefore, this application provides a configuration method, device, and vehicle for CAN matrix adaptation to multiple vehicle models. Firstly, the application integrates messages from multiple vehicles into a set matrix (messages shared by multiple models are only retained once in the set matrix), and configures a structured name for each message in the set matrix, including an identifier of the vehicle model to which the message is adapted. This enables unified collection and rapid identification of messages from multiple vehicle models. Furthermore, by visually adjusting the set matrix, the configuration threshold is lowered, human error is reduced, and the management chaos of multiple version matrices is resolved. Secondly, at the communication layer, each vehicle model's CAN channel is divided into two Ipdu groups for receiving and transmitting. Messages in the set matrix are indexed to their corresponding Ipdu groups. When communication needs to be established with the target vehicle model and its application layer functional interfaces, the corresponding Ipdu group for the corresponding CAN channel of the target vehicle model is activated. This implements a "grouping-index association-dynamic activation" mechanism, enabling precise control of message transmission and reception for multiple vehicle models using the same communication module, avoiding conflicts between messages from different vehicle models. Furthermore, upon vehicle power-on, the system identifies the vehicle model and automatically enables the corresponding IPDU group for that model, establishing a communication channel. This ensures that the application layer functional interfaces only parse message content adapted to the specific vehicle model, enabling automatic switching of communication configurations across multiple models without manual intervention or hardware modifications. Thirdly, it breaks away from the fixed mapping model, combining the multi-model arxml files provided by the OEM with a dynamic mapping design at the RTE layer. This achieves cross-model adaptation between the application and communication layers, ensuring compatibility of the same application code across different models, replacing manual mapping, reducing configuration errors, lowering system development and maintenance costs, and improving configuration efficiency and scalability. Fourthly, the updates and iterations of the integrated configuration matrix for multiple models can be directly refreshed to the vehicle's ECU, eliminating the need for separate configurations for each model's matrix. This significantly shortens the model iteration cycle, reduces the engineering risks of matrix updates, and meets the OTA upgrade requirements of OEMs.

[0043] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0044] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0045] Unless otherwise stated, the term "multiple" means two or more. In embodiments of this disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B. The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B.

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0047] See Figure 1 , Figure 1 This application provides a flowchart illustrating a configuration method for adapting a CAN matrix to multiple vehicle models. The method includes:

[0048] S101. In response to the vehicle being powered on, determine the vehicle model.

[0049] In one example, during the power-on initialization phase, the system accurately identifies the vehicle's model (such as model A, B, or C) by reading the vehicle's DID (Data Identifier) ​​information (such as the vehicle model code, the model identifier stored in the ECU, etc.).

[0050] To achieve automatic adaptation of the same set of matrix engineering on different vehicle models, the system needs to complete vehicle model recognition when the vehicle is powered on, and dynamically activate the corresponding communication configuration for subsequent steps based on the recognition results.

[0051] S102. Based on the vehicle model, call the enable interface of the target IPdu group in the communication layer; the target IPdu group is one or more of the IPdu groups included in the communication layer; the messages in the set matrix are indexed to the corresponding IPdu group in the communication layer according to the vehicle model, CAN channel and transmit / receive direction; the set matrix is ​​a matrix formed by integrating messages from multiple vehicle models.

[0052] In one embodiment, the application layer, based on the identification result (the vehicle model of the current vehicle), calls the Ipdu group enable interface (such as enabling IpduGroup_CAN1_TX_A and IpduGroup_CAN1_RX_A) of the corresponding vehicle model in the CP-Com module of the communication layer to realize message enable control for different vehicle models.

[0053] The CP-Com module described above is the core module for implementing CAN message transmission and reception control. By configuring multiple Ipdu (Interaction Layer Protocol Data Unit) groups, message enable control for different vehicle models can be achieved. The configuration methods for these Ipdu groups can include:

[0054] The first step is to create a corresponding Ipdu group in the CP-Com module according to the CAN channel (such as CAN1, CAN2, etc.) and the transmit / receive direction (TX, RX) of different vehicle models. The naming format is: IpduGroup_[CAN channel]_[transmit / receive direction]_[vehicle model identifier].

[0055] For example, the following IPdu groups can be created for the CAN1 channel of vehicle models A, B, and C:

[0056] IpduGroup_CAN1_TX_A (CAN1 channel transmission group for vehicle model A);

[0057] IpduGroup_CAN1_RX_A (CAN1 channel receiver group for vehicle model A);

[0058] IpduGroup_CAN1_TX_B (CAN1 channel transmission group for vehicle model B);

[0059] IpduGroup_CAN1_RX_B (CAN1 channel receiver group for vehicle model B).

[0060] IpduGroup_CAN1_TX_C (C Model CAN1 Channel Transmitting Group);

[0061] And IpduGroup_CAN1_RX_C (C model CAN1 channel receiver group).

[0062] The second step involves indexing each Ipdu in the set matrix (each message corresponds to a CAN ID, and each CAN ID corresponds to a CAN signal as an Ipdu) into the corresponding Ipdu group based on its applicable vehicle model. If an Ipdu is applicable to multiple vehicle models (e.g., applicable to both models A and B), it can be indexed into multiple Ipdu groups simultaneously (e.g., IpduGroup_CAN1_TX_A and IpduGroup_CAN1_TX_B), enabling the reuse of a single Ipdu across multiple vehicle models.

[0063] In this way, the messages required for actual communication for each vehicle model are mapped to the corresponding Ipdu groups according to their CAN channel, transmission / reception direction, and vehicle model affiliation, ensuring that only messages related to the Ipdu group corresponding to the current vehicle model are activated. After completing vehicle model identification, the system only enables the corresponding Ipdu group and blocks irrelevant messages from other vehicle models, thereby achieving optimal allocation of communication resources and cross-vehicle compatibility.

[0064] Furthermore, based on the vehicle model and the function request of the application layer's function interface, the enable interface of the target IPDU group in the communication layer can be invoked; the target IPDU group is the IPDU group determined in the communication layer by combining the vehicle model and the CAN channel corresponding to the function request.

[0065] S103. Activate the RteWrite and RteRead interfaces in the runtime environment Rte layer corresponding to the vehicle model. The application layer functional interface obtains the CAN signal in the message from the communication layer based on the preset mapping relationship in the activated runtime environment layer. The mapping relationship is the beneficial effect of the CP-Rte module parsing the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and the DBC file formed by the set matrix, establishing the mapping between the application layer functional interface of each vehicle model and the CAN signal of the communication layer.

[0066] The above activation of the RteWrite and RteRead interfaces is to enable read and write operations on the data in the target Ipdu group of the communication layer.

[0067] Based on steps S102 and S103 above, the application layer can call the corresponding Ipdu group enable interface in the CP-Com module (such as enabling IpduGroup_CAN1_TX_A and IpduGroup_CAN1_RX_A) according to the identified vehicle model, and at the same time activate the RteWrite (signal transmission) and RteRead (signal reception) interfaces corresponding to the vehicle model in the Rte layer. Through the above control, the system will only send and receive the CAN messages required by the current vehicle model, and the messages of other vehicle models will be in a dormant state because they are not enabled, thereby realizing the precise adaptation of one matrix and one project to the CAN communication needs of multiple vehicle models.

[0068] Based on the steps S101-S103 above, this application integrates messages from multiple vehicle models into a collection matrix. Each message in the collection matrix is ​​indexed to its corresponding Ipdu group in the communication layer according to vehicle model, CAN channel, and transmission / reception direction. That is, the communication layer is divided into multiple Ipdu groups based on vehicle model, CAN channel, and transmission / reception direction. After the vehicle is powered on, the corresponding Ipdu group can be automatically matched based on the identified vehicle model and the application layer's functional interface request. This achieves dynamic configuration of the communication layer, eliminating the need to develop a separate CAN matrix for each vehicle model, thus saving development costs. Furthermore, the runtime environment layer mapping relationship is established by parsing the DBC file formed by the collection matrix and the ARXML file provided by the vehicle manufacturer, creating a mapping between the application layer's functional interfaces and the communication layer's CAN signals. This breaks through the fixed mapping pattern, realizing a dynamic and flexible mapping relationship between the application layer and communication layer for each vehicle model, adapting to multi-vehicle configuration requirements, reducing system development and maintenance costs, and improving configuration efficiency and scalability.

[0069] In the embodiments of this application, the above Figure 1 The specific configuration method of the set matrix mentioned in step S102 can be described as follows. It should be noted that the implementation methods given below are only illustrative examples and do not represent all implementation methods of the embodiments of this application.

[0070] In one possible implementation, the steps for constructing the set matrix include:

[0071] Step A1: Obtain the original messages from multiple vehicle models;

[0072] Step A2: Based on whether the original messages are shared across multiple vehicle models, integrate the messages from multiple vehicle models to form a message matrix.

[0073] In one example, if the original message is a message shared by multiple vehicle models, then the message is a shared message, and only one copy of each shared message is kept in the message matrix; if the original message is not a message shared by multiple vehicle models, then the message is directly saved to the message matrix as an independent message.

[0074] Step A3: Based on the preset naming rules, name each message in the message matrix to form a collection matrix; the naming rules include the vehicle function adapted to the configuration message, the application module corresponding to the message, and the vehicle model to which the message is applicable.

[0075] In one example, to clearly identify the vehicle model to which each message belongs in the collection matrix, a structured naming rule is set for the messages, including: messages in the collection matrix adopt a composite naming format of "basic message name - application abbreviation - vehicle model identifier", where "basic message name" reflects the core function (such as power, body control); "application abbreviation" identifies the associated application module (such as ENG = engine, BCM = body controller); each vehicle model identifier is combined with a square bracket.

[0076] For example, the speed control message used only by the engine module of model A is: ENG_SPEED-ENG[A]; the lighting control message shared by the body controllers of models A and B is: LIGHT_CTRL-BCM[A][B]; and the battery voltage message common to models A, B, and C is: BATTERY_VOLT-POWER[A][B][C].

[0077] This naming convention allows for a clear distinction of the vehicle models to which a message is applicable, providing a definitive basis for subsequent configuration and invocation.

[0078] Based on the steps A1-A2 above, the collection matrix is ​​the foundation for achieving multi-vehicle compatibility. It integrates CAN messages from different vehicle models into a unified matrix, while using structured naming design to distinguish between vehicle-specific and shared messages.

[0079] Furthermore, addressing the pain points of complex configuration and version confusion in the collection matrix, a visual configuration tool was developed, integrating functions such as collection matrix editing, conflict detection, and version comparison to simplify the maintenance process of multi-model matrices. Specifically, the aforementioned collection matrix needs to be generated as a DBC file, and the configuration tool's functions can include:

[0080] Visual editing: In response to operations on the set matrix on the visual interface, the processed set matrix is ​​obtained; the operations include one or more of the following: adding or deleting messages in the set matrix, and adding or deleting vehicle models in message naming.

[0081] In one example, vehicle models and messages can be added / deleted via drag and drop, making the operation simple and convenient for users.

[0082] Conflict detection: Conflict verification is performed on the processed set matrix. The conflict verification includes one or more of the following: uniqueness verification of the CAN ID of the corresponding message for each vehicle model, non-overlapping bit fields of the CAN signals in each message, and consistency verification of the original message corresponding to the shared message.

[0083] In one possible implementation, the CAN ID of each vehicle type included in the set matrix is ​​uniquely verified. If the CAN ID of the vehicle type included in the message is not unique in the vehicle type included in the message, a first conflict warning is output.

[0084] For example, all CAN IDs included in model A in the set matrix are unique, and the CAN IDs of any two messages are not repeated.

[0085] In one example, based on the first conflict warning, the user manually adjusts the non-unique CAN ID corresponding to the vehicle model until the conflict is eliminated, and then re-executes the uniqueness check until the uniqueness check is completed.

[0086] In one possible implementation, based on the start bit and bit width of the CAN signal in each message in the set matrix, an overlap check is performed on the bit fields of the CAN signal in the message. If there is overlap of signal bit fields in the same message, a second collision warning is output.

[0087] In one example, based on the second collision warning, the user manually corrects the start bit or bit width of CAN signals with overlapping bit fields to ensure that the signals in the same message do not overlap in the bit fields, and re-executes the bit field overlap check until the check passes.

[0088] In one possible implementation, based on multiple original messages corresponding to a shared message, it is determined whether the multiple original messages are the same; if they are different, a third conflict warning is issued.

[0089] Optionally, based on the third conflict warning, the shared message is split. Specifically, the shared message is deleted from the set matrix, and each original message corresponding to the shared message is named and stored as an independent message in the set matrix.

[0090] The above naming refers to naming according to the naming rules.

[0091] One-click export of DBC file: If the uniqueness check, the bit width non-overlap check, and the consistency check all pass, the processed set matrix can be converted into a DBC file in response to the DBC file generation instruction.

[0092] Built-in version management: Records the vehicle range and message changes for each modification to the collection matrix (such as adding CHARGE_CTRL-POWER[D]), and supports version rollback of DBC files.

[0093] The set matrix is ​​edited using a visual configuration tool to generate a DBC file, ensuring that the vehicle model identification, attributes, and signal information of each message are accurately preserved in the file. Subsequently, the DBC file is imported into the CP tool (including the CP-com module for establishing Ipdu groups and the CP-Rte module for establishing mapping relationships) to provide data support for subsequent communication module configuration.

[0094] Based on step S103 above, the mapping relationship is established by parsing the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and forming a DBC file with the set matrix, thus establishing a mapping between the application layer functional interfaces and the communication layer CAN signals of each vehicle model. Therefore, the specific configuration of the mapping relationship may include:

[0095] First, obtain ARXML files for multiple car models provided by the car manufacturer.

[0096] The aforementioned automakers provide a collection of arxml files (AUTOSAR standard XML format files) containing information on all models. This file records the application functions, signal requirements, and interface definitions for each model.

[0097] Then, the Runtime Environment (Rte) layer parses the interface information of each vehicle model in the ARXML file, establishes and stores the mapping relationship between the application layer functional interfaces of each vehicle model and the CAN signals parsed from the DBC file.

[0098] The aforementioned Runtime Environment (Rte) layer serves as the intermediate interface between the application layer and the communication layer. It needs to establish the association between the application layer of different vehicle models and the CP-Com module messages through mapping configuration to ensure correct signal interaction.

[0099] After importing the arxml file, the Rte module establishes a mapping relationship between the application layer functional interfaces (such as sensor data acquisition interfaces, actuator control interfaces, etc.), middleware modules, and corresponding CAN signals in the COM module (communication layer) according to the vehicle model classification in the file. This ensures that the application requirements of different vehicle models can accurately correspond to the signals in the CAN message. This process can be automated by developing intelligent mapping tools to parse the DBC formed by the aggregation matrix and the arxml files of multiple vehicle models, build a CAN signal mapping table for each vehicle model, match CAN signals with application interfaces, and generate Rte configurations, all without manual intervention. After the vehicle model is determined at startup, the runtime environment layer automatically loads the mapping table for the corresponding vehicle model, achieving precise docking of communication data and functional logic, and ensuring collaborative optimization of function reuse and signal consistency between different vehicle models.

[0100] Based on the above embodiments, this application can also update the changes to the collection matrix to the collection matrix stored in the vehicle through the vehicle's diagnostic service update interface.

[0101] In one possible implementation, in response to at least one change received by the vehicle's diagnostic service update interface, the change is updated to a set matrix pre-stored in the ECU's erasable and rewritable memory (such as EEPROM).

[0102] Traditional CAN matrix iteration requires rewriting the ECU firmware, which is inefficient and risky. However, this application supports directly updating the vehicle configuration and message attributes (such as message cycle) changes in the collection matrix through a diagnostic tool, without modifying the application layer code.

[0103] In one example, when the change item is a vehicle model change for message adaptation, in response to the diagnostic tool issuing an update command, the association between vehicle model and message in the erasable and rewritable storage area is replaced (e.g., the vehicle model recorded in the naming of the message in the set matrix). After the system restarts, dynamic adaptation of the message under different vehicle model configurations is achieved.

[0104] In one example, when the change involves adjusting the start bit or bit width of the CAN signal, the bit field definition of the CAN signal in the corresponding message is updated. Furthermore, conflict checks can be performed on the bit fields of the CAN signal in the message to ensure that there is no overlap in the modified bit fields.

[0105] In one example, for newly added or deleted messages, their indices in each Ipdu group are correspondingly added or removed to maintain the accuracy of communication layer data mapping. Specifically, when a new message is detected, a unique CAN ID corresponding to the vehicle model is automatically assigned and added to the collection matrix. Simultaneously, based on its vehicle model, CAN channel, and transmit / receive direction, it is indexed to the corresponding Ipdu group. For deleted messages, their mapping entries in all Ipdu groups are cleared, and related storage resources are released. All changes are synchronously updated to the communication layer configuration file to ensure consistency between diagnostic services and the vehicle communication protocol, supporting efficient collaboration and flexible expansion of vehicles across different production batches and functional configurations.

[0106] The above are some specific implementations of the methods provided in the embodiments of this application. Based on this, this application also provides corresponding apparatus. The apparatus provided in the embodiments of this application will be described below from the perspective of functional modularity.

[0107] See Figure 2 The diagram shows a structural schematic of a CAN matrix adapter for multiple vehicle models. The CAN matrix adapter for multiple vehicle models includes:

[0108] Determining unit 201 is used to determine the vehicle model in response to vehicle power-on;

[0109] Calling unit 202 is used to call the enable interface of the target IPdu group in the communication layer based on the vehicle model; the target IPdu group is one or more IPdu groups included in the communication layer; the messages in the set matrix are indexed to the corresponding IPdu group in the communication layer according to the vehicle model, CAN channel and transmit / receive direction; the set matrix is ​​a matrix formed by integrating messages from multiple vehicle models;

[0110] The acquisition unit 203 is used to activate the RteWrite and RteRead interfaces corresponding to the vehicle model in the runtime environment layer. The application layer function interface obtains the CAN signal in the message from the communication layer based on the preset mapping relationship in the activated runtime environment layer. The mapping relationship is to parse the interface information of each vehicle model in the ARXML file provided by the vehicle manufacturer and the DBC file formed by the set matrix to establish the mapping between the application layer function interface of each vehicle model and the CAN signal of the communication layer.

[0111] In one example, the device includes a collection matrix generation unit for acquiring original messages from multiple vehicle models; integrating the messages from multiple vehicle models to form a message matrix based on whether each original message is shared across multiple vehicle models; and naming each message in the message matrix based on a preset naming rule to form a collection matrix; the naming rule includes configuring the vehicle functions adapted to the message, the application module corresponding to the message, and the vehicle model to which the message is applicable.

[0112] In one example, the set matrix generation unit is specifically used to ensure that if the original message is a message shared by multiple vehicle models, then the message is a shared message, and only one copy of each shared message is retained in the message matrix; if the original message is not a message shared by multiple vehicle models, then the message is directly saved to the message matrix as an independent message.

[0113] In one example, the device includes a visualization configuration unit, which is used to obtain a processed set matrix in response to operations on the set matrix on the visualization interface; the operations include one or more of the following: adding or deleting messages in the set matrix, adding or deleting vehicle models in message naming; performing conflict checking on the processed set matrix, the conflict checking including one or more of the following: uniqueness check of the CAN ID of the message corresponding to each vehicle model, non-overlapping bit field check of the CAN signal in each message, and consistency check of the original message corresponding to the shared message; if the uniqueness check, the non-overlapping bit field check, and the consistency check all pass, the processed set matrix is ​​converted into a DBC file.

[0114] In one example, the visualization configuration unit is specifically used to perform uniqueness verification on the CANID of each vehicle model including the message in the set matrix. If the CAN ID of the message including the vehicle model is not unique in the message including the vehicle model, a first conflict warning is output. Based on the start bit and bit width of the CAN signal included in each message in the set matrix, the bit field of the CAN signal in the message is checked for overlap. If there is signal bit field overlap in the same message, a second conflict warning is output. Based on the multiple original messages corresponding to the shared message, it is determined whether the multiple original messages are the same. If they are different, a third conflict warning is issued, and the shared message is deleted from the set matrix. The original messages corresponding to the shared message are named and stored as independent messages in the set matrix.

[0115] In one example, the device further includes a CP-COM unit, which is used to create Ipdu groups for each vehicle model's CAN channels and transmit / receive directions in the communication layer; and to index the messages in the set matrix to one or more corresponding Ipdu groups according to vehicle model, CAN channel, and transmit / receive direction.

[0116] In one example, the device includes an update unit for updating the change to a set matrix pre-stored in the erasable memory of the ECU in response to at least one change received by the vehicle’s diagnostic service update interface.

[0117] In one example, the device further includes a CP-Rte unit, which is used to acquire ARXML files of multiple vehicle models provided by the vehicle manufacturer; parse the interface information of each vehicle model in the ARXML file; establish and store the mapping relationship between the application layer functional interface of each vehicle model and the CAN signal parsed from the DBC file.

[0118] This application also provides corresponding vehicles and computer storage media for implementing the solutions provided in this application.

[0119] One type of vehicle employs a CAN matrix configuration method for adapting to multiple vehicle models as described in any of the above embodiments.

[0120] The computer storage medium stores code. When the code is executed, the device running the code implements a CAN matrix configuration method for adapting to multiple vehicle models as described in any embodiment of this application.

[0121] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0122] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0123] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0124] The above description is merely an exemplary implementation of this application and is not intended to limit the scope of protection of this application.

Claims

1. A configuration method of CAN matrix adaptation multi-vehicle type, characterized in that, The method comprises the following steps: in response to the vehicle being powered on, determining the vehicle model of the vehicle; based on the vehicle model, calling the enabling interface of the target Ipdu group in the communication layer; the target Ipdu group is one or more of the Ipdu groups included in the communication layer; the messages in the collection matrix are indexed to the corresponding Ipdu group in the communication layer according to the vehicle model, CAN channel and transmission direction; the collection matrix is a matrix formed by integrating the messages of multiple vehicle models; activate the RteWrite and RteRead interfaces in the activation runtime environment layer corresponding to the vehicle model, and the functional interface of the application layer obtains the CAN signal in the message from the communication layer based on the preset mapping relationship in the activation runtime environment layer; the mapping relationship is to analyze the interface information of each vehicle model in the ARXML file provided by the vehicle factory and the DBC file formed by the collection matrix, and to establish the mapping between the functional interface of the application layer of each vehicle model and the CAN signal of the communication layer.

2. The method of claim 1, wherein, The construction steps of the collection matrix comprise: obtain the original messages of multiple vehicle models; integrate the messages of multiple vehicle models according to whether each original message is shared in multiple vehicle models, and form a message matrix; based on a preset naming rule, name each message in the message matrix to form a collection matrix; the naming rule includes configuring vehicle functions adapted to the message, application modules corresponding to the message, and vehicle models applicable to the message.

3. The method of claim 2, wherein, The integration of the messages of multiple vehicle models according to whether each original message is shared in multiple vehicle models to form a message matrix comprises: in the case that the original message is a message shared by multiple vehicle models, the message is a shared message, and only one copy of each shared message is retained in the message matrix; in the case that the original message is not a message shared by multiple vehicle models, the message is directly saved to the message matrix as an independent message.

4. The method of claim 3, wherein, The steps of forming the DBC file from the collection matrix comprise: in response to the operation on the collection matrix in the visual interface, obtain the processed collection matrix; the operation includes one or more of adding, deleting a message in the collection matrix, and adding, deleting a vehicle model in the message naming; perform conflict checking on the processed collection matrix, which includes one or more of uniqueness checking of CAN ID of each vehicle model corresponding message, non-overlapping checking of bit field of CAN signal in each message, and consistency checking of the original message corresponding to the shared message; in the case that the uniqueness checking, the non-overlapping checking of bit width, and the consistency checking are all passed, convert the processed collection matrix into a DBC file.

5. The method of claim 4, wherein, The conflict checking on the processed collection matrix comprises: perform uniqueness checking on the CAN ID of each vehicle model including message in the collection matrix, and output a first conflict warning if the CAN ID of the vehicle model including message is not unique in the vehicle model including message; perform overlapping checking on the bit field of CAN signal in the message according to the start bit and bit width of CAN signal included in each message in the collection matrix, and output a second conflict warning if there is signal bit field overlapping in the same message; Determine whether the plurality of original messages are the same based on the plurality of original messages corresponding to the common message; if not, issue a third conflict warning, and delete the common message from the collection matrix, and store each original message corresponding to the common message in the collection matrix as an independent message after naming.

6. The method of claim 1, wherein, The method further comprises: According to the CAN channels and the receiving or transmitting directions included in each vehicle model, create Ipdu groups of each channel receiving or transmitting direction included in each vehicle model in the communication layer; Index the messages in the collection matrix to one or more corresponding Ipdu groups according to the vehicle model, CAN channel, and receiving or transmitting direction.

7. The method of claim 1, wherein, The method further comprises: In response to at least one change item received by the diagnostic service update interface of the vehicle, update the change item to the collection matrix pre-stored in the erasable storage area of the ECU.

8. The method of claim 1, wherein, The mapping relationship is to parse the interface information of each vehicle model in the ARXML file provided by the vehicle factory and the DBC file formed by the collection matrix, establish the mapping between the functional interface of the application layer of each vehicle model and the CAN signal of the communication layer, including: Obtain the ARXML file of multiple vehicle models provided by the vehicle factory; Parse the interface information of each vehicle model in the ARXML file, and establish the mapping relationship between the functional interface of the application layer of each vehicle model and the CAN signal parsed in the DBC file and store it.

9. A configuration device of a CAN matrix adaptation multi-vehicle type, characterized by, Comprise: A determination unit for determining the vehicle model of the vehicle in response to the vehicle being powered on; A calling unit for calling the enabling interface of the target Ipdu group in the communication layer based on the vehicle model; The target Ipdu group is one or more of the Ipdu groups included in the communication layer; the messages in the collection matrix are indexed to the corresponding Ipdu groups in the communication layer according to the vehicle model, CAN channel, and receiving or transmitting direction; The collection matrix is a matrix formed by integrating the messages of multiple vehicle models; An acquisition unit for activating the RteWrite and RteRead interfaces in the runtime environment layer corresponding to the vehicle model, and the functional interface of the application layer acquires the CAN signal in the message from the communication layer based on the preset mapping relationship in the activated runtime environment layer; the mapping relationship is to parse the interface information of each vehicle model in the ARXML file provided by the vehicle factory and the DBC file formed by the collection matrix, and establish the mapping between the functional interface of the application layer of each vehicle model and the CAN signal of the communication layer.

10. A vehicle characterized by comprising: A CAN matrix adaptation multi-vehicle model configuration method according to any one of claims 1-8.

Images