Autosar-oriented multi-id message hardware queue allocation optimization method

Abstract

This invention discloses an optimization method for hardware queue allocation of multi-ID messages for AUTOSAR, belonging to the field of vehicular network communication technology. The core of this method, through the collaborative configuration of the AUTOSAR toolchain, lies in: first, aggregating and classifying multiple CAN message IDs to be sent according to preset rules, and creating a software transmission queue corresponding to each category; second, configuring mask-based filtering rules for each software queue to match its corresponding multiple message IDs; and finally, mapping multiple software queues to the same physical hardware TX mailbox, enabling the sharing of multiple message IDs with that hardware mailbox. This invention breaks the traditional one-to-one binding limitation, significantly improving hardware resource utilization and configuration efficiency without increasing hardware costs or software queue burden, effectively meeting the gateway's real-time forwarding requirements for a large number of message IDs.

Description

Technical Field

[0001] This invention relates to the field of vehicle network communication technology, and specifically to an optimization method for multi-ID packet hardware queue allocation for the AUTOSAR open system architecture for automobiles. Background Technology

[0002] With the rapid development of automotive electronic and electrical architecture, the level of vehicle intelligence and connectivity is constantly improving, leading to a surge in the number of Electronic Control Units (ECUs) in in-vehicle networks, resulting in increasingly complex network topologies. As the core of data exchange in in-vehicle networks, gateways undertake the routing and forwarding of massive amounts of CAN messages between different network segments, and the number of message IDs they need to process is also growing explosively.

[0003] In current AUTOSAR Classic platform gateway configuration schemes, a straightforward and simple configuration logic is commonly adopted: a one-to-one static binding is made between a message ID to be sent and a hardware transmit mailbox (TX mailbox). During the message transmission process, the upper-layer PduR module routes the message to the CanInterface module. The CanInterface module, based on the pre-configured mapping relationship, writes the message to its uniquely corresponding hardware TX mailbox and triggers hardware transmission. This single-ID-bound-single-mailbox mode is simple to configure, has a clear message processing path, and can work stably in scenarios with a small number of messages.

[0004] However, this existing technology has significant drawbacks: due to the limited hardware resources of the MCU chip, the number of hardware TX mailboxes that each CAN controller can provide is fixed, for example, 32 or 64 for some chips. When the number of message IDs that the gateway needs to forward far exceeds the number of hardware mailboxes, the limited hardware resources will be quickly exhausted, making it impossible to configure a sending channel for newly added message IDs. This has become a core bottleneck restricting the expansion of gateway functions and performance improvement. Although theoretically, messages to be sent can be temporarily stored by introducing complex software queue management, this will increase message processing latency, affect real-time performance, and may introduce packet loss risks, making it difficult to meet the stringent requirements of vehicle communication. At the same time, configuring hundreds or thousands of message IDs one by one is a large and repetitive task with extremely low configuration efficiency. Summary of the Invention

[0005] In view of the above, the present invention aims to provide an optimization method for hardware queue allocation of multi-ID messages for AUTOSAR, so as to solve the technical problem in the prior art that the limited TX mailbox resources of MCU hardware lead to the exhaustion of hardware resources and low configuration efficiency when forwarding a large number of message IDs.

[0006] The technical solution adopted in this invention is as follows:

[0007] This invention provides an optimization method for hardware queue allocation of multi-ID packets for AUTOSAR, applied to a vehicle gateway controller, including:

[0008] Obtain multiple CAN IDs to be forwarded, and aggregate and classify the multiple CAN IDs according to preset classification rules, such as message period and function priority, to obtain at least one message classification set;

[0009] In the CanInterface module of the AUTOSAR architecture, a corresponding software transmission queue is created for each of the aforementioned message classification sets, and all CAN IDs in the set are bound to the software queue; here, the software queue is a logical transmission channel, decoupled from specific hardware resources;

[0010] In the CanFilter module of the AUTOSAR architecture, a corresponding filtering rule is configured for each software transmission queue. This rule is set based on the mask and ID value and is used to accurately match all CAN IDs in its corresponding message classification set to ensure that messages belonging to the same queue can be correctly identified and routed.

[0011] At least one of the software sending queues is mapped and bound to the same physical hardware TX mailbox, and sending parameters such as baud rate and triggering method are configured for the physical hardware TX mailbox. This step breaks the traditional one-to-one limitation and enables multiple logical queues (i.e., multiple message IDs) to share a single hardware mailbox.

[0012] In actual operation, when the gateway controller receives a CAN message to be forwarded, it first parses its CAN ID, matches the corresponding software transmission queue according to the parsed CAN ID, and then writes the message data into the physical hardware TX mailbox bound to the software transmission queue, thereby triggering the hardware transmission process.

[0013] In at least one of the possible implementations, the preset classification rules can aggregate and classify messages based on one or more combinations of message sending period, functional priority, or message type. For example, periodic messages with similar periods or multiple CAN IDs with priorities within the same preset range can be grouped into the same message classification set to avoid interference between high and low priority messages.

[0014] In at least one of the possible implementations, the core parameters of the created software sending queue, such as timeout time and forwarding path, are set by the upper-layer configuration tool and stored in an ARXML configuration file.

[0015] In at least one of the possible implementations, the mapping binding is specifically implemented through toolchain collaboration: firstly, an ARXML file containing the upper-layer software queue configuration is exported through a first configuration tool; then, the file is imported through a second configuration tool (such as EB tresos), and a one-to-one static mapping configuration is performed between the identifier of the software queue and the physical hardware TX mailbox specified in the CAN controller of the target MCU chip (such as NXPS32K312) at the underlying CAN driver layer.

[0016] In at least one of the possible implementations, in the final stage, when there are multiple CAN messages to be sent corresponding to the same software sending queue, the CanInterface module writes the message data into the physical hardware TX mailbox in sequence according to the preset priority order of each message, thereby ensuring the logical order of message sending while sharing hardware resources.

[0017] Compared to existing technologies, this invention fundamentally solves the problem of insufficient hardware mailboxes by sharing multiple ID messages across a single hardware TX mailbox. This allows the gateway to support message ID forwarding demands far exceeding the number of hardware mailboxes without replacing the MCU or increasing hardware costs. In particular, the core concept of this invention lies in direct transmission at the hardware level, avoiding the uncertain latency and packet loss risks associated with complex software queue caching and scheduling mechanisms. Furthermore, the classification and aggregation based on message attributes and the toolchain collaborative configuration elevate the configuration object from a single message ID to a set of messages, significantly reducing the configuration workload. Those skilled in the art will understand that subsequent adjustments or additions to messages only require modification within the corresponding software queue, without altering the underlying hardware mapping, significantly reducing iterative maintenance costs. Therefore, this invention, based on the standard AUTOSAR architecture, with its core idea of ​​upper-layer aggregation to lower-layer sharing, possesses good versatility and is easily ported and extended to other AUTOSAR-compliant MCU platforms. Attached Figure Description

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described below with reference to the accompanying drawings, wherein:

[0019] Figure 1 A schematic diagram of the flowchart of the AUTOSAR multi-ID message hardware queue allocation optimization method provided in the embodiments of the present invention;

[0020] Figure 2 This is a schematic diagram of the AUTOSAR CAN message transmission process in an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of the ISOLAR tool configuration in an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram of the EB tresos tool configuration in an embodiment of the present invention. Detailed Implementation

[0023] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0024] The following embodiments use a specific hardware and software environment as an example to illustrate the present invention. Figure 1 This document describes a detailed explanation of an AUTOSAR-oriented multi-ID message hardware queue allocation optimization method. The hardware platform is based on the NXP S32K312 MCU, with each CAN controller having 32 or 64 TX / RX mailboxes, paired with a TJA1443AT CAN transceiver and a customized vehicle gateway hardware board. The software utilizes the AUTOSAR Classic 4.4 architecture, with ISOLAR-A / B used for configuration. ISOLAR-A / B handles upper-layer modules such as PduR and CanInterface, as well as BSW configuration, while EB Tresos Studio handles lower-layer drivers such as the MCAL layer CanDriver. CANoe is used for testing, simulating message requests and data acquisition. The scenario to be optimized in this example involves forwarding over 100 different ID messages on a single CAN channel. Further details can be found by referring to... Figure 2 This illustrates the standard AUTOSAR CAN message transmission process.

[0025] Based on the above environment, the optimization method of the present invention is as follows: Figure 1 The illustration includes the following specific implementation steps:

[0026] Step S1: Message ID aggregation and classification;

[0027] In practice, a preset gateway communication matrix can be imported into the ISOLAR-A / B tool. Then, all message IDs (range, for example, 0x100-0x7xx) that need to be forwarded by the gateway can be filtered from the matrix. Next, these message IDs are aggregated and classified according to preset classification rules. In some preferred embodiments, the classification rules are mainly based on the message's functional priority and transmission period. For example, high-priority diagnostic messages are grouped together, and periodic messages with similar periods (such as 10ms and 20ms) are classified separately. In this embodiment, more than 100 message IDs are divided into several logical sets according to their functions, such as message routing, signal routing, and period differences, ensuring that the messages within each set are similar in terms of real-time requirements.

[0028] Step S2: Create a software sending queue;

[0029] Based on the above example, in the CanInterface module configuration interface of the ISOLAR-A / B tool, enter the Tx QueueConfiguration option; then, according to each message category set divided in step S1, create a corresponding software transmission queue Tx Queue, name each software transmission queue, and configure its core parameters, such as timeout time and forwarding path; the most crucial step is to bind all CAN IDs in the category set to the software transmission queue one by one, establishing the association relationship between multiple IDs and a single queue.

[0030] Step S3: Configure multi-ID mask filtering rules;

[0031] Further, in the CanFilter module configuration interface of the ISOLAR-A / B tool, configure corresponding filtering rules for each software transmission queue created in step S2. These filtering rules are not targeted at a single ID, but rather achieve matching of an ID range by configuring a mask and the desired ID value (Code). For example, through appropriate mask settings, a filtering rule can accurately hit all CAN IDs bound to the software queue. After configuration, bind these software queues to one or more common hardware TX mailbox identifiers (TxMailboxId, which is a logical identifier in this case). After completing the above upper-level configuration, export the ARXML configuration file containing all information. The above ISOLAR-A / B configuration diagram can be found in the reference diagram. Figure 3 Indication.

[0032] Step S4: Low-level hardware mapping and parameter configuration;

[0033] In practice, open the EB tresos Studio tool and perform the following sub-steps to complete the underlying adaptation:

[0034] Step S401: Import the ARXML file generated by ISOLAR to ensure that the configuration information of the upper layer regarding software queues and filtering rules is completely synchronized to the lower layer project.

[0035] Step S402: Enter the configuration interface of the CanDriver module and find the Hardware Mailbox Mapping option.

[0036] In this step, the logical public mailbox identifiers (TxMailboxId) configured in ISOLAR are mapped one by one to the specific physical hardware TX mailboxes of the NXP S32K312 chip CAN controller. For example, the identifiers of multiple software send queues can be mapped to the same hardware mailbox with the same physical address, thus forming the final mapping relationship of multiple queues to one hardware mailbox.

[0037] Step S403: Configure the sending parameters of the physical hardware mailbox;

[0038] For example, set the CAN communication baud rate to 500kbps and select "Immediate" as the sending trigger mode.

[0039] Step S404: In the Can module configuration, enable the Can Multiplexed Transmission mode and enable the mailbox sending completion interrupt so that the upper layer module can know the message sending status in real time; and synchronously check and adapt the interaction interface configuration of the CanDriver and CanInterface modules to ensure that the data path is unobstructed; after completing all configurations, generate the basic software code of the gateway.

[0040] The configuration interface for EB tresos mentioned above can be found in [reference]. Figure 4 Indication.

[0041] Step S5: Code integration and testing verification;

[0042] Specifically, this can be broken down into the following sub-steps:

[0043] Step S501: Use the debugging tool to flash the software code generated by EB tresos into the NXP S32K312 MCU chip;

[0044] Step S502: Build a complete gateway test bench that includes gateway hardware boards, CANoe testing tools and related loads;

[0045] Step S503: Use CANoe to simulate multiple vehicle ECUs and send a large number of CAN message requests with different IDs to the gateway concurrently to simulate a real complex bus load scenario.

[0046] Step S504: After receiving the message request, the gateway's internal processing flow is as follows:

[0047] First, the PduR module routes the message to the CanInterface module; the CanInterface module parses the message ID and matches the message ID to the corresponding software send queue according to the configuration in ISOLAR; then, the CanInterface module writes the message data to the physical hardware TX mailbox bound to the software queue in sequence according to the priority order of each message in the queue.

[0048] In step S505, the CanDriver module monitors the status of the hardware TX mailbox in real time. Once new data is detected, the hardware transmission logic is immediately triggered to send the message to the bus via the CAN transceiver.

[0049] Finally, step S6 is executed: continuously collect data on the bus via CANoe and perform statistical analysis.

[0050] The test results of the above embodiments show that the gateway can stably send all 100+ different IDs of messages. No packet loss or error occurred during the entire test process, and the average message sending delay was only 3ms, which fully meets the stringent requirements of automotive electronic control systems for real-time communication.

[0051] It is particularly important to emphasize that, in order to ensure the smooth implementation of the present invention and achieve the expected results, the following points should be noted in actual operation:

[0052] (1) Reasonableness of classification and aggregation: The classification rules in step S1 are crucial. It is necessary to strictly distinguish between message priority and period to avoid aggregating messages with completely different real-time requirements into the same queue, so as to prevent high-priority messages from being blocked by low-priority messages and affecting the overall real-time performance of the system.

[0053] (2) Consistency of configuration parameters: It is necessary to ensure that the parameters between ISOLAR (upper layer) and EB tresos (lower layer) configuration tools are completely consistent, especially the mapping relationship of key information such as mailbox identifier and queue identifier, to prevent message sending and receiving chaos or loss due to misconfiguration.

[0054] (3) Sufficient scenario verification: In the test and verification stage of step S5, the worst possible concurrent scenarios should be fully simulated, such as all aggregated messages arriving at the same time, the bus load rate approaching saturation, etc., to verify the stability and reliability of the solution under various working conditions.

[0055] In summary, this invention constructs a complete optimization solution to address hardware resource bottlenecks by organically combining three core methods: multi-ID packet classification and aggregation, AUTOSAR toolchain collaborative configuration, and multi-ID masking filtering technology. The core concept of this solution lies in breaking away from the traditional bias that packet IDs must correspond one-to-one with hardware mailboxes. Instead, it achieves maximum utilization of limited hardware resources through aggregation and scheduling at an intermediate software layer. This is not only an optimization of configuration strategies but also a deep exploration of the resource management capabilities of the AUTOSAR communication protocol stack. When facing insufficient hardware resources, the industry typically tends to upgrade hardware or add software caching. However, this invention achieves a soft extension of hardware performance through software configuration, bringing unexpected technical effects. Specifically, it significantly improves the packet processing capabilities and configuration efficiency of gateways at almost zero hardware cost, possessing extremely high industrial application value.

[0056] In this invention, when directional terms are mentioned, they are relative concepts based on the embodiments. Furthermore, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0057] The above description of the structure, features, and effects of the present invention is based on the embodiments shown in the figures. However, the above are only preferred embodiments of the present invention. It should be noted that the technical features involved in the above embodiments and their preferred methods can be reasonably combined and matched by those skilled in the art to form a variety of equivalent solutions without departing from or changing the design concept and technical effects of the present invention. Therefore, the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for optimizing hardware queue allocation of multi-ID packets for AUTOSAR, characterized in that, Applied to vehicle gateway controllers, including: Obtain multiple CAN message identifiers (IDs) to be forwarded from the Controller Area Network (CAN) and aggregate and classify the multiple CAN IDs according to a preset classification rule to obtain at least one message classification set. In the CanInterface module of the AUTOSAR architecture, a corresponding software transmission queue is created for each message classification set, and all CAN IDs in the message classification set are bound to the corresponding software transmission queue. In the CAN filter layer CanFilter of the AUTOSAR architecture, a corresponding filtering rule is configured for each software transmission queue. The filtering rule is set based on the mask and CAN ID value and is used to match all CAN IDs in its corresponding message classification set. Map and bind at least one of the software sending queues to the same physical hardware sending TX mailbox, and configure sending parameters for the TX mailbox; When the gateway controller receives a CAN message to be forwarded, it parses its CAN ID, matches the corresponding software transmission queue according to the parsed CAN ID, and writes the message data into the TX mailbox bound to the software transmission queue to trigger the hardware transmission process.

2. The multi-ID message hardware queue allocation optimization method according to claim 1, characterized in that, The classification rules include: performing aggregation classification based on one or more combinations of message transmission period, functional priority, or message type, so as to classify multiple CAN IDs with similar periods or priorities within the same preset range into the same message classification set.

3. The multi-ID message hardware queue allocation optimization method according to claim 1, characterized in that, The parameters in the software sending queue include at least: timeout time and forwarding path, and are set by the upper-layer configuration tool and stored in the AUTOSAR exchangeable ARXML configuration file.

4. The multi-ID message hardware queue allocation optimization method according to claim 1, characterized in that, The mapping binding specifically includes: Export an ARXML file containing upper-layer software send queue configuration information using the first configuration tool; The ARXML file is imported using the second configuration tool, and a one-to-one static mapping configuration is performed between the identifier of the software send queue and the physical hardware TX mailbox specified in the CAN controller of the target MCU chip in the underlying CAN driver layer.

5. The multi-ID message hardware queue allocation optimization method according to claim 4, characterized in that, Configure sending parameters for the TX mailbox, including configuring the baud rate and sending trigger method, and enabling mailbox sending completion interruption to realize sending status feedback.

6. The multi-ID message hardware queue allocation optimization method according to claim 1, characterized in that, When there are multiple CAN messages to be sent in the same software sending queue, the CanInterface module writes the message data into the TX mailbox in sequence according to the preset priority order of each message.

7. The multi-ID message hardware queue allocation optimization method according to any one of claims 1 to 6, characterized in that, The gateway controller is a hardware platform built on the NXP S32K312 series MCU, and its CAN controller contains multiple hardware TX mailboxes.

Images