Message distribution method, device and storage medium for electronic control unit in vehicle

Abstract

The application discloses a message distribution method and device of an electronic control unit in a vehicle and a storage medium. The method comprises the following steps: determining a resource description language file of the electronic control unit in the vehicle; obtaining a message dictionary converted from the resource description language file; determining at least one message queue of the electronic control unit from the message dictionary, and storing the message queue in a table file, wherein the length of a message in the message queue in the table file is greater than a length threshold; determining a target message queue in which a to-be-distributed message is located from the table file, and distributing the message in the target message queue. The application solves the technical problem of low efficiency of message distribution of the electronic control unit.

Description

Technical Field

[0001] This invention relates to the field of vehicles, and more specifically, to a message distribution method, apparatus, and storage medium for an electronic control unit in a vehicle. Background Technology

[0002] Currently, during vehicle development, the number of actual scalable service-oriented middleware (SOMEIP) messages can reach thousands. Dedicated software developers are responsible for configuring the scalable service-oriented middleware (SOMEIP Transport Protocol, SOMEIP TP) module based on Internet Protocol (IP) in configuration tools. However, manually checking the length of each message to verify whether it needs SOMEIP TP fragmentation is time-consuming and labor-intensive, especially when the signals are complex or involve a large number of service signals. This results in low efficiency in allocating messages to the electronic control unit.

[0003] There is currently no effective solution to the problem of low efficiency in allocating messages to electronic control units. Summary of the Invention

[0004] This invention provides a message allocation method, apparatus, and storage medium for electronic control units in vehicles, to at least solve the technical problem of low efficiency in allocating messages for electronic control units.

[0005] According to one aspect of the present invention, a message allocation method for an electronic control unit (ECU) in a vehicle is provided. The method may include: determining a resource description language (RPL) file of the ECU; obtaining a message dictionary converted from the RPL file; determining at least one message queue of the ECU from the message dictionary, and storing the message queue in a table file, wherein the length of messages in the message queue in the table file is greater than a length threshold; determining the target message queue of the message to be allocated from the table file, and allocating the message in the target message queue.

[0006] Optionally, obtaining the message dictionary converted from the resource description language file includes: calling a processing function established in the automation tool to receive the resource description language file; and obtaining the message dictionary converted from the resource description language file by the processing function from the automation tool.

[0007] Optionally, determining at least one message queue of the electronic control unit from the message dictionary and storing the at least one message queue in a table file includes: calling a dictionary data structure established in an automation tool, wherein the dictionary data structure contains a key field; obtaining the value field of the message dictionary obtained by the automation tool traversing the message dictionary based on the key field; determining at least one message queue based on the key field and the value field, and storing the at least one message queue in a table file.

[0008] Optionally, determining at least one message queue based on the key field and the value field, and storing at least one message queue in a table file, includes: determining at least one message with a length greater than a length threshold from the message dictionary based on the key field and the value field; storing the message in the message queue to obtain at least one message queue, and storing the message queue in a table file.

[0009] Optionally, the resource description language file may include at least the message name, message length, and service information.

[0010] Optionally, the method further includes: obtaining the allocation result after allocating the message; and verifying the electronic control unit based on the allocation result.

[0011] According to another aspect of the present invention, a message fragmentation device for an electronic control unit in a vehicle is also provided. The device may include: a first determining unit, configured to determine a resource description language file for the electronic control unit in the vehicle; a first acquiring unit, configured to acquire a message dictionary converted from the resource description language file; a second determining unit, configured to determine at least one message queue of the electronic control unit from the message dictionary, and store the message queue in a table file, wherein the length of the messages in the message queue in the table file is greater than a length threshold; and an allocation unit, configured to determine the target message queue where the message to be allocated is located from the table file, and allocate the message in the target message queue.

[0012] According to another aspect of the present invention, a computer-readable storage medium is also provided. The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to execute the message fragmentation method of the electronic control unit in a vehicle according to the present invention.

[0013] According to another aspect of the present invention, a processor is also provided. The processor is used to run a program, wherein the program, when run by the processor, executes the message fragmentation method of the electronic control unit in a vehicle according to the embodiments of the present invention.

[0014] According to another aspect of the present invention, a vehicle is also provided. This vehicle is used to execute the message fragmentation method of the electronic control unit in the vehicle according to the embodiments of the present invention.

[0015] In this embodiment of the invention, a resource description language file of the electronic control unit (ECU) in a vehicle is determined; a message dictionary converted from the resource description language file is obtained; at least one message queue of the ECU is determined from the message dictionary, and the message queue is stored in a table file, wherein the length of the messages in the message queues in the table file is greater than a length threshold; from the table file, the target message queue where the message to be allocated is located is determined, and the message in the target message queue is allocated. In other words, this embodiment of the invention determines the resource description language file of the ECU in the vehicle, inputs the determined resource description language file into an automation tool, obtains the message dictionary converted from the resource description language file from the automation tool, further determines at least one message queue of the ECU from the message dictionary, stores the message queue in a table file, and finally determines the target message queue where the message to be allocated is located from the table file, and allocates the message in the target message queue. This achieves the technical effect of improving the efficiency of message allocation for the ECU and solves the technical problem of low efficiency in message allocation for the ECU. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0017] Figure 1 This is a flowchart of a message allocation method for an electronic control unit in a vehicle according to an embodiment of the present invention;

[0018] Figure 2 This is a flowchart of another message allocation method for an electronic control unit in a vehicle according to an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram of a message distribution device for an electronic control unit in a vehicle according to an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] Example 1

[0023] According to an embodiment of the present invention, an embodiment of a message allocation method for an electronic control unit in a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0024] Figure 1 This is a flowchart of a message allocation method for an electronic control unit in a vehicle according to an embodiment of the present invention, such as... Figure 1 As shown, the method may include the following steps:

[0025] Step S102: Determine the resource description language file of the electronic control unit in the vehicle.

[0026] In the technical solution provided in step S102 of the present invention, the resource description language file of the electronic control unit in the vehicle can be determined. The resource description language file (e.g., an ARXML file) can be a standardized file format for describing the vehicle's electronic system. It can be used to describe information such as software components, interfaces, data types, and network communications within the vehicle's electronic system. This is merely an example and does not impose specific limitations on the content described by the resource description language file.

[0027] Optionally, this embodiment determines the ARXML file of the Electronic Control Unit (ECU) in the vehicle, provided by the network developer. The determined ARXML file contains definitions of the software components of the vehicle's electronic system, which may include at least software modules, interfaces, interface descriptions, data types, and enumeration values. It also describes the communication protocols between software components, which may include at least message and signal definitions and network communication configurations. The ARXML file provides a unified format, enabling software components from different manufacturers to be developed and integrated on different hardware platforms.

[0028] Optionally, ARXML files play a crucial role in vehicle development, serving as the foundation for software component development, integration, and testing. Through ARXML files, developers can clearly understand the interfaces and communication protocols of software components, enabling more efficient and accurate development. Furthermore, ARXML files can also be used for tasks such as automatic code generation, static analysis, and verification.

[0029] Step S104: Obtain the message dictionary converted from the resource description language file.

[0030] In the technical solution provided in step S104 of the present invention, a message dictionary converted from a resource description language file can be obtained. The message dictionary can be a data structure used to store data in key-value pairs. Each key-value pair contains a unique key and a corresponding value. It can be used to represent and transmit structured data. By using the key to access or update the corresponding value, data can be easily manipulated and managed. The message dictionary can also be called a message data dictionary or a message dictionary function.

[0031] Optionally, in this embodiment, the acquired ARXML file is input into an automation tool, which can control the automation tool to filter the message information in the received ARXML file and generate a key-value message data dictionary.

[0032] Step S106: Determine at least one message queue of the electronic control unit from the message dictionary, and store the message queue in a table file.

[0033] In the technical solution provided by step S106 of the present invention, at least one message queue of the electronic control unit can be determined from the generated message dictionary, and the message queue is stored in a table file. The length of the messages in the message queue in the table file is greater than a length threshold. The message queue can be a data structure used to store and manage messages in network communication. Messages can be added to the message queue in a specific order and processed according to the first-in, first-out principle. The table file can be a file storing table data in plain text format. Each row in the table file represents a record, and each field is separated by commas. It can be used to store and exchange structured data and can be parsed and processed by various software and programming languages. For example, it can be a CSV file; this is only an example and no specific limitation is made on the format of the table file. The length threshold can be a threshold set in advance based on the actual length of the message, for example, 65535 bytes; this is only an example and no specific limitation is made on the value of the length threshold.

[0034] Optionally, this embodiment iterates through the acquired message dictionary function, selects messages with a length greater than a length threshold from the message dictionary function, and stores these messages in a message queue. Based on the determined message queue, the determined message queue can be saved one by one to a CSV file, and the CSV file can be output.

[0035] For example, this embodiment iterates through the obtained message dictionary function, selects ten messages with a length greater than 65535 bytes, and stores these ten messages sequentially in two message queues. Furthermore, the two message queues containing the messages are saved one by one to a CSV file, and the CSV file is output.

[0036] Step S108: Determine the target message queue where the message to be assigned is located from the table file, and assign the message in the target message queue.

[0037] In the technical solution provided by step S108 of the present invention, the target message queue where the message to be allocated is located can be determined from the table file, and the messages in the target message queue can be allocated. The target message queue can be the message queue where the message to be allocated is located in the table file.

[0038] Optionally, in this embodiment, a professional developer can obtain a CSV file output by the automation tool. Based on the obtained CSV file, the target packet queue containing the packets to be assigned can be determined. Based on the determined target packet queue, the packets in the target packet queue can be configured, and the packet allocation configuration in the target packet queue can be performed in the configuration tool.

[0039] In steps S102 to S108 of this invention, the resource description language file of the electronic control unit (ECU) in the vehicle is determined; a message dictionary converted from the resource description language file is obtained; at least one message queue of the ECU is determined from the message dictionary and stored in a table file, wherein the length of the messages in the message queues in the table file is greater than a length threshold; the target message queue of the message to be allocated is determined from the table file, and the message in the target message queue is allocated. In other words, this embodiment of the invention determines the resource description language file of the ECU in the vehicle, inputs the determined resource description language file into an automation tool, obtains the message dictionary converted from the resource description language file from the automation tool, further determines at least one message queue of the ECU from the message dictionary and stores the message queue in a table file, and finally determines the target message queue of the message to be allocated from the table file and allocates the message in the target message queue. This achieves the technical effect of improving the efficiency of message allocation for the ECU and solves the technical problem of low efficiency in message allocation for the ECU.

[0040] The method described in this embodiment will be further described below.

[0041] As an optional embodiment, step S104, obtaining the message dictionary converted from the resource description language file, includes: calling a processing function established in the automation tool to receive the resource description language file; and obtaining the message dictionary converted from the resource description language file by the processing function from the automation tool.

[0042] In this embodiment, a processing function established in the automation tool can be invoked. This processing function can receive an input resource description language file. After receiving the resource description language file, the processing function can retrieve the message dictionary obtained by the processing function from the resource description language file, which has been converted by the processing function, from the automation tool.

[0043] Optionally, a processing function for receiving ARXML files can be established in the automation tool. After receiving the ARXML file, the processing function can parse the ARXML file, filter the message information in the ARXML file, and generate a key-value message data dictionary.

[0044] The automation tool provided in this embodiment can automatically filter out packets that exceed the length limit and require SOMEIP TP through ARXML files provided by network developers. It makes full use of the existing development environment and helps network and application developers reduce the time and effort spent and improve development efficiency.

[0045] As an optional embodiment, step S106, determining at least one message queue of the electronic control unit from the message dictionary and storing at least one message queue in a table file, includes: calling a dictionary data structure established in an automation tool, wherein the dictionary data structure contains a key field; obtaining the value field of the message dictionary obtained by the automation tool traversing the message dictionary based on the key field; determining at least one message queue based on the key field and the value field, and storing at least one message queue in a table file.

[0046] In this embodiment, a dictionary data structure established in the automation tool can be invoked. Based on the key fields of the invoked dictionary data structure, the value fields of the message dictionary obtained by the automation tool through traversal can be retrieved. Based on the determined key and value fields of the message dictionary, at least one message queue can be determined. Based on the determined message queues, the determined message queues can be stored one by one in a table file. The dictionary data structure can be a data structure that stores a set of data pairs consisting of keys and values. The dictionary data structure contains key fields and value fields. Each key is unique and can be used to identify the corresponding value. Furthermore, the corresponding value can be quickly accessed and retrieved using a given key.

[0047] Optionally, a key-value dictionary data structure can be created in the automation tool, where the key field contains the name and length of the SOMEIP message. Based on the generated message dictionary, the value fields corresponding to the key fields can be assigned one by one to determine at least one message queue. Based on the determined message queues, the queues can be stored one by one in a CSV file.

[0048] This embodiment can effectively solve the problem of developers manually matching message lengths one by one in configuration tools and determining which messages need to be fragmented by SOMEIP TP.

[0049] As an optional embodiment, determining at least one message queue based on a key field and a value field, and storing at least one message queue in a table file, includes: determining at least one message with a length greater than a length threshold from a message dictionary based on the key field and the value field; storing the message in a message queue to obtain at least one message queue, and storing the message queue in a table file.

[0050] In this embodiment, based on the key and value fields of the defined message dictionary, at least one message with a length greater than a length threshold can be determined from the message dictionary. The determined messages with a length greater than the length threshold can be stored in a message queue, resulting in at least one message queue. Based on the determined message queue, the message queue can be stored in a table file.

[0051] Optionally, based on the generated message dictionary, values ​​can be assigned to the value fields corresponding to the key fields in the message dictionary one by one to identify messages whose length exceeds the length threshold. These messages are then stored in a message queue, resulting in at least one message queue. Based on the identified message queues, they can be stored one by one in a CSV file.

[0052] As an optional implementation, the resource description language file includes at least the message name, message length, and service information.

[0053] In this embodiment, the resource description language file of the electronic control unit in the vehicle may include at least the message name, message length, and service information. The service information may describe various attributes and characteristics of the service signal, and may include at least specific information about the service signal, service groups, and service identifiers.

[0054] Optionally, the defined ARXML file contains specific information about each SOMEIP message, such as at least the message name, length, specific information about the service signal, service group, and service identifier (server IdentityCard, or server ID for short).

[0055] As an optional embodiment, the method further includes: obtaining the allocation result after allocating the message; and verifying the electronic control unit based on the allocation result.

[0056] In this embodiment, the allocation result obtained after the message is allocated can be obtained, and the electronic control unit can be verified based on the obtained allocation result.

[0057] Optionally, in this embodiment, a professional developer configures the SOMEIP TP allocation for the SOMEIP message information that needs to be configured in the CSV file using a configuration tool. The professional developer operates within the configuration tool, verifies the model and checks for errors. If no errors are found, computer language code (e.g., C file code) is generated, and the next steps of code compilation, burning to the ECU, and verifying ECU functionality are carried out.

[0058] This embodiment determines the resource description language file of the electronic control unit (ECU) in the vehicle; obtains a message dictionary converted from the resource description language file; determines at least one message queue of the ECU from the message dictionary and stores the message queue in a table file, wherein the length of the messages in the message queue in the table file is greater than a length threshold; determines the target message queue of the message to be allocated from the table file and allocates the message in the target message queue. In other words, this embodiment determines the resource description language file of the ECU in the vehicle, inputs the determined resource description language file into an automation tool, obtains the message dictionary converted from the resource description language file from the automation tool, further determines at least one message queue of the ECU from the message dictionary and stores the message queue in a table file, and finally determines the target message queue of the message to be allocated from the table file and allocates the message in the target message queue. This achieves the technical effect of improving the efficiency of message allocation for the ECU and solves the technical problem of low efficiency in message allocation for the ECU.

[0059] Example 2

[0060] The technical solutions of the embodiments of the present invention will be illustrated below with reference to preferred embodiments.

[0061] With the development of new software architectures for domain controllers in intelligent vehicles, and the gradual improvement of communication methods for signal and service interaction under Service-Oriented Architecture (SOA), the applications and functions located in domain controllers are also increasing. Consequently, Ethernet communication based on SOA architecture is widely used for communication interaction within domain controller signals, and this signal and service interaction is based on the SOMEIP protocol stack for in-vehicle Ethernet communication. In the automotive field, SOMEIP is a widely used communication protocol for standardized communication within the vehicle and between the vehicle and external systems. SOMEIP provides a flexible and efficient communication framework for communication between different ECUs within a vehicle.

[0062] The main applications and advantages of SOMEIP in vehicles are network communication, service-oriented architecture, responsiveness and scalability, real-time performance and reliability, and security. In terms of network communication, SOMEIP provides a standardized network communication protocol, enabling ECUs in different vehicles to communicate via IP networks. This allows for data exchange and functional integration between different systems and subsystems within the vehicle, promoting interoperability between various modules. Regarding service-oriented architecture, SOMEIP is based on SOA, where different functional modules within the vehicle can provide and use specific services. This architecture allows for modular development and maintenance of vehicle systems and supports dynamic service discovery and configuration. In terms of flexibility and scalability, SOMEIP features flexible message formats and protocol definitions, which can be customized and extended according to specific application needs. It supports different types of data exchange modes, such as request-response and publish-subscribe, to adapt to different communication scenarios and application requirements. Regarding real-time performance and reliability, SOMEIP TP, as part of the SOMEIP protocol stack, provides a reliable message transmission mechanism with functions such as flow control, fragmentation, reassembly, and message serialization to ensure real-time and reliable data delivery, which is crucial for safety-related systems and real-time applications in vehicles. In terms of security, SOMEIP provides several security mechanisms, such as message encryption and signing, to protect the confidentiality and integrity of data, which is crucial for protecting sensitive data in vehicles and preventing unauthorized access.

[0063] By using SOMEIP, vehicle manufacturers and suppliers can achieve standardized communication between different ECUs, simplify the development and integration process, and promote the flexibility and interoperability of vehicle systems. SOMEIP also provides a foundation for advanced functions such as remote vehicle diagnostics, in-vehicle entertainment systems, and intelligent transportation systems. Many SOMEIP messages are long-byte messages, and there is a limit to the length of a SOMEIP message. Therefore, for long messages, SOMEIPTP fragmentation is required. The complete link is as follows: the signal is transmitted from the Run-Time Environment (RTE) to the Basic Software Module (BSW) layer, and then to the processing module (e.g., LdCom). LdCom converts the signal into Transport Protocol Data Units (I-PDUs) and passes them to the Protocol Data Unit Router (PduR) layer. PduR passes the IP User Datagrams (I-PUDS) to the SOMEIP TP layer. The SOMEIP TP layer fragments the long message I-PDUs into Network Protocol Data Units (N-PDUs) and returns them to the PduR layer. The PduR layer then passes the N-PDUs to the definition module (e.g., SoAd).

[0064] In actual development, dedicated software developers are responsible for configuring the SOMEIPTP module in the configuration tool. However, the actual number of SOMEIP messages may be as high as thousands. Software developers have to manually check the length of each message to verify whether the message needs to be fragmented by SOMEIPTP. The manual analysis process consumes a lot of time and effort, especially when the signal is complex or involves a large number of service signals, resulting in low efficiency in allocating messages to the electronic control unit.

[0065] As an alternative example, a method and system for implementing the SOMEIP communication middleware layer based on the SOA architecture of an in-vehicle Android system are proposed. This method uses Android tools (such as Android NDK) to compile the SOMEIP C++ library, calls SOMEIP library functions through the Java Native Interface (JNI interface) and encapsulates them into system services, uses the Android Interface Definition Language (Android AIDL) to call SOMEIP services across processes, uses a Python script to read the basic service information of SOMEIP services from the SOA service interface template file, inputs the basic service information into the SOMEIP communication middleware layer code template file to generate Java code files, and adds the Java code files to the Android project. Since this method does not involve the allocation of messages to the electronic control unit, it suffers from the problem of low efficiency in allocating messages to the electronic control unit.

[0066] As another alternative example, a method, apparatus, vehicle, and medium for invoking enhanced services for vehicle position lights are also proposed. This method obtains at least one invoking parameter for the enhanced services of vehicle position lights, determines the priority of each invoking parameter according to a preset arbitration strategy, and selects the highest-priority first invoking parameter. The enhanced service is then invoked based on the first invoking parameter, or the enhanced service is invoked based on the highest-priority invoking parameter among the first invoking parameter and the second invoking parameter that has already invoked the enhanced service, thereby causing the vehicle position lights to enter the target invoking state. This method solves the problems of resource contention and reduced user experience during enhanced service invoking of vehicle position lights in related technologies. However, since this method does not involve the allocation of messages from the electronic control unit, it suffers from low efficiency in allocating messages from the electronic control unit.

[0067] As another alternative example, a communication architecture and fusion method for the vehicle body domain and cockpit domain based on SOA is proposed. This communication architecture includes an adaptive automotive open system applied to the vehicle body domain and an Android system applied to the cockpit domain. An Ethernet SOMEIP protocol is established between the adaptive automotive open system and the Android system, enabling communication between the vehicle body domain and the cockpit domain through SOMEIP messages. In this method, network information sent by Android can be directly used by the vehicle body network, so that Android does not need to spend a lot of effort to convert vehicle body attributes when interconnecting with the vehicle body network, thereby improving communication efficiency and reducing resource waste. However, since this method does not involve the allocation of messages from the electronic control unit, it suffers from the problem of low efficiency in allocating messages from the electronic control unit.

[0068] To address the aforementioned issues, this embodiment proposes a message allocation method for electronic control units (ECUs) in vehicles. This method effectively solves the problem of developers manually matching and selecting message length information one by one in configuration tools. It implements an automated tool that uses ARXML files provided by network developers to automatically filter out messages whose length exceeds the upper limit and requires fragmentation via SOMEIP TP. By making full use of the existing development environment, this method can help network and application developers reduce time and effort consumption and improve development efficiency. This achieves the technical effect of improving the efficiency of message allocation for ECUs and solves the technical problem of low efficiency in message allocation for ECUs.

[0069] Figure 2 This is a flowchart of another message allocation method for an electronic control unit in a vehicle according to an embodiment of the present invention, such as... Figure 2 As shown, the message allocation method of the electronic control unit in this vehicle may include the following steps:

[0070] Step S201: Determine the resource description language file.

[0071] In step S201 above, the ARXML file of the ECU provided by the network developer can be determined. The determined ARXML file contains specific information about each SOMEIP message, such as the message name, length, specific information about the service signal, service group, and server ID.

[0072] Step S202: Input the resource description language file into the automation tool.

[0073] In step S202 above, the ARXML file can be input into the automation tool.

[0074] Step S203: Create a Python project.

[0075] In step S203 above, the automation tool can be implemented using a computer language (e.g., Python syntax) and a Python project can be created using an integrated development environment (e.g., PyCharm).

[0076] Step S204: Establish the processing function.

[0077] In step S204 above, a processing function for receiving ARXML files can be established in the automation tool. After receiving the ARXML file, the processing function can parse the ARXML file.

[0078] Step S205: Establish the dictionary data structure.

[0079] In step S205 above, a key-value dictionary data structure can be established in the automation tool, where the key field contains the name of the SOMEIP message and the length of the message.

[0080] Step S206: Generate a message dictionary.

[0081] In step S206 above, based on the received ARXML file, the message information in the ARXML file can be filtered and a key-value message data dictionary can be generated.

[0082] Step S207: Determine the message queue based on the message dictionary.

[0083] In step S207 above, based on the generated message dictionary, the value field corresponding to the key field in the message dictionary can be assigned one by one to determine the message with a length greater than the length threshold, and the message with a length greater than the length threshold can be stored in the message queue to determine at least one message queue.

[0084] Step S208: Output a table file based on the message queue.

[0085] In step S208 above, based on the determined message queues, the determined message queues can be stored one by one in a CSV file, and the CSV file can be output.

[0086] Step S209: Obtain the table file.

[0087] In step S209 above, professional developers can obtain the CSV file output by the automation tool.

[0088] Step S210: Configure the message.

[0089] In step S210 above, the professional developers configure the SOMEIP TP allocation for the SOMEIP packets in the configuration tool based on the SOMEIP packet information that needs to be configured in the CSV file.

[0090] Step S211: Proceed with the development work.

[0091] In step S211 above, professional developers operate in the configuration tool to check whether the model check mode has any errors. If there are no errors, C file code is generated, and the next steps of code compilation, burning to ECU, and verifying ECU function are carried out.

[0092] In SOMEIP, message delivery involves communication between multiple components and nodes. The main components and nodes involved can include at least the sending application, the SOMEIP protocol stack, the network, the receiving SOMEIP protocol stack, and the receiving application. Specifically, the sending application generates the SOMEIP message to be transmitted and sends it to the SOMEIP protocol stack. The SOMEIP protocol stack is a software library or module that implements the SOMEIP protocol, responsible for handling functions such as SOMEIP message encapsulation, encoding / decoding, fragmentation, reassembly, and transmission control. The SOMEIP protocol stack then sends the SOMEIP message to the network.

[0093] In terms of networking, SOMEIP messages are transmitted over a network, which can be a Local Area Network (LAN), a Wide Area Network (WAN), or an in-vehicle network, such as Ethernet or Controller Area Network (CAN) in a vehicle. On the receiving end's SOMEIP protocol stack, the stack receives SOMEIP messages from the network, parses and processes them, and is responsible for operations such as fragment reassembly, message decoding, verification, and transmission control. On the receiving end's application end, the application receives messages transmitted by the SOMEIP protocol stack and processes them accordingly, including parsing messages, executing relevant business logic, and generating response messages. Through this transmission link, SOMEIP messages can be sent from the sending application to the receiving application, traversing the SOMEIP protocol stack and the network. All components and nodes in the entire link need to support the SOMEIP protocol and related functions to ensure reliable message transmission and correct processing.

[0094] When SOMEIP TP faces challenges such as exceeding the Maximum Transmission Unit (MTU) limit, limited network bandwidth, priority and flow control, and certain network technology or physical layer limitations, it needs to fragment SOMEIP packets. Fragmentation ensures that large SOMEIP packets can be reliably transmitted and processed over the network, improving communication efficiency and reliability. Specifically, when the packet size exceeds the MTU limit (the maximum data unit that can be transmitted in the network), the packet needs to be fragmented into smaller data blocks suitable for network transmission. With limited network bandwidth, large SOMEIP packets can cause transmission delays or congestion. To avoid this, the packet can be fragmented into multiple smaller blocks to more effectively utilize network resources. Regarding priority and flow control, SOMEIP TP supports different message priorities. In cases of network congestion, high-priority messages may be fragmented for more timely transmission and processing. Furthermore, SOMEIP TP uses flow control mechanisms to manage message sending rates. When the sender's message sending rate exceeds the receiver's message processing capacity, fragmentation helps balance data traffic to avoid message loss or delays. Due to limitations of certain network technologies or physical layers, some network technologies or physical layers may have specific restrictions on packet size. For example, some automotive networks (such as CAN) may have fixed message length limits, requiring large SOMEIP messages to be fragmented into pieces suitable for network transmission.

[0095] This embodiment utilizes Python scripting techniques including string matching and regular expressions. String matching is a basic text processing method used to find specific patterns or substrings within a string. In the context of information matching, string matching can be used to check whether fields in signal tables and service tables match or contain specific values. Regular expressions are powerful pattern matching tools used to find strings in text that conform to specific patterns. In information matching, you can use regular expressions to validate whether fields conform to specific formats, patterns, or rules.

[0096] This embodiment determines the resource description language file of the electronic control unit (ECU) in the vehicle; obtains a message dictionary converted from the resource description language file; determines at least one message queue of the ECU from the message dictionary and stores the message queue in a table file, wherein the length of the messages in the message queue in the table file is greater than a length threshold; determines the target message queue of the message to be allocated from the table file and allocates the message in the target message queue. In other words, this embodiment determines the resource description language file of the ECU in the vehicle, inputs the determined resource description language file into an automation tool, obtains the message dictionary converted from the resource description language file from the automation tool, further determines at least one message queue of the ECU from the message dictionary and stores the message queue in a table file, and finally determines the target message queue of the message to be allocated from the table file and allocates the message in the target message queue. This achieves the technical effect of improving the efficiency of message allocation for the ECU and solves the technical problem of low efficiency in message allocation for the ECU.

[0097] Example 3

[0098] According to embodiments of the present invention, a message distribution device for an electronic control unit in a vehicle is also provided. It should be noted that this message distribution device for an electronic control unit in a vehicle can be used to execute the message distribution method for an electronic control unit in a vehicle as described in Embodiment 1.

[0099] Figure 3 This is a schematic diagram of a message distribution device for an electronic control unit in a vehicle according to an embodiment of the present invention, as shown below. Figure 3 As shown, the message distribution device 300 of the electronic control unit in the vehicle may include: a first determining unit 302, an acquiring unit 304, a second determining unit 306, and a distribution unit 308.

[0100] The first determining unit 302 is used to determine the resource description language file of the electronic control unit in the vehicle.

[0101] The first acquisition unit 304 is used to acquire the message dictionary converted from the resource description language file.

[0102] The second determining unit 306 is used to determine at least one message queue of the electronic control unit from the message dictionary and store the message queue in a table file, wherein the length of the message in the message queue in the table file is greater than a length threshold.

[0103] The allocation unit 308 is used to determine the target message queue where the message to be allocated is located from the table file, and to allocate the message in the target message queue.

[0104] Optionally, the acquisition unit 304 includes: a first calling module, used to call a processing function established in the automation tool to receive the resource description language file; and a first acquisition module, used to acquire from the automation tool the message dictionary obtained by the processing function converting the resource description language file.

[0105] Optionally, the second determining unit 306 includes: a second calling module, used to call a dictionary data structure established in the automation tool, wherein the dictionary data structure contains a key field; a second obtaining module, used to obtain the value field of the message dictionary obtained by the automation tool traversing the message dictionary based on the key field; and a determining module, used to determine at least one message queue based on the key field and the value field, and store the message queue in a table file.

[0106] Optionally, the determining module includes: a first determining submodule, used to determine at least one message with a length greater than a length threshold from the message dictionary based on the key field and the value field; and a second determining submodule, used to store the message in a message queue to obtain at least one message queue, and to store the at least one message queue in a table file.

[0107] Optionally, the resource description language file in the first determining unit 302 includes at least the message name, message length, and service information.

[0108] Optionally, the device further includes: a second acquisition unit for acquiring the allocation result obtained after allocating the message; and a verification unit for verifying the electronic control unit based on the allocation result.

[0109] In this embodiment of the invention, the first determining unit 302 determines the resource description language file of the electronic control unit in the vehicle, the first obtaining unit 304 obtains the message dictionary converted from the resource description language file, the second determining unit 306 determines at least one message queue of the electronic control unit from the message dictionary and stores the message queue in a table file, wherein the length of the message in the message queue in the table file is greater than the length threshold, and the allocation unit 308 determines the target message queue where the message to be allocated is located from the table file and allocates the message in the target message queue. In other words, this embodiment of the invention determines the resource description language file of the electronic control unit in the vehicle, inputs the determined resource description language file into an automation tool, obtains the message dictionary converted from the resource description language file from the automation tool, further determines at least one message queue of the electronic control unit from the message dictionary, stores the message queue in a table file, and finally determines the target message queue of the message to be allocated from the table file and allocates the message in the target message queue. This achieves the technical effect of improving the efficiency of message allocation for the electronic control unit and solves the technical problem of low efficiency in message allocation for the electronic control unit.

[0110] Example 4

[0111] According to an embodiment of the present invention, a computer-readable storage medium is also provided, the storage medium including a stored program, wherein the program executes the message allocation method of the electronic control unit in the vehicle in Embodiment 1.

[0112] Example 5

[0113] According to an embodiment of the present invention, a processor is also provided for running a program, wherein the program is executed by the processor to perform the message allocation method of the electronic control unit in the vehicle in Embodiment 1.

[0114] Example 6

[0115] According to an embodiment of the present invention, a vehicle is also provided, which is used to execute the message allocation method of the electronic control unit in any one of the embodiments of the present invention.

[0116] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0117] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0118] In the several embodiments provided by this invention, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection can be through some interfaces; the indirect coupling or communication connection of units or modules can be electrical or other forms.

[0119] The units defined as separate components may or may not be physically separate. Similarly, the components displayed as units may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0120] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0121] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0122] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A message allocation method for an electronic control unit in a vehicle, characterized in that, include: The resource description language file of the electronic control unit in the vehicle is determined, wherein the resource description language file is an ARXML file; Obtain the message dictionary converted from the resource description language file; From the message dictionary, at least one message queue of the electronic control unit is determined, and the message queue is stored in a table file, wherein the length of the message in the message queue in the table file is greater than a length threshold, the message is a SOMEIP message, and the table file is a CSV file; From the table file, determine the target message queue where the message to be allocated is located, and allocate the message in the target message queue; The process of determining at least one message queue of the electronic control unit from the message dictionary and storing at least one message queue in the table file includes: calling a dictionary data structure established in an automation tool, wherein the dictionary data structure contains a key field, wherein the key field contains information in sequence as the name and length of the message; based on the key field, obtaining the value field of the message dictionary obtained by the automation tool traversing the message dictionary; and based on the key field and the value field, determining at least one message queue and storing at least one message queue in the table file.

2. The method according to claim 1, characterized in that, Obtaining the message dictionary converted from the resource description language file includes: The processing function established in the automation tool is invoked to receive the resource description language file; The message dictionary, obtained from the processing function by converting the resource description language file, is retrieved from the automation tool.

3. The method according to claim 1, characterized in that, Based on the key field and the value field, determining at least one message queue and storing at least one message queue in the table file includes: Based on the key field and the value field, at least one message with a length greater than the length threshold is determined from the message dictionary; the message is stored in the message queue to obtain at least one message queue, and the message queue is stored in the table file.

4. The method according to claim 1, characterized in that, The resource description language file includes at least the message name, the message length, and service information.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the allocation result after allocating the message; Based on the allocation results, the electronic control unit is verified.

6. A message fragmentation device for an electronic control unit in a vehicle, characterized in that, include: The first determining unit is used to determine the resource description language file of the electronic control unit in the vehicle, wherein the resource description language file is an ARXML file; The first acquisition unit is used to acquire the message dictionary converted from the resource description language file; The second determining unit is configured to determine at least one message queue of the electronic control unit from the message dictionary, and store the message queue in a table file, wherein the length of the message in the message queue in the table file is greater than a length threshold, the message is a SOMEIP message, and the table file is a CSV file; The allocation unit is used to determine the target message queue where the message to be allocated is located from the table file, and to allocate the message in the target message queue; The second determining unit is further configured to invoke a dictionary data structure established in the automation tool, wherein the dictionary data structure contains a key field, wherein the key field contains information in sequence as the name and length of the message; based on the key field, obtain the value field of the message dictionary obtained by the automation tool traversing the message dictionary; based on the key field and the value field, determine at least one message queue, and store at least one message queue in the table file.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein when the program is run by a processor, it controls the device in which the storage medium is located to perform the method of any one of claims 1 to 5.

8. A processor, characterized in that, The processor is used to run a program, wherein the program, when run by the processor, performs the method according to any one of claims 1 to 5.

9. A vehicle, characterized in that, The vehicle is used to perform the method according to any one of claims 1 to 5.

Images