A method for automatically generating CAN communication and routing configurations for multiple vehicle models under an Autosar architecture

Abstract

The present invention discloses a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. The method includes the following steps: parsing the CAN message description file for normal communication and the csv file with multiple configurations for the messages that need to be routed or for normal communication; generating the configurations for normal CAN communication; generating the configurations for routing and some messages; generating the message sending and receiving control configurations. Based on the modular architecture of the basic software (BSW) specified by Autosar, the present invention proposes a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. By calibrating or writing the configurations through UDS, a software can be reused on multi-vehicle and multi-platform, improving the software generality, being convenient and fast, beneficial to reducing errors, improving work efficiency, and simplifying the requirement analysis process.

Description

Technical Field

[0001] The present invention belongs to the technical field of automotive open system architecture, and particularly relates to a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. Background Art

[0002] Automotive requirements are becoming increasingly complex, and there is an urgent need for software to be reused on different vehicle models or platforms. Autosar defines a modular architecture for basic software (BSW). Based on this architecture, the present invention has invented a method for automatically generating CAN communication and routing configurations with multiple configurations, enabling a software to be reused on multiple vehicle models and platforms through calibration or UDS writing of configurations. Summary of the Invention

[0003] The object of the present invention is to provide a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture, which realizes automatic configuration for multiple requirements of the same controller on different vehicle model platforms.

[0004] The technical solution adopted by the present invention is as follows:

[0005] A method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture, comprising the following steps:

[0006] Parse the CAN message description file for normal communication and the csv file with multiple configurations for messages that need routing or normal communication;

[0007] Generate the configuration for normal CAN communication;

[0008] Generate the configuration for routing and some messages;

[0009] Generate the message sending and receiving control configuration.

[0010] Further, the csv file format is:

[0011] Name; SrcId; SrcNode; DesId; DesNode; Length; Behavior; Addressing; VehicleConfig;

[0012] Respectively represent the CAN message name, source node CAN ID, source node, destination node CAN ID, destination node, data field length, behavior, addressing type, vehicle model or platform configuration;

[0013] Among them, the behavior includes CAN and CAN-FD, and the addressing type includes standard and extended.

[0014] Furthermore, the CAN message routing configuration rules are as follows:

[0015] The CAN message name must be unique or the same as the message name in the CAN message description file. The source node CAN ID must be unique or the same as the message ID in the CAN message description file. The source node must be the same as one of those in the CAN message description file. The destination node CAN ID must be unique. The destination node must be the same as one of those in the CAN message description file and different from the source node. The data field length supports up to 64 bytes and at least 1 byte in CAN-FD mode, and up to 8 bytes and at least 1 byte in CAN mode. The behavior selection is CAN or CAN-FD and must match the data length. The addressing type selects standard or extended. The vehicle model or platform configuration is any string. The multi-vehicle model configuration is separated by a specific symbol, indicating that this rule applies to multiple vehicle models simultaneously;

[0016] For non-routing messages, but the configuration rules for prohibiting sending due to vehicle model differences are as follows:

[0017] Only the CAN message name and the vehicle model or platform configuration are required. The CAN message name must be the same as the message name in the CAN message description file.

[0018] Furthermore, the configuration for generating normal CAN communication includes:

[0019] The mailbox of the CAN module uses the FIFO (First In First Out) mode to receive messages;

[0020] Determine whether the currently processed CAN message is for reception or transmission;

[0021] If it is a received message, create an EcucPduCollection class for the received message, namely message name A + "_CanIf2PduR" and A + "_PduR2Com" respectively; allocate to the configuration container CanIfInitHohCfg's CanIfHrhCfg of the Can interface according to the CAN bus cluster CAN-CLUSTER and CAN ID in the CAN message description file; CanIfHrhCfg is the reception configuration of the Can interface;

[0022] Create a parameter container CanIfRxPduCfg class for receiving PDUs. The name is determined by message name A and the CAN-CLUSTER to which the message belongs, and it is configured, including CAN ID, data length, the upper-layer module RxIndicationUL, PduRef, and PduHrhIdRef to which the message needs to be routed when received; among them, PduRef references the Pdu object defined in EcucPduCollection, referring to the created A_CanIf2PduR; PduHrhIdRef references the CanIfHrhCfg defined in CanIfInitHohCfg, referring to the CanIfHrhCfg to which the received message belongs;

[0023] Create the routing mapping relationship PduRRoutingPath of the module, that is, the routing path of the Pdu, with the name being message name A + "_CanIf2Com"; among them, PduRSrcPduRef references the Pdu object defined in EcucPduCollection as the source Pdu, which is the created A_CanIf2PduR, and PduRDestPdu references the Pdu object defined in EcucPduCollection as the destination Pdu, which is the created A_PduR2Com;

[0024] Create the Pdu Interaction Layer PDU parameter ComIpdu of the Com module, which is determined by message name A and the CAN-CLUSTER to which the message belongs. Configure the direction of the Ipdu, ComIPduDirection, as "RECEIVE", that is, receive. ComPduIdRef references the Pdu object defined in EcucPduCollection, which is the created A_PduR2Com; ComIPduGroupRef references the Pdu group, and is configured as a group of the Ipdu, "ComIPduGroup_Rx", for the control of normal communication;

[0025] Create the communication layer signal ComSignal for all signals under this message, with the name being the signal name. Set its parsing method to support 4 data types, SINT, UINT, FLOAT, BOOLEAN, and the endian byte order, signal length, and the referenced SystemSignal, and add it under the created ComIpdu; finally, check whether there is a mapping relationship between this ComSignal and the interface of the SWC. If there is a mapping relationship, create the corresponding ComNotification interface, with the naming rule being "'Rte_COMCbk_" + the name of ComSignal; SystemSignal represents the way to exchange data between different defined ECUs;

[0026] If it is a sending message, create an EcucPduCollection class for the sending message, namely the message name A + "_PduR2CanIf" and A + "_Com2PduR"; allocate them to CanIfHthCfg of CanIfInitHohCfg according to CAN-CLUSTER and CAN ID in the CAN message description file.

[0027] Create a parameter container CanIfTxPduCfg class for the sending PDU, the name is determined according to the message name A and the CAN-CLUSTER to which the message belongs, and configure it, including CAN ID, data length, the upper layer module TxConfirmationUL that needs to be confirmed when the message is sent, PduRef, and PduHrhIdRef; PduRef refers to the created A_PduR2CanIf, and PduBufferRef refers to the configuration CanIfBufferCfg of the sending buffer associated with CanIfHthCfg to which the sending message belongs.

[0028] Create the routing mapping relationship PduRRoutingPath of the module, the name is the message name A + "_Com2CanIf", where PduRSrcPduRef is the created A_Com2PduR, and PduRDestPdu is the created A_PduR2CanIf.

[0029] Create ComIpdu, which is determined according to the message name A and the CAN-CLUSTER to which the message belongs, configure ComIPduDirection as "SEND", that is, send, configure the sending method according to the type of CAN message, and configure ComIPduGroupRef as "ComIPduGroup_Tx" for the control of normal communication.

[0030] Create ComSignal for all signals under this message, the name is the signal name, set its parsing method to support 4 data types SINT, UINT, FLOAT, BOOLEAN and the endian byte order, signal length, the referenced SystemSignal, and add it under the created ComIpdu.

[0031] Furthermore, the generation of routing and the configuration of some messages include:

[0032] Define PduRRoutingPathGroup according to the vehicle model configuration and make it disabled by default.

[0033] Judge whether the current message has undefined SrcNode and DesNode.

[0034] If, when there is no vehicle type configuration in the current message, no processing is performed; if there is a vehicle type configuration, add the Pdu with the message name A + "_PduR2CanIf" to the packet PduRRoutingPathGroup of the currently configured PduRRoutingPath;

[0035] If not, if the Pdu with the message name A + "_CanIf2PduR" is not defined, create the corresponding configuration; otherwise, if the Pdu with the message name A + "_PduR2CanIf" is not defined, create the corresponding configuration; otherwise, if the PduRRoutingPath with the message name A + "_CanIf2Com" is not defined, create the routing mapping relationship PduRRoutingPath of the module, with the name being the message name A + "_CanIf2CanIf", where PduRSrcPduRef is the aforementioned A_CanIf2PduR and PduRDestPdu is the aforementioned A_PduR2CanIf; otherwise, in the existing PduRRoutingPath of A + "_CanIf2Com", add PduRDestPdu as the aforementioned A_PduR2CanIf;

[0036] Add the aforementioned A_PduR2CanIf to the PduRRoutingPathGroup of the currently configured PduRRoutingPath.

[0037] Furthermore, generating the message sending and receiving control configuration includes:

[0038] Create the port BswMModeRequestPor for defining the mode request, set the BswM arbitration request method BswMRequestProcessing to "BSWM_IMMEDIATE", use the specified request source which can only be the notification BswMBswModeNotification from other Bsw modules, and generate the mode set ModeDeclarationGroups required for this request port according to the vehicle type configuration;

[0039] Generate the condition for mode execution BswMModeCondition, the expression for condition judgment BswMLogicalExpression, the action list for mode switching execution BswMActionList, and the modes included in the mode list BswMAction and BswMRule according to the described vehicle configuration; among them, BswMRule is the rule for mode execution, the action list executed when the condition is true or the action list executed when the condition is false, and each configuration has 2 conditions, LogicalExpressions, ActionLists, Actions, and Rules for enabling and disabling the corresponding PduRRoutingPathGroup.

[0040] The described Action should use the BswMPduRouterAction for enabling or disabling the Pdu routing function as the execution action of BswM, and add all PduRRoutingPathGroups that meet the vehicle configuration to its control object.

[0041] Enable the required PduRRoutingPathGroup according to the vehicle configuration in the calibration or UDS configuration during the startup phase for the generated BswM control interface, to achieve software reusability.

[0042] An Autosar architecture-based system for automatically generating multi-vehicle Can communication and routing configurations for implementing the method of automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of the above, includes:

[0043] A message parsing module, used to parse the CAN message description file for normal communication and the csv file with multiple configurations for messages that need to be routed or for normal communication.

[0044] A communication configuration module, used to generate the configuration for normal CAN communication.

[0045] A routing configuration module, used to generate the configuration for routing and some messages.

[0046] A control configuration module, used to generate the control configuration for message sending and receiving.

[0047] A vehicle that adopts the method of automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of the above.

[0048] An electronic device, includes:

[0049] A memory, used to store an executable computer program.

[0050] A processor, when executing an executable computer program stored in a memory, implements the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of the above.

[0051] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of the above.

[0052] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0053] Based on the modular architecture of basic software (BSW) specified by Autosar, the present invention proposes a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. By calibrating or writing configurations through UDS, a software can be reused on multi-vehicle and multi-platforms, improving software generality, being convenient and fast, beneficial to reducing errors, improving work efficiency, and simplifying the requirement analysis process. Description of the Drawings

[0054] Figure 1 It is a flowchart of the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. Detailed Embodiments

[0055] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0056] Based on the modular architecture of basic software (BSW) specified by Autosar, the present invention proposes a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. By parsing the configurations to be implemented with a python script and representing the requirements with a very simple csv file (comma-separated values); automatically configuring the Com stack (Can / CanIF / Com / PduR); automatically configuring the PduR control group (used to control the routing functions of different configurations); automatically configuring BswM and providing a control interface to SWC (Asw / Cdd / Dcm). Compared with the prior art, it improves software generality, is convenient and fast, beneficial to reducing errors, improves work efficiency, and simplifies the requirement analysis process.

[0057] Such as Figure 1As shown in the figure, the method for automatically generating multi-vehicle Can communication and routing configuration under the Autosar architecture of the present invention is as follows:

[0058] 1. Analyze the CAN message description file (.arxml) for normal communication and the csv file with multiple configurations for the messages that need to be routed or communicated normally.

[0059] 1.1. The format of the above csv file is as follows:

[0060] Name; SrcId; SrcNode; DesId; DesNode; Length; Behavior; Addressing; VehicleConfig;

[0061] They represent the CAN message name, source node CAN ID, source node, destination node CAN ID, destination node, data field length, behavior (CAN / CAN-FD), addressing type (standard / extended), vehicle model or platform configuration respectively.

[0062] 1.2. The CAN message routing configuration rules are as follows:

[0063] The CAN message name must be unique or the same as the message name in the CAN message description file. The source node CAN ID must be unique or the same as the message ID in the CAN message description file. The source node must be the same as one of those in the CAN message description file. The destination node CAN ID must be unique. The destination node must be the same as one of those in the CAN message description file and different from the source node. The data field length supports up to 64 bytes and at least 1 byte in the CAN-FD mode, and up to 8 bytes and at least 1 byte in the CAN model. The behavior can be selected as CAN or CAN-FD and must match the data length. The addressing type can be selected as standard or extended. The vehicle model or platform configuration can be any string. Multiple vehicle model configurations are separated by ":", for example, E1:E2:E3, indicating that this rule applies to vehicle models E1, E2, and E3 at the same time;

[0064] 1.3. For non-routing messages, but the configuration rules for prohibiting sending due to vehicle model differences are as follows:

[0065] Only two configurations of the CAN message name and the vehicle model or platform are required. The CAN message name must be the same as the message name in the CAN message description file.

[0066] 2. Generate the configuration for normal CAN communication.

[0067] 2.1. For software generalization, the mailbox of the CAN module receives messages in FIFO (First In First Out) mode;

[0068] 2.2. Determine whether the currently processed CAN message is for reception or transmission. If it is for reception, execute step 2.3; if it is for transmission, execute step 2.8;

[0069] 2.3. Create an EcucPduCollection (Collection of all Pdu objects flowing through the Com-Stack. A collection of all protocol data units Pdu used in the communication stack in the Autosar standard) class for the received message, namely message name A + "_CanIf2PduR" and A + "_PduR2Com" respectively; Allocate according to the CAN-CLUSTER (CAN bus cluster) and CAN ID in the CAN message description file to the CanIfHrhCfg (receive configuration of the Can interface) of the CanIfInitHohCfg (configuration container of the Can interface);

[0070] 2.4. Create a CanIfRxPduCfg (parameter container for received PDU) class, the name of which is determined according to message name A and the CAN-CLUSTER to which the message belongs. For example, if message A belongs to CAN0, the corresponding name is A_CAN0; Configure A_CAN0, including CAN ID, data length, RxIndicationUL (required to route to the upper-layer module when the message is received), PduRef (refer to the Pdu object defined in EcucPduCollection) refer to A_CanIf2PduR created in the above step 2.3, and PduHrhIdRef (refer to the CanIfHrhCfg defined in CanIfInitHohCfg) refer to the CanIfHrhCfg to which the message belongs in the above step 2.3;

[0071] 2.5. Create a routing mapping relationship PduRRoutingPath (routing path of Pdu) for the module, named message name A + "_CanIf2Com", where PduRSrcPduRef (refer to the Pdu object defined in EcucPduCollection as the source Pdu) is A_CanIf2PduR created in the above step 2.3, and PduRDestPdu (refer to the Pdu object defined in EcucPduCollection as the destination Pdu) is A_PduR2Com created in the above step 2.3;

[0072] 2.6. Create ComIpdu (Pdu Interaction Layer PDU parameters of the Com module). It is determined according to the message name A and the CAN-CLUSTER to which the message belongs. Configure ComIPduDirection (the direction of the Ipdu, receive or transmit) as "RECEIVE", ComPduIdRef (refer to the Pdu object defined in EcucPduCollection) as A_PduR2Com created in step 2.3 above, and ComIPduGroupRef (refer to the Pdu group) is configured as "ComIPduGroup_Rx" (a group of Ipdu) for the control of normal communication;

[0073] 2.7. Create ComSignal (communication layer signal) for all signals under this message, with the name being the signal name. Set its parsing method to support 4 data types: SINT, UINT, FLOAT, BOOLEAN, and the endian byte order, signal length, and reference SystemSignal (defines the way to exchange data between different ECUs, such as CAN signals), and add it under the ComIpdu created in step 2.6; Finally, check whether there is a mapping relationship between this ComSignal and the interface of the SWC. If there is a mapping relationship, create the corresponding ComNotification interface, and the naming rule is "'Rte_COMCbk_" + the name of the ComSignal.

[0074] 2.8. For the EcucPduCollection class of the message to be sent, they are A + "_PduR2CanIf" and A + "_Com2PduR" for the message name A respectively; Allocate them to CanIfHthCfg of CanIfInitHohCfg according to CAN-CLUSTER and CAN ID in the CAN message description file;

[0075] 2.9. Create the CanIfTxPduCfg (parameter container for transmitting PDU) class, and the name is determined according to the message name A and the CAN-CLUSTER to which the message belongs. For example, if message A belongs to CAN0, the corresponding name is A_CAN0; Configure A_CAN0, including CAN ID, data length, TxConfirmationUL (the upper layer module that needs to confirm the completion of message transmission), PduRef refers to A_PduR2CanIf created in step 2.8 above, and PduBufferRef refers to the CanIfBufferCfg (configuration of the transmit buffer) associated with CanIfHthCfg to which the message belongs in step 2.8;

[0076] 2.10. Create the routing mapping relationship of the module PduRRoutingPath, named as message name A + "_Com2CanIf", where PduRSrcPduRef is A_Com2PduR created in step 2.8 above, and PduRDestPdu is A_PduR2CanIf created in step 2.8 above;

[0077] 2.11. Create ComIpdu, determined according to message name A and the CAN - CLUSTER to which the message belongs. Configure ComIPduDirection as "SEND", configure the sending method according to the type (periodic / event) of the CAN message, and configure ComIPduGroupRef as "ComIPduGroup_Tx" for the control of normal communication;

[0078] 2.12. Create ComSignal for all signals under this message, named as the signal name, set its parsing method to support 4 data types SINT, UINT, FLOAT, BOOLEAN and the endian byte order, signal length, the referenced SystemSignal, and add it under the ComIpdu created in step 2.6.

[0079] 3. Generate the routing and configuration of some messages.

[0080] 3.1. Define PduRRoutingPathGroup according to the vehicle model configuration and make it disabled by default;

[0081] 3.2. If the SrcNode and DesNode of the current message are not defined, execute step 3.3, otherwise execute step 3.4;

[0082] 3.3. If there is no vehicle model configuration for the current message, do nothing; if there is a vehicle model configuration, add the Pdu with message name A + "_PduR2CanIf" to the currently configured PduRRoutingPathGroup (the grouping of PduRRoutingPath);

[0083] 3.4. If the Pdu with message name A + "_CanIf2PduR" is not defined in step 2.3, create the corresponding configuration according to step 2.3 and step 2.4, otherwise execute step 3.5;

[0084] 3.5. If the Pdu with message name A + "_PduR2CanIf" is not defined in step 2.8, create the corresponding configuration according to step 2.8 and step 2.9, otherwise execute step 3.6;

[0085] 3.6. If the PduRRoutingPath of message name A + "_CanIf2Com" is not defined in step 2.5, create a routing mapping relationship PduRRoutingPath for the module, named message name A + "_CanIf2CanIf", where PduRSrcPduRef is A_CanIf2PduR described in step 3.4 above, and PduRDestPdu is A_PduR2CanIf described in step 3.5 above. Otherwise, in the existing PduRRoutingPath of A + "_CanIf2Com", add PduRDestPdu as A_PduR2CanIf described in step 3.5 above;

[0086] 3.7. Add A_PduR2CanIf described in step 3.5 above to the currently configured PduRRoutingPathGroup.

[0087] 4. Generate message transmission and reception control configuration.

[0088] 4.1. Create a BswMModeRequestPort (the port for defining mode requests), set BswMRequestProcessing (the method of BswM arbitration requests) to "BSWM_IMMEDIATE", use the BswMBswModeNotification (specifying that the request source can only be notifications from other Bsw modules) method, and generate ModeDeclarationGroups (the set of modes required for this request port) according to the vehicle model configuration described in step 3.1 above;

[0089] 4.2. According to the vehicle model configuration described in step 3.1 above, generate BswMModeCondition (the conditions for mode execution), BswMLogicalExpression (the expression for condition judgment), BswMActionList (the list of actions to be executed for mode switching), BswMAction (the modes included in the mode list), and BswMRule (the rules for mode execution, the list of actions to be executed when the condition is true or the list of actions to be executed when the condition is false). Each configuration has 2 types of condition, LogicalExpression, ActionList, Action, and Rule for enabling and disabling the corresponding PduRRoutingPathGroup described in step 3.1 above;

[0090] 4.3. The Action described in step 4.2 above shall use BswMPduRouterAction (a type of BswMAction that can enable or disable the Pdu routing function) as the execution action of BswM, and add all PduRRoutingPathGroups that meet the vehicle configuration to its control object;

[0091] 4.4. The generated BswM control interface shall enable the required PduRRoutingPathGroups according to the vehicle configuration in the calibration or UDS configuration during the startup phase to achieve software reusability.

[0092] The present invention also provides a system for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture for implementing the method of automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of the above, including:

[0093] A message parsing module for parsing the CAN message description file for normal communication and the csv file with multiple configurations for messages that need to be routed or for normal communication;

[0094] A communication configuration module for generating the configuration for normal CAN communication;

[0095] A routing configuration module for generating the configuration for routing and some messages;

[0096] A control configuration module for generating the control configuration for message sending and receiving.

[0097] The present invention also provides an electronic device, including:

[0098] A memory for storing an executable computer program;

[0099] A processor for implementing the method of automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture when executing the executable computer program stored in the memory.

[0100] The present invention also provides a computer-readable storage medium storing a computer program for implementing the method of automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture when being executed by a processor.

[0101] In summary, based on the modular architecture of the basic software (BSW) specified by Autosar, the present invention proposes a method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture. By calibrating or writing configurations through UDS, the reuse of a software on multiple vehicle models and platforms is achieved, improving the software versatility, being convenient and fast, beneficial to reducing errors, enhancing work efficiency, and simplifying the requirement analysis process.

[0102] It should be noted that the magnitudes of the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0103] It should be pointed out that according to the needs of implementation, each step / component described in the present application can be split into more steps / components, or two or more steps / components or partial operations of steps / components can be combined into new steps / components to achieve the purpose of the present invention.

[0104] Those skilled in the art can easily understand that the above are only the preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture, characterized in that, it includes the following steps: Parse the CAN message description file for normal communication and the csv file with multiple configurations for messages that need to be routed or for normal communication; Generate the configuration for normal CAN communication; Generate the configuration for routing and some messages; Generate the message sending and receiving control configuration; Among them, generating the configuration for normal CAN communication includes: The mailbox of the CAN module uses the FIFO (First In First Out) mode to receive messages; Judge whether the currently processed CAN message is for reception or transmission; If it is a received message, create an EcucPduCollection class for the received message, namely message name A+"_CanIf2PduR” and A+"_PduR2Com” respectively; allocate the CAN bus cluster CAN-CLUSTER and CANID in the CAN message description file to the Can interface configuration container CanIfInitHohCfg's CanIfHrhCfg; CanIfHrhCfg is the receive configuration of the Can interface; Create a parameter container CanIfRxPduCfg class for the received PDU, the name is determined according to the message name A and the CAN-CLUSTER to which the message belongs, and configure it, including CAN ID, data length, the upper-layer module RxIndicationUL, PduRef, and PduHrhIdRef to which the message needs to be routed when received; among them, PduRef references the Pdu object defined by EcucPduCollection, referring to the created A_CanIf2PduR; PduHrhIdRef references the CanIfHrhCfg defined in CanIfInitHohCfg, referring to the CanIfHrhCfg to which the received message belongs; Create the routing mapping relationship PduRRoutingPath of the module, that is, the routing path of the Pdu, with the name of the message name A+"_CanIf2Com”; among them, PduRSrcPduRef references the Pdu object defined by EcucPduCollection as the source Pdu, which is the created A_CanIf2PduR, and PduRDestPdu references the Pdu object defined by EcucPduCollection as the target Pdu, which is the created A_PduR2Com; Create the Pdu Interaction Layer PDU parameter ComIpdu of the Com module, which is determined according to the message name A and the CAN-CLUSTER to which the message belongs. Configure the direction of the Ipdu, ComIPduDirection, as "RECEIVE", that is, receive. ComPduIdRef references the Pdu object defined by EcucPduCollection, which is A_PduR2Com created; ComIPduGroupRef references the Pdu group, which is configured as a group of Ipdu, "ComIPduGroup_Rx", for the control of normal communication; Create the communication layer signal ComSignal for all signals under this message, with the name being the signal name. Set its parsing method to support 4 data types, SINT, UINT, FLOAT, BOOLEAN, and the endian byte order, signal length, and the referenced SystemSignal, and add it under the created ComIpdu; finally, check whether there is a mapping relationship between this ComSignal and the interface of the SWC. If there is a mapping relationship, create the corresponding ComNotification interface, with the naming rule being "'Rte_COMCbk_” + the name of ComSignal; SystemSignal represents the way to exchange data between different defined ECUs; If it is a transmit message, create the EcucPduCollection class for the transmit message, which are A+"_PduR2CanIf" and A+"_Com2PduR" respectively for the message name A; allocate them to CanIfHthCfg of CanIfInitHohCfg according to the CAN-CLUSTER and CAN ID in the CAN message description file; Create the parameter container CanIfTxPduCfg class for the transmit PDU, with the name determined according to the message name A and the CAN-CLUSTER to which the message belongs, and configure it, including CAN ID, data length, the upper layer module TxConfirmationUL that needs to be confirmed when the message transmission is completed, PduRef, and PduHrhIdRef; PduRef references the created A_PduR2CanIf, and PduBufferRef references the configuration of the transmit buffer CanIfBufferCfg associated with the CanIfHthCfg to which the transmit message belongs; Create the routing mapping relationship PduRRoutingPath of the module, with the name being the message name A+"_Com2CanIf", where PduRSrcPduRef is the created A_Com2PduR, and PduRDestPdu is the created A_PduR2CanIf; Create a ComIpdu, which is determined by the message name A and the CAN-CLUSTER to which the message belongs. Configure ComIPduDirection as "SEND", that is, send. Configure the sending method according to the type of CAN message, and configure ComIPduGroupRef as "ComIPduGroup_Tx" for the control of normal communication; Create ComSignals for all signals under this message, with the name being the signal name. Set its parsing method to support 4 data types: SINT, UINT, FLOAT, BOOLEAN, and the endian byte order, signal length, and the referenced SystemSignal, and add them under the created ComIpdu.

2. The method for automatically generating multi-vehicle Can communication and routing configuration under the Autosar architecture according to claim 1, characterized in that, The csv file format is: Name; SrcId; SrcNode; DesId; DesNode; Length; Behavior; Addressing; VehicleConfig; respectively representing the CAN message name, source node CAN ID, source node, destination node CAN ID, destination node, data field length, behavior, addressing type, vehicle model or platform configuration; Among them, the behavior includes CAN and CAN-FD, and the addressing type includes standard and extended.

3. The method for automatically generating multi-vehicle Can communication and routing configuration under the Autosar architecture according to claim 2, characterized in that, The CAN message routing configuration rules are as follows: The CAN message name must be unique or the same as the message name in the CAN message description file. The source node CAN ID must be unique or the same as the message ID in the CAN message description file. The source node must be the same as one of the CAN message description files. The destination node CAN ID must be unique. The destination node must be the same as one of the CAN message description files and different from the source node. The data field length supports a maximum of 64 bytes and a minimum of 1 byte in CAN-FD mode, and a maximum of 8 bytes and a minimum of 1 byte in CAN mode. The behavior selects CAN or CAN-FD and must match the data length. The addressing type selects standard or extended. The vehicle model or platform configuration is any string. The multi-vehicle configuration is separated by a specific symbol, indicating that this rule applies to multiple vehicle models at the same time; For non-routing messages, but the configuration rules for prohibiting sending due to vehicle model differences are as follows: Only the CAN message name and the vehicle model or platform configuration are required. The CAN message name must be the same as the message name in the CAN message description file.

4. The method for automatically generating multi-vehicle Can communication and routing configuration under the Autosar architecture according to claim 1, characterized in that, The generation of routing and partial message configuration includes: Define the PduRRoutingPathGroup according to the vehicle model configuration and disable it by default; Determine whether the current message does not define SrcNode and DesNode; If so, if the current message has no vehicle model configuration, do nothing; if there is a vehicle model configuration, add the Pdu with the message name A+"_PduR2CanIf” to the grouping PduRRoutingPathGroup of the PduRRoutingPath of the current configuration; If not, if the Pdu with the message name A+"_CanIf2PduR” is not defined, create the corresponding configuration, otherwise if the Pdu with the message name A+"_PduR2CanIf” is not defined, create the corresponding configuration, otherwise if the PduRRoutingPath of the message name A+"_CanIf2Com” is not defined, create the routing mapping relationship PduRRoutingPath of the module, with the name of the message name A+"_CanIf2CanIf”, where PduRSrcPduRef is the aforementioned A_CanIf2PduR and PduRDestPdu is the aforementioned A_PduR2CanIf, otherwise in the existing PduRRoutingPath of A+"_CanIf2Com”, add PduRDestPdu as the aforementioned A_PduR2CanIf; Add the aforementioned A_PduR2CanIf to the PduRRoutingPathGroup of the current configuration.

5. The method for automatically generating multi-vehicle model Can communication and routing configuration under the Autosar architecture according to claim 4, characterized in that, Generating the message sending and receiving control configuration includes: Create the port BswMModeRequestPor for defining the mode request, set the BswM arbitration request method BswMRequestProcessing to "BSWM_IMMEDIATE”, use the specified request source which can only be the notification BswMBswModeNotification of other Bsw modules, and generate the mode set ModeDeclarationGroups required for this request port according to the vehicle model configuration; Generate the condition for mode execution BswMModeCondition, the expression for condition judgment BswMLogicalExpression, the action list for mode switching execution BswMActionList, and the modes included in the mode list BswMAction and BswMRule according to the described vehicle configuration; among them, BswMRule is the rule for mode execution, the action list executed when the condition is true or the action list executed when the condition is false, and each configuration has 2 types of condition, LogicalExpression, ActionList, Action, and Rule for enabling and disabling the corresponding PduRRoutingPathGroup. The described Action should use the BswMPduRouterAction for enabling or disabling the Pdu routing function as the execution action of BswM, and add all PduRRoutingPathGroups that meet the vehicle configuration to its control object. Open the required PduRRoutingPathGroup according to the vehicle configuration in the calibration or UDS configuration during the startup phase for the generated BswM control interface to achieve software reusability.

6. A system for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture for implementing the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of claims 1 to 5, Characterized in that, It includes: A message parsing module for parsing the CAN message description file for normal communication and the csv file with multiple configurations for messages that need to be routed or for normal communication; A communication configuration module for generating the configuration for normal CAN communication; A routing configuration module for generating the configuration for routing and some messages; A control configuration module for generating the control configuration for message sending and receiving.

7. A vehicle, Characterized in that, This vehicle adopts the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of claims 1 to 5.

8. An electronic device, Characterized in that, It includes: A memory for storing an executable computer program; A processor, when executing the executable computer program stored in the memory, implements the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of claims 1 to 5.

9. A computer-readable storage medium, Characterized in that, It stores a computer program, which, when executed by a processor, implements the method for automatically generating multi-vehicle Can communication and routing configurations under the Autosar architecture described in any one of claims 1 to 5.

Images