Gateway routing method, apparatus, electronic device, and medium

Abstract

The application discloses a gateway routing method and device, electronic equipment and medium, and relates to the technical field of gateways. The method comprises the following steps: receiving a to-be-forwarded message, and analyzing the to-be-forwarded message to extract a message identifier of the to-be-forwarded message; in response to the message identifier not matching a first routing rule data file, extracting a source controller identifier of the to-be-forwarded message, and determining a second routing rule data file corresponding to the to-be-forwarded message based on the source controller identifier; in response to the message identifier matching the second routing rule data file, querying the second routing rule data file based on the message identifier to determine a routing rule of the to-be-forwarded message; and determining a target controller corresponding to the to-be-forwarded message based on the routing rule of the to-be-forwarded message, and routing the to-be-forwarded message to the target controller. In this way, when facing a routing change requirement, only the second routing rule data file needs to be modified to complete the adaptation, and the development cycle is significantly shortened.

Description

Technical Field

[0001] This application relates to the field of gateway technology, and in particular to a gateway routing method, a gateway routing device, a computer-readable storage medium, and an electronic device. Background Technology

[0002] With the increasing intelligence and connectivity of automobiles, the number of in-vehicle electronic control units has surged. As the core hub for data interaction in the whole vehicle, the accuracy and flexibility of the routing table of the in-vehicle gateway directly determines the reliability of the whole vehicle network communication.

[0003] Currently, the configuration of routing tables for vehicle gateways generally adopts a development model of static pre-compilation and offline hardening. The specific process of this model is as follows: During the vehicle model definition stage, the OEM locks the vehicle's electronic and electrical architecture and signal matrix, and then releases the DBC file (CAN database file) or ARXML file (Extensible Markup Language file) containing complete routing relationships to the gateway supplier and the associated ECU (Electronic Control Unit) supplier; Based on this static file, the supplier's engineers manually configure the underlying software or calibrate the module parameters using tools such as ETAS or Vector, and finally burn the hardened routing table software into the gateway hardware.

[0004] However, for different configuration tiers within the same vehicle platform, gateways require supplier engineers to manually modify the code at the code level using tools like ETAS to generate multiple independent routing table firmwares. This results in a linear increase in development cycle with the number of configurations, high R&D costs, and difficulty in ensuring consistency of the underlying software. Furthermore, when OEMs require routing changes due to feature iterations, they must go through multiple sequential steps, including architecture file release, supplier evaluation, code modification, testing and verification, and final flashing. This involves frequent coordination between OEMs and multiple levels of suppliers, leading to low software maintenance efficiency; even minor changes can take several days to weeks to implement. In addition, because detailed design documents containing the vehicle topology and signal matrix must be distributed to component suppliers to support routing development, there is a significant risk of leakage of vehicle electronic and electrical architecture information, making confidentiality management difficult.

[0005] In summary, the relevant technical solutions face significant technical bottlenecks that urgently need to be overcome in terms of development flexibility, maintenance response speed, and information security protection. Summary of the Invention

[0006] This application aims to at least partially address one of the technical problems in the related art. To this end, the first objective of this application is to propose a gateway routing method, comprising: receiving a packet to be forwarded and parsing the packet to be forwarded to extract a packet identifier; in response to a mismatch between the packet identifier and a first routing rule data file, extracting a source controller identifier of the packet to be forwarded, and determining a second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier; in response to a match between the packet identifier and the second routing rule data file, querying the second routing rule data file based on the packet identifier to determine the routing rule for the packet to be forwarded; and based on the routing rule for the packet to be forwarded, determining the target controller corresponding to the packet to be forwarded, and routing the packet to be forwarded to the target controller.

[0007] Thus, through the hierarchical management mechanism that divides routing rules into a static, fixed layer and a dynamic, configurable layer, OEMs only need to modify the second routing rule data file to adapt to different vehicle configurations or routing changes resulting from later functional iterations. This eliminates the need to recompile or replace the entire gateway firmware, significantly shortening the change development cycle and reducing software maintenance costs. Since only the first routing rule data file containing static basic routing information needs to be provided when distributing design documents to component suppliers, the second routing rule data file, which involves the complete vehicle topology and signal matrix, can be maintained internally in a closed loop by the OEM, effectively avoiding the risk of leakage of core electronic and electrical architecture information during the supply chain process. At the same time, the above routing matching process is executed in real time during gateway operation without restarting the device or interrupting bus communication, ensuring the real-time performance and stability of the vehicle network.

[0008] The second objective of this application is to provide a gateway routing device.

[0009] The third objective of this application is to provide a computer-readable storage medium.

[0010] The fourth objective of this application is to propose an electronic device.

[0011] To achieve the above objectives, a first aspect of this application proposes a gateway routing method, comprising: receiving a packet to be forwarded and parsing the packet to be forwarded to extract a packet identifier; in response to a mismatch between the packet identifier and a first routing rule data file, extracting a source controller identifier of the packet to be forwarded and determining a second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier; in response to a match between the packet identifier and the second routing rule data file, querying the second routing rule data file based on the packet identifier to determine a routing rule for the packet to be forwarded; and determining a target controller corresponding to the packet to be forwarded based on the routing rule for the packet to be forwarded, and routing the packet to be forwarded to the target controller.

[0012] According to one embodiment of this application, determining the second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier includes: determining the routing rule storage area of ​​the packet to be forwarded based on the source controller identifier, wherein the routing rule storage area is used to store the second routing rule data file corresponding to the packet to be forwarded; wherein the second routing rule data file is written to the corresponding routing rule storage area through the cloud.

[0013] According to one embodiment of this application, writing a second routing rule data file to the corresponding routing rule storage area via the cloud includes: obtaining a routing rule table of a vehicle gateway, wherein each routing rule in the routing rule table includes a source controller identifier; grouping the routing rules in the routing rule table based on the source controller identifier to obtain multiple routing rule subsets; mapping the addresses of the multiple routing rule subsets respectively using a preset script based on the base address of the routing rule storage area corresponding to the source controller identifier, so as to convert each routing rule subset into a corresponding second routing rule data file; and writing each second routing rule data file to the corresponding routing rule storage area based on the base address of the routing rule storage area corresponding to the source controller identifier.

[0014] According to one embodiment of this application, each routing rule further includes a message identifier, and before grouping the routing rule set based on the source controller identifier, the method further includes: sorting the routing rules in the routing rule set according to the numerical value of the message identifier.

[0015] According to one embodiment of this application, each routing rule also includes a target controller identifier and a message frame format. The routing rules in the second routing rule data file are stored in a preset storage format, wherein the preset storage format includes the low bit of the message identifier, the high bit of the message identifier, the target controller identifier, and the message frame format.

[0016] According to one embodiment of this application, the method further includes: in response to a match between a message identifier and a first routing rule data file, querying the first routing rule data file based on the message identifier to determine the routing rule for the message to be forwarded; determining the target controller corresponding to the message to be forwarded based on the routing rule for the message to be forwarded, and routing the message to be forwarded to the target controller.

[0017] According to one embodiment of this application, based on the routing rules of the message to be forwarded, the target controller corresponding to the message to be forwarded is determined, and the message to be forwarded is routed to the target controller. The method further includes: in response to the failure of routing the message to be forwarded, the routing rules of the message to be forwarded are written into the corresponding subset of routing rules based on the source controller identifier of the message to be forwarded.

[0018] To achieve the above objectives, a second aspect of this application provides a gateway routing apparatus, comprising: a parsing module, configured to receive a packet to be forwarded and parse the packet to be forwarded to extract a packet identifier; a first determining module, configured to, in response to a mismatch between the packet identifier and a first routing rule data file, extract a source controller identifier of the packet to be forwarded and determine a second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier; a second determining module, configured to, in response to a match between the packet identifier and the second routing rule data file, query the second routing rule data file based on the packet identifier to determine the routing rule for the packet to be forwarded; and a routing module, configured to, based on the routing rule for the packet to be forwarded, determine the target controller corresponding to the packet to be forwarded and route the packet to be forwarded to the target controller.

[0019] To achieve the above objectives, a third aspect of this application provides a computer-readable storage medium storing a gateway routing program thereon, which, when executed by a processor, implements the aforementioned gateway routing method.

[0020] To achieve the above objectives, a fourth aspect of this application provides an electronic device including a memory, a processor, and a gateway routing program stored in the memory and capable of running on the processor. When the processor executes the gateway routing program, it implements the aforementioned gateway routing method.

[0021] According to the gateway routing method, apparatus, electronic device, and medium of this application embodiment, a message to be forwarded is received and parsed to extract the message identifier of the message to be forwarded; in response to a mismatch between the message identifier and a first routing rule data file, the source controller identifier of the message to be forwarded is extracted, and a second routing rule data file corresponding to the message to be forwarded is determined based on the source controller identifier; in response to a match between the message identifier and the second routing rule data file, the second routing rule data file is queried based on the message identifier to determine the routing rule of the message to be forwarded; based on the routing rule of the message to be forwarded, the target controller corresponding to the message to be forwarded is determined, and the message to be forwarded is routed to the target controller. Thus, through the hierarchical management mechanism that divides routing rules into a static, fixed layer and a dynamic, configurable layer, OEMs only need to modify the second routing rule data file to adapt to different vehicle configurations or routing changes resulting from later functional iterations. This eliminates the need to recompile or replace the entire gateway firmware, significantly shortening the change development cycle and reducing software maintenance costs. Since only the first routing rule data file containing static basic routing information needs to be provided when distributing design documents to component suppliers, the second routing rule data file, which involves the complete vehicle topology and signal matrix, can be maintained internally in a closed loop by the OEM, effectively avoiding the risk of leakage of core electronic and electrical architecture information during the supply chain process. At the same time, the above routing matching process is executed in real time during gateway operation without restarting the device or interrupting bus communication, ensuring the real-time performance and stability of the vehicle network. Attached Figure Description

[0022] Figure 1 This is a flowchart of a gateway routing method according to some embodiments of this application; Figure 2 This is a schematic diagram of the structure of a gateway routing device according to some embodiments of this application; Figure 3 This is a block diagram of an electronic device according to some embodiments of this application; Figure 4 This is a block diagram of a vehicle according to some embodiments of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of the 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 intended to explain this application, and should not be construed as limiting this application.

[0024] As a core component of the vehicle's electronic and electrical architecture, the vehicle gateway primarily undertakes multiple tasks such as data transmission, security control, and remote diagnostics. With the evolution of electronic and electrical architecture from distributed to centralized domain architecture, gateways have also undergone significant changes. Their evolution path can be divided into three main stages: the traditional CAN (Controller Area Network) gateway stage under a distributed architecture, the centralized gateway stage under a domain-centralized architecture, and the distributed gateway stage under a Zonal architecture.

[0025] In the traditional CAN gateway stage under a distributed architecture, communication between various systems in the early stages of vehicle electronic systems mainly relied on the CAN bus. At this time, the core function of the vehicle gateway was focused on data forwarding and routing on the CAN bus.

[0026] Entering the centralized gateway stage under the domain-centralized architecture, with the enrichment of vehicle functions and the increase in system complexity, the electronic and electrical architecture begins to show domain division characteristics, such as the body domain, chassis domain, power domain, etc. are formed one after another. The vehicle gateway not only needs to continuously process CAN bus data, but also needs to undertake the coordination and management functions of communication between different domains.

[0027] In the distributed gateway stage of the Zonal architecture, in order to further improve system integration and response speed, the vehicle is divided into several areas. Communication within each area is achieved through a high-speed bus, and interconnection between areas is accomplished through an on-board gateway. This architecture places more stringent requirements on the gateway's data processing capabilities and transmission latency.

[0028] At the technical implementation level, existing vehicle gateways generally employ high-performance processors and are equipped with advanced communication protocols such as Ethernet and SOME / IP (Scalable service-oriented middleware over IP) to achieve efficient and reliable data transmission. Meanwhile, to ensure vehicle network security, the gateway also integrates multiple security mechanisms such as data encryption and access control.

[0029] However, current automotive gateway technology still faces several prominent challenges in practical applications. Firstly, complexity continues to rise. As vehicle functions become increasingly sophisticated, the amount of data that gateways need to process expands dramatically, and logical complexity increases accordingly. This poses a severe test to processing performance and transmission latency, while significantly raising the technical threshold for development and maintenance. Secondly, the security situation is tightening. The rapid development of vehicle-to-everything (V2X) technology has led to increasingly close interconnections between vehicles and external networks. As a key bridge for internal and external communication, gateways must directly confront increasingly diverse network attacks and security threats, resulting in ever-increasing protection pressure. Thirdly, compatibility issues persist. Given the inherent differences in electronic and electrical architectures between different vehicle models and OEMs, gateways need sufficient adaptability to support cross-vehicle and cross-manufacturer data exchange and communication. However, due to multiple practical constraints, compatibility issues are still difficult to completely avoid in actual deployments. Fourthly, cost pressures are becoming increasingly prominent. The creation of high-performance gateways cannot be separated from the support of advanced processors and high-end communication protocols, which in turn drives up hardware manufacturing costs. Meanwhile, the investment in software development and maintenance, which increases in functionality and complexity, further exacerbates the overall cost burden. How to find a balance between functionality, performance and cost has become an unavoidable key issue in the evolution of technology.

[0030] Focusing further on the engineering implementation of vehicle gateway routing tables, the shortcomings of related technical solutions in terms of development efficiency and information security are particularly significant. Currently, the industry generally adopts a routing table development model based on static pre-compilation and offline hardening. For different configuration tiers derived from the same vehicle platform, gateways require supplier engineers to manually modify the code at the differential level using professional tools such as ETAS (Engineering Tools, Applications and Services) to generate multiple independent routing table firmware sets. This model results in a linear extension of the development cycle with the number of configurations, prominent duplication of R&D costs, and difficulty in effectively ensuring the consistency of underlying software versions. When OEMs require changes to routing relationships due to functional iterations or architectural adjustments, the response chain under the existing technical framework is extremely lengthy, requiring multiple sequential steps such as distributing architecture documents to suppliers, internal supplier evaluation, code modification implementation, testing and verification, and final software flashing. This involves frequent back-and-forth coordination between OEMs and multiple levels of suppliers. Even for minor change requests, it can take several days to several weeks to achieve a closed loop, resulting in overall low software maintenance efficiency. Even more serious is the fact that, to ensure the smooth development of routing tables, OEMs have to distribute detailed design documents containing the vehicle's topology and complete signal matrix to component suppliers. This information release process exposes the core secrets of the vehicle's electronic and electrical architecture to a high risk of leakage, placing immense pressure on information security and confidentiality management. The existing solutions mentioned above all have critical technical bottlenecks that urgently need to be overcome in key areas such as development flexibility, agility in responding to demands, and core data protection capabilities.

[0031] Based on this, after receiving a message to be forwarded, the gateway of this application first extracts the message identifier and performs a matching verification with the first routing rule data file stored in the read-only storage area. If the verification fails, it further extracts the source controller identifier corresponding to the message to retrieve the second routing rule data file stored in the erasable storage area. Then, it queries the second routing rule data file according to the message identifier to obtain the corresponding routing rule, and accurately routes the message to be forwarded to the target controller accordingly.

[0032] The gateway routing method, apparatus, electronic device, and medium of this application embodiment will now be described in detail with reference to the accompanying drawings.

[0033] Figure 1 This is a flowchart of a gateway routing method according to some embodiments of this application. (Refer to...) Figure 1 The gateway routing method in this application embodiment may include the following steps: S110 receives the message to be forwarded and parses it to extract the message identifier.

[0034] Specifically, after the gateway receives the message to be forwarded from the bus interface, it first performs layer-by-layer parsing of the message data frame according to the communication protocol stack corresponding to the current bus type in order to extract the message identifier of the message to be forwarded.

[0035] For example, for CAN bus messages, the gateway extracts the arbitration field field in the data frame to obtain the CAN ID as the message identifier; for automotive Ethernet messages, the gateway parses the protocol header information and extracts the combined field of Service ID and Method ID from the SOME / IP message header, or extracts the combined field of source port number and destination port number from the UDP (User Datagram Protocol) or IP (Internet Protocol) message header, and uses this combined field as the message identifier.

[0036] S120, in response to the mismatch between the message identifier and the first routing rule data file, extract the source controller identifier of the message to be forwarded, and determine the second routing rule data file corresponding to the message to be forwarded based on the source controller identifier.

[0037] Specifically, if the gateway confirms through query and comparison that the extracted message identifier is not recorded in the first routing rule data file that is stored in the hard drive, that is, it is determined that the message identifier does not match the first routing rule data file, then the gateway further extracts the source controller identifier from the parsed message data frame. The source controller identifier can be the node address identifier in the CAN message or the source IP address and source MAC address in the Ethernet message, which can uniquely identify the identity of the message sender controller.

[0038] Based on the extracted source controller identifier, the gateway searches a preset mapping table to determine the storage address and index information of the second routing rule data file associated with the source controller, thereby locating and retrieving the second routing rule data file and providing a basis for subsequent routing rule matching in the dynamic configuration file.

[0039] S130, in response to the message identifier matching the second routing rule data file, the second routing rule data file is queried based on the message identifier to determine the routing rule for the message to be forwarded.

[0040] Specifically, after locating and retrieving the second routing rule data file, the gateway uses the extracted packet identifier as a query index to traverse and match within the second routing rule data file. The second routing rule data file stores the correspondence between packet identifiers and routing rules in the form of key-value pairs or table entries. Each table entry contains at least a packet identifier field and corresponding routing action parameters such as the target controller address, forwarding port, and transmission protocol type.

[0041] Unlike the first routing rule data file, which is fixed in read-only storage and cannot be changed after leaving the factory, this second routing rule data file is stored in the gateway's erasable and writable storage area. Its internal entries can be added, deleted, modified, and retrieved by the OEM throughout the vehicle's lifecycle via diagnostic commands or remote over-the-air downloads. For example, when changes in vehicle configuration lead to new controllers or signal interaction requirements, the OEM only needs to write the new message identifier and corresponding routing rule entry into the second routing rule data file, or correct the target controller address in the existing entry, to complete the online update of the routing policy. This process requires no replacement of the gateway hardware or re-flashing of the underlying firmware.

[0042] When the gateway finds an entry in the second routing rule data file that matches the current packet identifier, it determines that the packet identifier matches the second routing rule data file and reads the complete routing rule information defined in the entry. This clarifies the forwarding path, target exit, and required protocol conversion method of the packet to be forwarded within the gateway, providing a basis for decision-making to accurately deliver the packet to the target controller.

[0043] S140: Based on the routing rules of the message to be forwarded, determine the target controller corresponding to the message to be forwarded, and route the message to be forwarded to the target controller.

[0044] Specifically, the gateway parses the key forwarding parameters defined by the routing rules obtained from the second routing rule data file, such as the target controller address, target port identifier, and transmission protocol type, to determine the target controller to which the forwarded message should be delivered.

[0045] After determining the target controller, the gateway performs necessary protocol conversion processing on the message to be forwarded according to the bus type and communication protocol requirements of the network segment where the target controller is located. For example, it encapsulates the CAN message into an Ethernet frame format or deconstructs and reassembles the SOME / IP message into a CAN signal matrix. The converted message is then sent to the physical bus through the corresponding bus interface driver layer, so that it is accurately routed to the target controller along the preset communication path, thus completing the cross-domain or cross-network segment forwarding of the message.

[0046] Thus, through the hierarchical management mechanism that divides routing rules into a static, fixed layer and a dynamic, configurable layer, OEMs only need to modify the second routing rule data file to adapt to different vehicle configurations or routing changes resulting from later functional iterations. This eliminates the need to recompile or replace the entire gateway firmware, significantly shortening the change development cycle and reducing software maintenance costs. Since only the first routing rule data file containing static basic routing information needs to be provided when distributing design documents to component suppliers, the second routing rule data file, which involves the complete vehicle topology and signal matrix, can be maintained internally in a closed loop by the OEM, effectively avoiding the risk of leakage of core electronic and electrical architecture information during the supply chain process. At the same time, the above routing matching process is executed in real time during gateway operation without restarting the device or interrupting bus communication, ensuring the real-time performance and stability of the vehicle network.

[0047] In some embodiments, determining the second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier includes: determining the routing rule storage area of ​​the packet to be forwarded based on the source controller identifier, wherein the routing rule storage area is used to store the second routing rule data file corresponding to the packet to be forwarded; wherein the second routing rule data file is written to the corresponding routing rule storage area via the cloud.

[0048] Specifically, based on the source controller identifier extracted from the message, a search is performed in a preset storage area mapping table to determine the routing rule storage area bound to the source controller. This routing rule storage area is an independent logical partition or physical address range divided in the gateway's erasable storage area, specifically used to store the second routing rule data file associated with the source controller.

[0049] It should be noted that the second routing rule data file stored in the routing rule storage area is not permanently written to the gateway at the factory, but rather supports remote flashing and updating by the OEM through a cloud platform during vehicle use. Specifically, when a routing rule change is required, the OEM can generate an updated second routing rule data file in the cloud and send the data to the gateway through a secure channel established by the vehicle networking module. After receiving the data, the gateway writes it to the corresponding routing rule storage area, overwriting the original file or adding new entries. This allows for dynamic adjustment of the routing strategy without requiring the vehicle to be returned to the factory, hardware disassembly, or recompilation of the underlying firmware. Through the aforementioned cloud flashing mechanism, this application achieves flexible remote configuration of routing rules, significantly reducing the cost and time overhead of routing changes caused by differences in vehicle configuration or later functional iterations.

[0050] Furthermore, the second routing rule data files corresponding to different source controllers are independent of each other in physical or logical storage space. When the OEM needs to update or modify the routing policy of a specific controller, it only needs to perform a targeted write operation on the storage area bound to that controller, without having to traverse or modify the routing rule data of other unrelated controllers. In this way, the amount of data written involved in a single configuration change is effectively reduced, the time consumption and bandwidth usage of the cloud write process are shortened, and on the other hand, it also avoids the potential risk of accidentally affecting the existing communication links of other controllers due to local routing rule modifications, thereby improving the operational security, configuration accuracy and overall system stability during the dynamic adjustment of routing policies.

[0051] In some embodiments, writing the second routing rule data file to the corresponding routing rule storage area via the cloud includes: obtaining the routing rule table of the vehicle gateway, wherein each routing rule in the routing rule table includes a source controller identifier; grouping the routing rules in the routing rule table based on the source controller identifier to obtain multiple routing rule subsets; mapping the addresses of the multiple routing rule subsets respectively using a preset script based on the base address of the routing rule storage area corresponding to the source controller identifier, so as to convert each routing rule subset into a corresponding second routing rule data file; and writing each second routing rule data file to the corresponding routing rule storage area based on the base address of the routing rule storage area corresponding to the source controller identifier.

[0052] Specifically, the cloud first obtains the complete gateway routing rule table from the vehicle manufacturer's routing configuration database. Each routing rule record in the routing rule table contains a source controller identifier field, which is used to identify the source of the message to which the rule applies.

[0053] Subsequently, the cloud performs a grouping operation on all records in the routing rule table based on the source controller identifier, and gathers all routing rules belonging to the same source controller into a routing rule subset, thereby forming multiple independent routing rule subsets corresponding to each source controller.

[0054] Based on this, the cloud obtains the base address of the routing rule storage area pre-allocated to each source controller, and uses a preset automated script tool to traverse each routing rule subset. Based on the corresponding base address, it performs address offset calculation and memory mapping on each routing rule in the subset, thereby converting each routing rule subset into a second routing rule data file format that can be directly recognized and loaded by the gateway hardware.

[0055] Finally, the cloud uses a secure data channel established with the vehicle gateway to write each of the generated second routing rule data files to the routing rule storage area that matches its source controller identifier, thus completing the partitioned remote deployment of the routing rules.

[0056] In this way, this application achieves efficient classification management and accurate distribution of routing rules, which improves configuration efficiency while effectively avoiding the risks of data redundancy and accidental overwriting caused by full routing table flushing.

[0057] In some embodiments, each routing rule further includes a message identifier, and before grouping the set of routing rules based on the source controller identifier, the method further includes: sorting the routing rules in the set of routing rules according to the numerical value of the message identifier.

[0058] Specifically, before performing grouping operations on the routing rule set based on the source controller identifier, the cloud first sorts all routing rule records in the routing rule set in ascending or descending order according to the numerical value of the packet identifier in each routing rule. By introducing a pre-sorting mechanism based on the numerical value of the packet identifier, each subset of routing rules formed after grouping is in an ordered state. When the gateway subsequently traverses and matches in the second routing rule data file using the packet identifier as an index, it can quickly locate the target entry using efficient search algorithms such as binary search, without having to compare all records in the subset one by one. This significantly reduces the average query time complexity and processor computational overhead of the routing matching process, effectively improving the gateway's packet forwarding throughput and real-time response performance under high load conditions.

[0059] In some embodiments, each routing rule further includes a target controller identifier and a message frame format. The routing rules in the second routing rule data file are stored in a preset storage format, wherein the preset storage format includes the low-order bits of the message identifier, the high-order bits of the message identifier, the target controller identifier, and the message frame format.

[0060] Specifically, within the second routing rule data file, each routing rule is stored in a compact arrangement according to a preset storage format. This preset storage format sequentially includes the low-order byte of the packet identifier, the high-order byte of the packet identifier, the target controller identifier, and the packet frame format field. The preset storage format is shown in Table 1. Table 1

[0061] By splitting the packet identifier into low-order and high-order bytes for separate storage, the gateway can prioritize fast comparison of the low-order bytes of the packet identifier during route lookup. If a match fails, there is no need to read the subsequent high-order bytes and the complete table entry content, thereby effectively reducing the number of memory accesses and data read bandwidth consumption during the matching process. Simultaneously, storing the target controller identifier and frame format information adjacently in the same table entry structure allows the gateway to simultaneously obtain the forwarding target address and the required frame encapsulation method in a single continuous read operation once a packet identifier match is successful, without initiating secondary addressing or cross-regional reads, further improving route lookup efficiency and the real-time performance of packet forwarding responses.

[0062] In some embodiments, the method further includes: in response to a message identifier matching a first routing rule data file, querying the first routing rule data file based on the message identifier to determine the routing rule for the message to be forwarded; determining the target controller corresponding to the message to be forwarded based on the routing rule for the message to be forwarded, and routing the message to be forwarded to the target controller.

[0063] Specifically, if the gateway confirms through query and comparison that the extracted message identifier has been recorded in the first routing rule data file that is permanently stored, that is, if the message identifier matches the first routing rule data file, the gateway directly uses the message identifier as a query index to retrieve the corresponding routing rule entry in the first routing rule data file, reads the routing action parameters such as the target controller address, forwarding port and transmission protocol type defined in the entry, and determines the target controller to which the message to be forwarded needs to be delivered.

[0064] Subsequently, the gateway performs necessary protocol conversion and frame format encapsulation on the message to be forwarded according to the bus type and communication protocol requirements of the network segment where the target controller is located, and sends the message to the physical bus through the corresponding bus interface driver layer, so that it is accurately routed to the target controller along the preset communication path, thus completing the cross-domain or cross-network segment forwarding of the message.

[0065] Since the first routing rule data file is permanently stored in the gateway's read-only storage area, the matching and forwarding process does not need to call or traverse the second routing rule data file. Therefore, it has the shortest query path and the fastest forwarding response speed, making it suitable for transmission scenarios of basic control messages or safety-critical messages with high real-time requirements.

[0066] In some embodiments, determining the target controller corresponding to the packet to be forwarded based on the routing rules of the packet to be forwarded, and routing the packet to be forwarded to the target controller, further includes: in response to the failure of routing the packet to be forwarded, writing the routing rules of the packet to be forwarded into the corresponding subset of routing rules based on the source controller identifier of the packet to be forwarded.

[0067] Specifically, during the process of forwarding the message to be forwarded to the target controller according to the routing rules obtained from the first routing rule data file, if the gateway detects that the forwarding operation has failed, such as due to abnormal conditions such as the target controller not responding, the target bus being busy and timeout, or the target address being unreachable, the gateway generates the corresponding routing failure error message, records the error message in the status log or fault code storage area inside the gateway, and can optionally report it to the vehicle central domain controller or synchronize it to the cloud platform through the vehicle networking module, so that the vehicle manufacturer can perform fault diagnosis and location.

[0068] At the same time, the gateway triggers the routing failure handling process, extracts the source controller identifier of the packet to be forwarded, and locates the routing rule storage area bound to it based on the source controller identifier. Then, it dynamically writes the routing rule corresponding to this forwarding failure, which originates from the first routing rule data file, into the routing rule subset in the storage area.

[0069] When a subsequent packet with the same message identifier from the same source controller is received, the gateway can directly retrieve the written routing rule from the second routing rule data file and execute the forwarding. This eliminates the need to repeatedly go through the step-by-step matching and fallback query process from the first to the second routing rule data file, effectively shortening the routing decision path for duplicate packets and improving forwarding efficiency. Simultaneously, the dual mechanism of error logging triggered by routing failure and self-writing of rules provides OEMs with traceable fault diagnosis data and enables the gateway to possess a certain degree of self-learning and adaptive optimization capabilities for routing strategies. It can dynamically adjust and expand the content of the second routing rule data file according to the actual network communication status, further enhancing the system's robustness and intelligence in complex vehicular network environments.

[0070] As a specific example, the gateway routing method in this application embodiment may further include the following steps: First, the definition and maintenance of routing rules are completed using spreadsheet software. Users only need to fill in the routing relationships in the spreadsheet. The information fields included in the spreadsheet at least cover the message identifier, source controller name, target controller name, and message frame format type, where the message frame format type is used to distinguish between standard frames and extended frames. It is worth noting that the target controller field supports multiple controller identifiers, meaning that this application supports forwarding the same message to multiple target channels simultaneously to meet one-to-many broadcast or multicast communication needs. After the spreadsheet is filled in and the preset script tool is executed, the script tool will automatically parse the spreadsheet content and generate a hexadecimal format file or a Motorola S-Log format file, which is the target image file used for subsequent flashing operations.

[0071] Secondly, when the routing relationships recorded in the spreadsheet change or are added, the user only needs to update the spreadsheet content and run the aforementioned preset script tool again to regenerate the updated hexadecimal or S-record format file. During operation, the script tool reads the message identifier and target channel information corresponding to each receiving channel, and sorts the routing rules for each channel in ascending order according to the value of the message identifier for quick retrieval during subsequent code execution. Simultaneously, the script tool counts the total number of routing rules contained in each channel and stores this count in the first byte of the corresponding storage area for that channel. Each routing rule is stored compactly in a fixed length of four bytes, with the following storage format: the first byte stores the lower eight bits of the message identifier, the second byte stores the higher eight bits of the message identifier, the third byte stores the target controller identifier, and the fourth byte stores the message frame format type identifier. To minimize the time spent matching message identifiers during code execution, this application allocates a dedicated storage space for each receiving channel in the address allocation of the read-only storage area. This space is used to store the routing rule set corresponding to that channel separately, so that the code can directly locate the base address of the corresponding storage area based on the receiving channel identifier during runtime, effectively compressing the search range.

[0072] Furthermore, the generated hexadecimal or S-record format files can be directly flashed to the controller's read-only memory via the Joint Test Action Group's debugging interface. Simultaneously, considering that external debugging interfaces are typically unavailable in real-world vehicle environments, this application further supports remote flashing via the Unified Diagnostic Service Protocol. To achieve non-intrusive upgrades without modifying the vehicle controller's bootloader code, the script tool also features a file fusion function. This function can merge a hexadecimal or S-record format file containing routing table data with the controller's application firmware file into a single, complete image file. This merged image file can then be directly written to the controller via the Unified Diagnostic Service Protocol's standard flashing process, thereby completing online updates of the routing table data without altering the existing controller software architecture or flashing procedure.

[0073] Finally, during the controller operation phase, after the controller receives a CAN message through the bus interface, it will call the CAN layer interface function via the interrupt service routine and obtain the complete message information received by the controller through the callback function. The gateway first matches and locates the base address of the read-only memory area corresponding to the channel based on the source controller identifier of the message. Then, within this address range, it searches the routing table using the message identifier as a lookup index to determine whether the current message needs to be forwarded across channels. If the search result indicates a successful match, the message is forwarded to all specified target channels in sequence according to the target channel information recorded in the routing rules, thus completing the entire routing and forwarding process.

[0074] Given the large number of routing packets in real-world vehicular network environments, a naive search method that performs a full traversal of the routing table for each received packet would inevitably lead to excessively long query times, resulting in routing packet backlog and frame drops, severely impacting communication real-time performance and reliability. Therefore, this application proposes a multi-level accelerated routing table lookup scheme, which maximizes retrieval efficiency through the following steps: First, rapid location of the storage area based on the source controller identifier. This application pre-plans and allocates a fixed read-only storage address range for each receiving channel to store the routing table data corresponding to that channel. This allows the gateway to quickly calculate the corresponding routing table storage base address based on the source controller identifier of the packet after receiving it, thereby compressing the retrieval scope from the global routing table to the local routing table corresponding to a single channel, significantly reducing the number of table entries that need to be traversed in a single query.

[0075] Second, rapid elimination based on sorting range boundaries. Since the script tool sorts the packet identifiers in each channel's routing table in ascending order of value during the image file generation stage, the code can first determine whether the received packet's identifier falls within the closed interval formed by the minimum and maximum packet identifiers in the channel's routing table when performing a query. If the packet identifier is less than the minimum identifier or greater than the maximum identifier, it is determined that the current packet does not need to be routed and forwarded, and the query process is exited directly, thus avoiding unnecessary deep search overhead.

[0076] Third, fast matching based on the binary search algorithm. Once the packet identifier of the received packet is determined to be within the valid identifier range of the routing table, the code uses the binary search algorithm to perform target matching in the sorted set of routing rules. Each iteration of the binary search algorithm halves the current search interval, resulting in a logarithmic time complexity. Taking a single-channel routing table containing one hundred routing rules as an example, the binary search algorithm requires at most five iterations to locate the target rule. Compared to the traversal method, which requires an average of fifty comparisons and a worst-case of one hundred comparisons, the retrieval efficiency is significantly improved by orders of magnitude, effectively ensuring the real-time forwarding capability and zero-frame-loss transmission reliability of routing packets under high load conditions.

[0077] In summary, compared with the shortcomings of related technologies, such as the long development cycle, slow response to requirements, and easy leakage of architectural information caused by the static pre-compilation and offline solidification mode of vehicle gateway routing tables, this application has achieved significant technical breakthroughs and beneficial effects by constructing a dynamic routing architecture with hierarchical management of the first routing rule data file and the second routing rule data file.

[0078] On the one hand, traditional vehicle gateway routing management is relatively rigid. When faced with routing change requirements due to differences in vehicle configurations or functional iterations, it often requires complex processes such as re-integration and compilation, software upgrades, and multiple rounds of supplier collaborative testing, with change cycles lasting weeks or even months. This application, however, stores a flexibly configurable second routing rule data file in the gateway's erasable and writable storage area and grants cloud-based write access. This allows OEMs to update routing policies online simply by modifying the routing rule configuration file, without recompiling the underlying firmware or replacing the gateway hardware. This reduces the change cycle from weeks to minutes, significantly improving software development efficiency and demand response agility, making it suitable for R&D scenarios requiring rapid software iteration and verification. Furthermore, since routing table updates do not involve code compilation, gateways with variable routing capabilities can quickly adapt to any vehicle platform, effectively accelerating vehicle development and significantly reducing repetitive development costs caused by differences in vehicle configurations.

[0079] On the other hand, this application uses source controller identifiers to partition and isolate the storage of routing rules and perform targeted writing, so that when the vehicle manufacturer distributes design documents to the supplier, it only needs to provide the first routing rule data file containing static basic routing information. The second routing rule data file, which involves the complete topology and signal matrix of the vehicle, can be maintained in a closed loop by the vehicle manufacturer. The vehicle manufacturer does not need to release the complete vehicle routing table information to the component supplier, which effectively avoids the risk of leakage of core electronic and electrical architecture information in the process of supply chain flow from the source, and significantly improves the level of information security protection and confidentiality management capabilities.

[0080] Furthermore, the variable-route vehicle gateway in this application supports protocol conversion and data interaction for multiple communication protocols and interface types. It can uniformly parse and convert data from devices of different bus types and communication protocols, enabling vehicles to connect to a wider variety of external devices and sensors, further enhancing the device compatibility and architectural scalability of the vehicle's electronic and electrical systems. Facing the continuous evolution of intelligent connected vehicle technology and the emergence of new communication protocols and devices, the routing rule self-learning and dynamic update capabilities of this application allow the gateway to quickly adapt to the access requirements of new technologies and devices, ensuring that vehicles maintain technological advancement and market competitiveness over a longer period.

[0081] In summary, the variable routing table vehicle gateway provided in this application has achieved significant technological advancements in multiple dimensions, including improving network efficiency and routing flexibility, enhancing system compatibility and scalability, strengthening information security protection capabilities, and shortening the R&D cycle and reducing development costs. As an important component of intelligent connected vehicle technology innovation, the introduction of dynamic routing management capabilities in this application will powerfully promote the optimization and upgrading of vehicle internal network architecture, shorten the automotive software development cycle, accelerate the market application and promotion of intelligent connected vehicles, and provide solid technical support for the continuous evolution of the automotive industry towards intelligence and connectivity. It represents one of the important directions for the development of intelligent connected vehicle technology.

[0082] Corresponding to the above embodiments, this application also proposes a gateway routing device.

[0083] Reference Figure 2 The gateway routing device 200 includes: a parsing module 210, a first determining module 220, a second determining module 230, and a routing module 240.

[0084] The parsing module 210 receives and parses the message to be forwarded to extract its message identifier. The first determining module 220, in response to a mismatch between the message identifier and the first routing rule data file, extracts the source controller identifier of the message to be forwarded and determines the corresponding second routing rule data file based on the source controller identifier. The second determining module 230, in response to a match between the message identifier and the second routing rule data file, queries the second routing rule data file based on the message identifier to determine the routing rule for the message to be forwarded. The routing module 240, based on the routing rule for the message to be forwarded, determines the target controller corresponding to the message to be forwarded and routes the message to the target controller.

[0085] According to one embodiment of this application, the first determining module 220 is specifically used to determine the routing rule storage area of ​​the packet to be forwarded based on the source controller identifier, wherein the routing rule storage area is used to store the second routing rule data file corresponding to the packet to be forwarded; wherein the second routing rule data file is written to the corresponding routing rule storage area through the cloud.

[0086] According to one embodiment of this application, a routing rule table of a vehicle gateway is obtained, wherein each routing rule in the routing rule table includes a source controller identifier; the routing rules in the routing rule table are grouped based on the source controller identifier to obtain multiple routing rule subsets; based on the base address of the routing rule storage area corresponding to the source controller identifier, a preset script is used to perform address mapping on the multiple routing rule subsets respectively, so as to convert each routing rule subset into a corresponding second routing rule data file; based on the base address of the routing rule storage area corresponding to the source controller identifier, each second routing rule data file is written to the corresponding routing rule storage area.

[0087] According to one embodiment of this application, each routing rule also includes a message identifier. Before grouping the routing rule set based on the source controller identifier, the routing rules in the routing rule set are sorted according to the numerical value of the message identifier.

[0088] According to one embodiment of this application, each routing rule also includes a target controller identifier and a message frame format. The routing rules in the second routing rule data file are stored in a preset storage format, wherein the preset storage format includes the low bit of the message identifier, the high bit of the message identifier, the target controller identifier, and the message frame format.

[0089] According to one embodiment of this application, in response to a match between a message identifier and a first routing rule data file, the first routing rule data file is queried based on the message identifier to determine the routing rule for the message to be forwarded; based on the routing rule for the message to be forwarded, the target controller corresponding to the message to be forwarded is determined, and the message to be forwarded is routed to the target controller.

[0090] According to one embodiment of this application, in response to a failure to route a packet to be forwarded, the routing rules for the packet to be forwarded are written into a corresponding subset of routing rules based on the source controller identifier of the packet to be forwarded.

[0091] It should be noted that the above explanation of the embodiments and beneficial effects of the gateway routing method also applies to the gateway routing device of the embodiments of this application. To avoid redundancy, it will not be elaborated in detail here.

[0092] Corresponding to the above embodiments, this application also proposes a computer-readable storage medium.

[0093] The computer-readable storage medium of this application stores a gateway routing program thereon, which, when executed by a processor, implements the aforementioned gateway routing method.

[0094] It should be noted that the above explanation of the embodiments and beneficial effects of the gateway routing method also applies to the computer-readable storage medium of the embodiments of this application. To avoid redundancy, it will not be elaborated in detail here.

[0095] Corresponding to the above embodiments, this application also proposes an electronic device.

[0096] See Figure 3 As shown, the electronic device 300 of this application includes a memory 310, a processor 320, and a gateway routing program stored in the memory 310 and capable of running on the processor 320. When the processor executes the gateway routing program, it implements the aforementioned gateway routing method.

[0097] It should be noted that the above explanation of the embodiments and beneficial effects of the gateway routing method also applies to the electronic devices in the embodiments of this application. To avoid redundancy, they will not be elaborated in detail here.

[0098] Corresponding to the above embodiments, this application also proposes a vehicle.

[0099] See Figure 4 As shown, the vehicle 30 of this application includes the aforementioned electronic device 300.

[0100] It should be noted that the above explanation of the embodiments and beneficial effects of the electronic device also applies to the vehicle in the embodiments of this application, and will not be elaborated in detail here to avoid redundancy.

[0101] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0102] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0103] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0104] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0105] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0106] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A gateway routing method, characterized in that, include: Receive the message to be forwarded and parse the message to be forwarded to extract the message identifier of the message to be forwarded; In response to the mismatch between the packet identifier and the first routing rule data file, the source controller identifier of the packet to be forwarded is extracted, and the second routing rule data file corresponding to the packet to be forwarded is determined based on the source controller identifier; In response to the message identifier matching the second routing rule data file, the second routing rule data file is queried based on the message identifier to determine the routing rule for the message to be forwarded; Based on the routing rules of the message to be forwarded, the target controller corresponding to the message to be forwarded is determined, and the message to be forwarded is routed to the target controller.

2. The gateway routing method according to claim 1, characterized in that, The step of determining the second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier includes: The routing rule storage area for the packet to be forwarded is determined based on the source controller identifier, wherein the routing rule storage area is used to store the second routing rule data file corresponding to the packet to be forwarded; Specifically, the second routing rule data file is written to the corresponding routing rule storage area via the cloud.

3. The gateway routing method according to claim 2, characterized in that, The step of writing the second routing rule data file to the corresponding routing rule storage area via the cloud includes: Obtain the routing rule table of the vehicle gateway, wherein each routing rule in the routing rule table includes a source controller identifier; The routing rules in the routing rule table are grouped based on the source controller identifier to obtain multiple subsets of routing rules; Based on the base address of the routing rule storage area corresponding to the source controller identifier, the multiple routing rule subsets are address mapped by a preset script to convert each routing rule subset into a corresponding second routing rule data file; Based on the base address of the routing rule storage area corresponding to the source controller identifier, each of the second routing rule data files is written to the corresponding routing rule storage area.

4. The gateway routing method according to claim 3, characterized in that, Each routing rule also includes a message identifier, and before grouping the set of routing rules based on the source controller identifier, it also includes: The routing rules in the routing rule set are sorted according to the numerical value of the message identifier.

5. The gateway routing method according to claim 4, characterized in that, Each routing rule also includes a target controller identifier and a message frame format. The routing rules in the second routing rule data file are stored according to a preset storage format, wherein the preset storage format includes the low-order bits of the message identifier, the high-order bits of the message identifier, the target controller identifier, and the message frame format.

6. The gateway routing method according to claim 1, characterized in that, Also includes: In response to the message identifier matching the first routing rule data file, the first routing rule data file is queried based on the message identifier to determine the routing rule for the message to be forwarded; Based on the routing rules of the message to be forwarded, the target controller corresponding to the message to be forwarded is determined, and the message to be forwarded is routed to the target controller.

7. The gateway routing method according to claim 6, characterized in that, Based on the routing rules of the message to be forwarded, the target controller corresponding to the message to be forwarded is determined, and the message to be forwarded is routed to the target controller, which further includes: In response to the failure of routing the packet to be forwarded, the routing rules of the packet to be forwarded are written into the corresponding subset of routing rules based on the source controller identifier of the packet to be forwarded.

8. A gateway routing device, characterized in that, include: The parsing module is used to receive the message to be forwarded and parse the message to be forwarded in order to extract the message identifier of the message to be forwarded; The first determining module is configured to, in response to a mismatch between the packet identifier and the first routing rule data file, extract the source controller identifier of the packet to be forwarded, and determine the second routing rule data file corresponding to the packet to be forwarded based on the source controller identifier; The second determining module is configured to, in response to the message identifier matching the second routing rule data file, query the second routing rule data file based on the message identifier to determine the routing rule for the message to be forwarded; The routing module is used to determine the target controller corresponding to the packet to be forwarded based on the routing rules of the packet to be forwarded, and to route the packet to be forwarded to the target controller.

9. A computer-readable storage medium, characterized in that, It stores a gateway routing program, which, when executed by the processor, implements the gateway routing method according to any one of claims 1-7.

10. An electronic device, characterized in that, The system includes a memory, a processor, and a gateway routing program stored in the memory and capable of running on the processor. When the processor executes the gateway routing program, it implements the gateway routing method according to any one of claims 1-7.

Images