CN115390753A - Data processing method of vehicle, ECU, vehicle and storage medium - Google Patents
Data processing method of vehicle, ECU, vehicle and storage medium Download PDFInfo
- Publication number
- CN115390753A CN115390753A CN202210963299.5A CN202210963299A CN115390753A CN 115390753 A CN115390753 A CN 115390753A CN 202210963299 A CN202210963299 A CN 202210963299A CN 115390753 A CN115390753 A CN 115390753A
- Authority
- CN
- China
- Prior art keywords
- program
- driving function
- ecu
- memory
- programming language
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0608—Saving storage space on storage systems
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Software Systems (AREA)
- Mechanical Engineering (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a data processing method of a vehicle, an ECU, the vehicle and a storage medium, wherein the ECU designed for executing a driving function comprises an internal memory and an external memory. And storing programs corresponding to the driving functions with different operation requirements into different storage devices. The trigger request indicates that there is a target driving function to be executed by the ECU. If the target driving function is the first driving function, the first program can be directly read from the memory to run, and repeated loading of the first program from the external memory is avoided. And if the target driving function is the second driving function, loading the second program from the external memory to the memory, so that the occupation of the memory space of the memory is avoided. On one hand, the driving function corresponding program is stored by additionally arranging the external memory, so that the driving function which can be realized by the ECU is enriched. On the other hand, according to the operation requirements of different driving functions, programs corresponding to different driving functions are stored in different storage devices, and storage space can be reasonably arranged.
Description
Technical Field
The present application relates to the field of vehicle technologies, and in particular, to a data processing method for a vehicle, an ECU, a vehicle, and a storage medium.
Background
An Electronic Control Unit (ECU) of an automobile is also called a "driving computer" of the automobile, and uses data of various sensors and buses to judge a vehicle state and obtain the intention of a driver, and controls the automobile to run through an actuator and realize other various running functions. The ECU usually includes a processor and a memory, and in the related art, limited by the performance of the processor and the capacity of the memory, the ECU often has difficulty in implementing complex driving functions and meeting the increasing functional requirements of the vehicle.
Disclosure of Invention
The application provides a data processing method of a vehicle, an ECU, a vehicle and a storage medium.
According to a first aspect of the present application, a data processing method for a vehicle is provided, which is applied to an ECU mounted on the vehicle, the ECU being configured to execute driving functions, the driving functions including at least one first driving function and at least one second driving function; the operating requirement of the first driving function in the vehicle is higher than the operating requirement of the second driving function; the ECU comprises an internal memory and an external memory; the memory stores at least one first program capable of realizing the first driving function; the external memory stores at least one second program capable of realizing the second driving function, and the method comprises the following steps:
receiving trigger requests from other ECUs and/or external equipment in the vehicle, wherein the trigger requests indicate target driving functions to be executed by the ECUs;
if the target driving function is the first driving function, running a first program corresponding to the target driving function stored in the memory;
and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external memory, and operating the second program.
In some examples, the first program is written using a first programming language and the second program is written using a second programming language; the ECU is capable of recognizing instructions in a program written in the first programming language and is incapable of recognizing instructions in a program written in the second programming language;
before the executing the second program, further comprising:
and converting the instructions in the second program into instructions written by using the first programming language by using a prestored instruction conversion relation between the second programming language and the first programming language.
In some examples, the external memory stores a plurality of second programs, at least a portion of which are written in a first programming language and another portion of which are written in a second programming language; the ECU is capable of recognizing instructions in a program written in the first programming language and is incapable of recognizing instructions in a program written in the second programming language;
before the running of the second program corresponding to the target driving function, the method further comprises:
and if the second program is determined to be written by using a second programming language based on the flag bit preset in the second program and/or the extension name of the program file, converting the instruction in the second program into the instruction written by using the first programming language by using the pre-stored instruction conversion relation between the second programming language and the first programming language.
In some examples, the ECU is installed with an analysis component for converting the instructions in the second program using a pre-stored instruction conversion relationship between the second programming language and the first programming language;
wherein the instruction complexity of the second program that can be analyzed by the analysis component is in a positive correlation with the operating resources of the ECU.
In some examples, the operation requirement of the driving function is positively correlated with the operation frequency of the program corresponding to the driving function, the real-time requirement of the driving function, and/or the correlation between the driving function and the driving behavior.
In some examples, the ECU records the number of times the first program is executed and the number of times the second program is executed;
the method further comprises the following steps:
after a preset updating period is reached, acquiring the operating frequency of each first program in a preset time period according to the operating times of the first programs, and acquiring the operating frequency of each second program in the preset time period according to the operating times of the second programs;
and updating the storage positions of the first programs and the second programs based on the running frequency, so that the running frequency of the first programs stored in the internal memory is higher than that of the second programs stored in the external memory.
In some examples, the second program is deleted from the memory after a preset condition is met; the preset conditions include: the remaining available capacity of the memory is less than or equal to a preset capacity, a trigger request for the target driving function is not received within a preset time period, the utilization rate of the memory is greater than or equal to a preset ratio, a second program corresponding to the target driving function has been run for a preset time, or the second program corresponding to the target driving function has been run and ended.
In some examples, the ECU is equipped with a server; the other ECU is provided with a client; the reliability degree of the ECU provided with the server is higher than that of the ECU provided with the client, and the performance of the ECU provided with the server is lower than that of the ECU provided with the client;
the server and the client communicate based on SOME/IP protocol, the method also includes:
and the service end broadcasts the driving function to a client based on the SOME/IP protocol so that the client sends the trigger request for subscribing the driving function to the service end.
In some examples, the ECU includes an MCU and an external memory, and the internal memory is an internal memory of the MCU; the MCU and the external memory are independent chips and are integrated on the same circuit board.
According to a second aspect of the present application, there is provided an ECU to be mounted in a vehicle, the ECU being configured to perform driving functions including at least one first driving function and at least one second driving function; the operating requirement of the first driving function in the vehicle is higher than the operating requirement of the second driving function; the ECU includes:
the external memory stores at least one second program capable of realizing the second driving function;
the MCU comprises a processor and a memory; the memory stores at least one first program capable of realizing a first driving function; the processor is configured to:
receiving a trigger request from other ECUs and/or external equipment, wherein the trigger request indicates a target driving function to be executed by the ECU;
if the target driving function is the first driving function, running a first program corresponding to the target driving function stored in the memory;
and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external storage, and operating the second program.
According to a third aspect of the present application, there is provided a vehicle comprising:
a vehicle body;
the power assembly is used for driving the vehicle to move;
and an ECU as described in the second aspect above.
According to a fourth aspect of the present application, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed, perform the method of any of the first aspects described above.
The technical scheme provided by the embodiment of the application can have the following beneficial effects:
the application provides a data processing method of a vehicle, an ECU, the vehicle and a storage medium, wherein the ECU for executing a driving function is designed to comprise an internal memory and an external memory. And storing programs corresponding to the driving functions with different operation requirements into different storage devices. The first program capable of realizing the first driving function with high operation demand is stored in the memory, and the second program capable of realizing the second driving function with low operation demand is stored in the external memory. In addition, the trigger requests from other ECUs and/or external devices indicate that there is a target driving function to be executed by the ECU. If the target driving function is the first driving function, the first program can be directly read from the memory to run, and repeated loading of the first program from the external memory is avoided. And if the target driving function is the second driving function, loading the second program from the external memory to the memory, so that the occupation of the memory space of the memory is avoided. On one hand, the program corresponding to the driving function is stored by additionally arranging the external memory, the driving function realized by the ECU is not limited by the memory performance any more, and the driving function realized by the ECU is enriched. On the other hand, according to the operation requirements of different driving functions, programs corresponding to different driving functions are stored in different storage devices, and storage space can be reasonably arranged.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this application, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.
FIG. 1 is a flow chart illustrating a data processing method for a vehicle according to one embodiment of the present application.
FIG. 2 is a schematic diagram of an ECU according to one embodiment of the present application.
Fig. 3A is a flow chart illustrating a data processing method of a vehicle according to another embodiment of the present application.
FIG. 3B is a flow chart illustrating a method for data processing for a vehicle according to another embodiment of the present application.
FIG. 3C is a flow chart illustrating a method for data processing for a vehicle according to another embodiment of the present application.
FIG. 4 is a flow chart illustrating a method for data processing for a vehicle according to another embodiment of the present application.
FIG. 5 is a schematic illustration of a vehicle according to an embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if," as used herein, may be interpreted as "at \8230; \8230when" or "when 8230; \823030when" or "in response to a determination," depending on the context.
An Electronic Control Unit (ECU) of an automobile is also called a "driving computer" of the automobile, and uses data of various sensors and buses to judge a vehicle state and obtain the intention of a driver, and controls the automobile to run through an actuator and realize other various running functions. The ECU typically includes a processor and memory, with embedded software running. In the related art, limited by the performance of the processor and the capacity of the memory, the ECU often has difficulty in implementing complex driving functions and meeting the increasing functional requirements of the vehicle.
In view of the above, the present application proposes a data processing method for a vehicle, which is applied to an ECU mounted on the vehicle. The ECU is used for executing the driving functions, and the driving functions comprise at least one first driving function and at least one second driving function. Wherein the operating requirement of the first driving function in the vehicle is higher than the operating requirement of the second driving function. The ECU comprises an internal memory and an external memory. At least one first program capable of realizing the first driving function is stored in the memory; at least one second program capable of realizing the second driving function is stored in the external memory. In addition, the ECU also comprises a processor which can be respectively connected with the internal memory and the external memory. The method described above may thus be executed by a processor in an ECU, specifically including the steps as shown in fig. 1:
step 110: receiving trigger requests from other ECUs and/or external equipment, wherein the trigger requests indicate target driving functions to be executed by the ECUs;
step 120: if the target driving function is the first driving function, operating a first program corresponding to the target driving function stored in the memory;
step 130: and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external memory, and operating the second program.
The ECU may implement a variety of driving functions including, but not limited to, a driving data forwarding function, a radar control function, an ECU diagnostic function, an OTA (Over-the-Air Technology) upgrade function, a vehicle speed detection function, a power inquiry function, a range inquiry function, and the like. According to the running requirements of the running functions on the vehicle, the running functions can be divided into a first running function with high running requirements and a second running function with low running requirements. The first driving function may include one or more than one, and the second driving function may also include one or more than one. One driving function may correspond to one program, that is, the driving function may be realized by operating one program. One driving function may correspond to a plurality of programs, that is, the driving function can be realized by operating a plurality of programs.
The operational requirements of the driving function may be positively correlated with one or more of the following parameters:
(1) And running frequency of a program corresponding to the running function. The higher the running frequency of the program corresponding to the driving function is, the higher the running requirement of the driving function is. As an example, the operational requirements of a periodically operating vehicle function are higher than the operational requirements of an occasionally operating vehicle function. For example, vehicles are often equipped with external sensors, such as lidar, to detect the presence of obstacles in the vehicle surroundings. The ECU needs to periodically sense the environmental obstacles. For another example, when an OTA upgrade instruction is received, the ECU may run an upgrade program to complete the upgrade of the vehicle system and/or portions of software, such upgrade program being run infrequently. Therefore, the operation requirement of the upgrade function is lower than the operation requirement of the environmental obstacle sensing function.
(2) Real-time performance requirements of the driving function. The higher the real-time performance requirement of the driving function, the higher the operation requirement thereof. For example, the real-time requirement of the in-vehicle temperature adjustment function is lower than the real-time requirement of the environmental obstacle sensing function, and therefore, the operation requirement of the in-vehicle temperature adjustment function is lower than the operation requirement of the environmental obstacle sensing function.
(3) The degree of correlation between the driving function and the driving behavior. The higher the correlation between the driving function and the driving behavior, the higher the operating requirement of the driving function. For example, the correlation between the music playing function and the driving behavior is low, and the correlation between the function of acquiring the current running speed and the driving behavior is high. The operation requirement of the music playing function is lower than that of the traveling speed acquiring function.
In order to enrich the driving function which can be realized by the ECU, the ECU comprises a processor, an internal memory and an external memory. The processor is respectively connected with the internal memory and the external memory. The external memory may include one or more. In some embodiments, as shown in FIG. 2, the ECU200 includes an MCU 210 and an external memory 220. The MCU (micro controller Unit, also called Single Chip Microcomputer) or a Single Chip Microcomputer (MCU) is a Chip-level computer formed by appropriately reducing the frequency and specification of a Central Processing Unit (CPU) and integrating components such as a memory (memory) on a Single Chip. As shown in fig. 2, the MCU 210 includes a CPU 211 and a memory 212. As an example, the data processing method of the vehicle described above may be executed by the CPU 211. The memory 212 is a built-in memory of the MCU 210. The MCU 210 and the external memory 220 are separate chips and integrated on the same circuit board.
Programs corresponding to the driving functions with different operation requirements are stored in different storage devices. A first program capable of realizing a first traveling function with a high operation demand is stored in a memory, and a second program capable of realizing a second traveling function with a low operation demand is stored in an external memory. When the trigger request is received, the trigger request indicates that the target driving function to be executed by the ECU exists. And determining whether to acquire the corresponding program from the memory or the storage device according to the trigger request.
In some embodiments, the ECU may have a mapping relationship between the driving function and a storage location of the corresponding program stored in advance. The mapping relationship may be stored in the memory and/or the external storage. The ECU may determine a target storage location of a program corresponding to the target driving function from the mapping relationship according to the target driving function indicated by the trigger request, and acquire and run the corresponding program from the target storage location to execute the target driving function.
In other embodiments, the trigger request may also carry storage location information of a program corresponding to the target driving function. The ECU can acquire and run a program from the target storage location based on the storage location information to perform the target traveling function.
As an example, the storage location information may indicate a memory in which a program corresponding to the target driving function is located. Meanwhile, the trigger request also carries a program name corresponding to the target driving function, so that the ECU can traverse the memory indicated by the storage position information and inquire the program corresponding to the target driving function according to the program name carried by the trigger request.
As another example, the storage location information may indicate a storage address of a program corresponding to the target driving function in the internal memory or the external storage. In this way, the ECU can directly acquire the corresponding program from the storage address indicated by the storage location information.
If the target driving function is the first driving function, the first program can be directly read from the memory to run, and repeated loading of the first program from the external memory is avoided. And if the target driving function is the second driving function, loading the second program from the external memory to the memory, and reading the second program from the memory to run, so that the occupation of the memory space of the memory is avoided.
Therefore, based on the design, on one hand, the program corresponding to the driving function is stored by additionally arranging the external memory, the driving function realized by the ECU is not limited by the memory performance any more, and the driving function realized by the ECU is enriched and expanded. On the other hand, according to the operation requirements of different driving functions, programs corresponding to different driving functions are stored in different storage devices, and storage space can be reasonably arranged. Meanwhile, from the aspect of software upgrading, a technician can replace or add a new second program corresponding to the driving function in the external memory at any time according to actual needs without rewriting embedded software written in the memory of the ECU. So that unlimited driving functions are realized in limited hardware resources.
After the second program is executed, in order to save the storage space of the memory, in some embodiments, the second program may be deleted from the memory. In other embodiments, the second program may be deleted from the memory after one or more of the following preset conditions are met:
(1) The remaining available capacity of the memory is less than or equal to the preset capacity.
(2) The utilization rate of the memory is greater than or equal to a preset ratio.
In order to ensure the running of the program, the memory needs to be left with enough capacity to store intermediate data generated during the running of the program. Therefore, when the remaining available capacity of the memory is less than or equal to the preset capacity, or the utilization rate of the memory is greater than or equal to the preset ratio, the second program may be deleted from the memory in order not to affect the program operation.
(3) And a trigger request aiming at the target driving function is not received within a preset time period. In order to avoid repeatedly loading the second program from the external memory, the second program may wait for a predetermined period of time after the second program finishes running. If the trigger request for the target driving function is not received within the preset time period, the second program may be deleted from the memory in consideration of saving the memory storage space. Wherein the preset time period can be determined by the skilled person according to the actual need.
(4) The second program has been running for a preset length of time. For example, the second program may be a program for performing data acquisition. If the vehicle only needs a certain amount of collected data for subsequent calculation processing, the operating duration of the second program may be set. And when the second program runs for the preset time length, deleting the second program from the memory to terminate the running of the second program.
The programs may be written in different programming languages. Different programming languages have different writing capability requirements for program developers. However, the CPU often can only recognize instructions in a program written in a specific programming language (e.g., C language), and if the program is written in another programming language, the program needs to be converted before running the program. Or, the CPU stores therein a CPU instruction set, which is a hard program for optimizing and guiding the CPU operation. Each instruction of a system or program requires the CPU to complete according to the CPU instruction set. If the CPU instruction set is not used when the program is written, the program needs to be converted first.
In some embodiments, the first program and the second program are both written in a first programming language. Wherein the ECU is capable of recognizing instructions in a program written in a first programming language. That is, the ECU can recognize the instructions in the first program and the second program, so the ECU can directly run the first program and the second program. As an example, the first programming language may be C language, and instructions in a program written using C language are instructions in the CPU instruction set, so that the CPU in the ECU can directly execute. The second program may be written by a program developer directly using the first programming language, or may be parsed into the second program written by the first programming language through a script parser after the program developer is written by using another programming language, such as a scripting language.
As such, the step 130 may include the steps shown in fig. 3A:
step 310: if the target driving function is the second driving function, traversing the external memory according to the program name of the second program carried by the trigger request to check whether the second program exists;
if yes, go to step 321; if not, go to step 322.
Step 321: allocating a memory, and loading a second program to the allocated memory from the external memory;
step 322: and outputting error prompt information.
Step 340: operating a second program in the memory;
step 350: and after the second program is operated, deleting the second program from the memory to release the memory.
In some embodiments, the first program is written using a first programming language; the second program is written using a second programming language. Wherein the ECU is capable of recognizing instructions in a program written in a first programming language and is incapable of recognizing instructions in a program written in a second programming language. That is, the ECU is able to recognize the instructions in the first program and is unable to recognize the instructions in the second program. The ECU can directly run the first program. Wherein the second programming language may be a scripting language. In this way, before the second program is run, the instructions in the second program can be converted into the instructions written in the first programming language by using the prestored instruction conversion relationship between the second programming language and the first programming language. That is, the instructions in the second program are converted into instructions in the CPU instruction set so that the CPU in the ECU can recognize the converted instructions in the second program.
As such, the step 130 may include the steps shown in fig. 3B:
step 310: if the target driving function is the second driving function, traversing the external memory according to the program name of the second program carried by the trigger request to check whether the second program exists;
if yes, go to step 321; if not, go to step 322.
Step 321: allocating a memory, and loading a second program to the allocated memory from the external memory;
step 322: and outputting error prompt information.
Step 330: converting the instructions in the second program into instructions written by using the first programming language by using a prestored instruction conversion relation between the second programming language and the first programming language;
step 340: operating a second program in the memory;
step 350: and after the second program is operated, deleting the second program from the memory to release the memory.
In other embodiments, the external memory stores a plurality of second programs, and at least a portion of the plurality of second programs are written in a first programming language and another portion of the plurality of second programs are written in a second programming language. Wherein the ECU is capable of recognizing instructions in a program written in a first programming language and is incapable of recognizing instructions in a program written in a second programming language. In this manner, the ECU also needs to determine whether the second program can be identified before running the second program.
In some embodiments, the determination may be made through a flag bit preset in the second program and/or an extension of the program file. As an example, a flag may be set in the second program to identify whether the second program is written in the second programming language. For example, if the flag bit is 1, it represents that the second program is written in the first programming language and thus can be identified; if the flag bit is 0, it means that the second program is not written in the first programming language, but in the second programming language, and cannot be recognized. As an example, a second program written in a first programming language has a corresponding program file in a certain set format. According to the extension name of the program file, the format of the program file can be determined, so that whether the corresponding second program is written by using the first programming language or not is judged. Therefore, whether the second program is written in the second programming language can be determined by the extension of the program file of the second program. And if the extension name of the program file of the second program is the preset extension name, judging that the second program is written by using the first programming language, otherwise, writing by using the second programming language instead of the first programming language.
When it is determined that the second program is written using the second programming language based on the flag bit and/or the extension of the program file preset in the second program, before the second program is run, the instruction in the second program may be converted into the instruction written using the first programming language by using the instruction conversion relationship between the second pre-stored programming language and the first programming language. That is, the instructions in the second program are converted into instructions in the CPU instruction set so that the CPU in the ECU can recognize the converted instructions in the second program.
As such, the step 130 may include the steps shown in fig. 3C:
step 310: if the target driving function is the second driving function, traversing the external memory according to the program name of the second program carried by the trigger request to check whether the second program exists;
if yes, go to step 321; if not, go to step 322.
Step 321: allocating a memory, and loading a second program to the allocated memory from the external memory;
step 322: and outputting error prompt information.
Step 331: determining whether a second program is written by using a second programming language or not based on a flag bit preset in the second program and/or an extension name of a program file;
if yes, go to step 332; if not, go to step 340.
Step 332: converting the instructions in the second program into instructions written by using the first programming language by using a prestored instruction conversion relation between the second programming language and the first programming language;
step 340: operating a second program in the memory;
step 350: and after the second program is operated, deleting the second program from the memory to release the memory.
According to either of the embodiments shown in fig. 3B and 3C, an analysis module is further mounted in the ECU. For example, the memory of the ECU also stores an analysis component. The analysis component is used for converting the instruction in the second program by using the instruction conversion relation between the pre-stored second programming language and the first programming language. The analysis component can analyze the instruction complexity of the second program and the running resources of the ECU to form a positive correlation relationship. As examples, the parsing component may be a lua parser, a java virtual machine, or the like. The parsing component is stored in a memory, the size of the memory storage space determining the size of the parsing component used. Therefore, the corresponding parsing component needs to be selected according to the size of the memory storage space. If the parsing component is too small, the parsing function may be so poor that some of the instructions of the second program cannot be converted by the parsing component. If the analysis component is too large, a large storage space is occupied, and the loading of the second program and the running of the program are influenced. Those skilled in the art may select a corresponding script parser as a parsing component according to the size of the memory storage space, which is not limited herein.
The foregoing provides different embodiments of the second program when written using the first programming language and/or the second programming language. Taking the first programming language as C language and the second programming language as other scripting languages as examples, C language is relatively complex and has high requirements on technical personnel. Accordingly, other scripting languages are relatively simple and relatively easy to master. Therefore, if the second program stored in the external memory is written by using other scripting languages and is loaded into the memory, the instructions in the second program are converted into instructions written by using the C language, so that the cost of program development and maintenance can be effectively reduced, and the requirements of technicians writing the second program are also reduced.
In some embodiments, the present application provides a data processing method for a vehicle, further including the steps shown in fig. 4:
step 410: after a preset updating period is reached, acquiring the operating frequency of each first program in a preset time period according to the operating times of the first programs, and acquiring the operating frequency of each second program in the preset time period according to the operating times of the second programs;
step 420: and updating the storage positions of the first programs and the second programs based on the running frequency, so that the running frequency of the first programs stored in the internal memory is higher than that of the second programs stored in the external memory.
The update period can be set by a person skilled in the art according to actual needs, for example, one week, one month, and the like. The running times of each first program and each second program may be stored in the memory or may be stored in the external memory. According to the running times of each program, the running frequency of each program can be determined respectively.
Subsequently, the storage locations of the respective programs may be updated based on the operating frequency of the respective programs in the update cycle. As an example, a plurality of programs may be selected from high to low according to the operation frequency according to the size of the memory storage space, and stored in the memory as the first program. The remaining available space of the memory after the first program is stored is larger than a preset threshold value, so that the memory has enough remaining available space for loading the second program and for running the program. The remaining programs are stored in the external memory as the second program.
As another example, after the operating frequencies of the respective first programs and the respective second programs are determined, it is determined whether there is an operating frequency of the second program that is greater than the operating frequency of the first program. If so, storing the target first program with the operating frequency less than the operating frequency of the second program into the external memory as the second program, and storing the target second program with the operating frequency greater than the operating frequency of the target first program into the memory as the first program.
If the target second program is written using the second programming language, the target second program may be converted by the instruction conversion method provided in the above embodiment and then stored in the memory. In this embodiment, by periodically updating the storage location of each program, a reasonable arrangement of storage space can be ensured. The method and the device avoid repeated loading of the program with high running frequency from the external memory and avoid occupation of the program with low running frequency on the memory.
Regarding the sender of the trigger request, in some embodiments, the trigger request may be sent by an external device to the ECU. The external device may be an ECU detector, for example. When the ECU detector is connected with the vehicle, a detection request can be sent to the ECU, and the detection request carries a detection program to be executed by the ECU, so that the ECU loads the detection program from the external memory to the memory and operates.
In some embodiments, multiple ECUs onboard the vehicle are used to perform different driving functions. The main frequency of the CPU of part of the ECUs is higher, the number of cores (core) included in the CPU is larger, correspondingly, the memory capacity of the ECU is also larger, and the performance of the ECU is higher. Correspondingly, on one hand, because a high-performance CPU and a large-capacity memory use a relatively new chip manufacturing process and a relatively new packaging process, the safety level of the chip is relatively low and cannot meet the requirement of the high safety level of the vehicle gauge, and on the other hand, compared with the chip with the high safety level, the chip is more prone to failure, the corresponding driving function is caused to fail, and the reliability of the high-performance ECU is relatively low. In order to ensure the normal running of the vehicle, some key running functions are often executed by the ECU with higher safety level. However, for an ECU with a higher security level, in order to ensure the reliability and prevent failure, the used chip usually adopts a more mature chip manufacturing process and packaging process, but the performance of such an ECU is relatively low. Therefore, the ECU with high safety level has high reliability, but the ECU has poor performance and can only realize less key driving functions.
In the application, the ECU is additionally provided with the external memory, so that the ECU with high safety level can realize more driving functions. The improved ECU has high safety level and better stability, and can realize more driving functions. In this way, by utilizing the characteristic that the ECU with the high security level has high stability, the ECU with the high security level and high stability but low performance can be loaded with the server, and the other ECU with the low security level and low stability but high performance can be loaded with the client. The server and the client communicate based on the SOME/IP protocol. SOME/IP is called Scalable Service-organized MiddlewarE over IP, SOME/IP protocol is located at application layer in OSI seven-layer network structure, and is a Service-Oriented telescopic MiddlewarE. Alternatively, the server and the client communicate with a Service Discovery protocol (SD) based on the SOME/IP protocol. The SOME/IP protocol and the service discovery protocol are called SOME/IP-SD protocol for short.
The server is used for providing services, and the client is used for calling the services. By using an SOA (Service-Oriented Architecture) provided by the vehicle-mounted Ethernet, the Service end can broadcast the driving function which can be realized by the Service end in a vehicle body network through an SOME/IP protocol or an SOME/IP-SD protocol. After receiving the published message, the client in the vehicle body network can send a trigger request for subscribing the driving function to the server according to the self requirement, so that the server provides the corresponding driving function to the subscriber.
The application provides a data processing method of a vehicle, an ECU, the vehicle and a storage medium, wherein the ECU for executing a driving function is designed to comprise an internal memory and an external memory. And storing programs corresponding to the driving functions with different operation requirements into different storage devices. The first program capable of realizing the first driving function with high operation demand is stored in the memory, and the second program capable of realizing the second driving function with low operation demand is stored in the external memory. In addition, the trigger requests from other ECUs and/or external devices indicate that there is a target driving function to be executed by the ECU. If the target driving function is the first driving function, the first program can be directly read from the memory to run, and repeated loading of the first program from the external memory is avoided. And if the target driving function is the second driving function, loading the second program from the external memory to the memory, so that the occupation of the memory space of the memory is avoided. On one hand, the program corresponding to the driving function is stored by additionally arranging the external memory, the driving function realized by the ECU is not limited by the memory performance any more, and the driving function realized by the ECU is enriched. On the other hand, according to the operation requirements of different driving functions, programs corresponding to different driving functions are stored in different storage devices, and storage space can be reasonably arranged.
Based on a data processing method of a vehicle according to any of the above embodiments, the present application further provides an ECU200 as shown in fig. 2. The ECU200 is mounted on a vehicle and executes a driving function. The driving functions comprise at least one first driving function and at least one second driving function, and the operation requirement of the first driving function in the vehicle is higher than that of the second driving function. As shown in fig. 2, the ECU200 includes an MCU 210 and an external memory 220. The external memory 220 stores at least one second program capable of implementing a second driving function; the MCU 210 includes a processor (e.g., CPU 211) and a memory 212. The memory 212 stores at least one first program that can implement a first driving function, and the processor is configured to execute any one of the data processing methods described above.
Illustratively, the processor includes a CPU11, the CPU 211 is configured to:
receiving a trigger request from other ECUs and/or external equipment, wherein the trigger request indicates a target driving function to be executed by the ECU;
if the target driving function is the first driving function, operating a first program corresponding to the target driving function stored in the memory;
and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external memory, and operating the second program.
Of course, the Processor may be other types of processors, such as a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or an off-the-shelf Programmable Gate Array (FPGA), etc.
Based on the data processing method of the vehicle according to any of the embodiments, the present application further provides a schematic structural diagram of a vehicle as shown in fig. 5. As in fig. 5, at a hardware level, the vehicle includes a body; the power assembly is used for driving the vehicle to move; and an ECU as shown in fig. 2. As shown in fig. 2, the ECU200 includes an MCU 210 and an external memory 220. The external memory 220 stores at least one second program capable of implementing the second driving function; the MCU 210 includes a CPU (processor) 211 and a memory 212. The memory 212 stores at least one first program that can implement the first traveling function, and the CPU 211 is configured to:
receiving a trigger request from other ECUs and/or external equipment, wherein the trigger request indicates a target driving function to be executed by the ECU;
if the target driving function is the first driving function, operating a first program corresponding to the target driving function stored in the memory;
and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external memory, and operating the second program.
Based on the data processing method of the vehicle according to any of the embodiments, the present application further provides a computer program product comprising a computer program, which when executed by a processor is operable to perform the method according to any of the embodiments.
Based on the data processing method of the vehicle according to any of the embodiments, the present application further provides a computer storage medium, where a computer program is stored, and the computer program, when executed by a processor, is operable to perform the method according to any of the embodiments.
The foregoing description of specific embodiments of the present application has been presented. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
Claims (12)
1. A data processing method of a vehicle is characterized in that the method is applied to an ECU (electronic control unit) mounted on the vehicle, and the ECU is used for executing driving functions, wherein the driving functions comprise at least one first driving function and at least one second driving function; the operating requirement of the first driving function in the vehicle is higher than the operating requirement of the second driving function; the ECU comprises an internal memory and an external memory; the memory stores at least one first program capable of realizing the first driving function; the external memory stores at least one second program capable of realizing the second driving function, and the method comprises the following steps:
receiving trigger requests from other ECUs and/or external equipment in the vehicle, wherein the trigger requests indicate target driving functions to be executed by the ECUs;
if the target driving function is the first driving function, operating a first program corresponding to the target driving function stored in the memory;
and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external memory, and operating the second program.
2. The method of claim 1, wherein the first program is written in a first programming language and the second program is written in a second programming language; the ECU is capable of recognizing instructions in a program written in the first programming language and is incapable of recognizing instructions in a program written in the second programming language;
before the executing the second program, further comprising:
and converting the instructions in the second program into instructions written by using the first programming language by using a prestored instruction conversion relation between the second programming language and the first programming language.
3. The method according to claim 1, wherein the external memory stores a plurality of second programs, at least a portion of which are written in a first programming language and another portion of which are written in a second programming language; the ECU is capable of recognizing instructions in a program written in the first programming language and is incapable of recognizing instructions in a program written in the second programming language;
before the running of the second program corresponding to the target driving function, the method further comprises:
and if the second program is determined to be written by using a second programming language based on the flag bit and/or the extension name of the program file preset in the second program, converting the instruction in the second program into the instruction written by using the first programming language by using the pre-stored instruction conversion relation between the second programming language and the first programming language.
4. The method according to claim 2 or 3, wherein the ECU is provided with an analysis component for converting the instructions in the second program by using a prestored instruction conversion relationship between the second programming language and the first programming language;
wherein the instruction complexity of the second program that can be analyzed by the analysis component is in a positive correlation with the operating resources of the ECU.
5. The method according to claim 1, wherein the operation requirement of the driving function is positively correlated with the operation frequency of the program corresponding to the driving function, the real-time requirement of the driving function, and/or the correlation between the driving function and the driving behavior.
6. The method according to claim 1, wherein the ECU records the number of times of operation of the first program and the number of times of operation of the second program;
the method further comprises the following steps:
after a preset updating period is reached, acquiring the operating frequency of each first program in a preset time period according to the operating times of the first programs, and acquiring the operating frequency of each second program in the preset time period according to the operating times of the second programs;
and updating the storage positions of the first programs and the second programs based on the running frequency, so that the running frequency of the first programs stored in the internal memory is higher than that of the second programs stored in the external memory.
7. The method of claim 1, further comprising:
deleting the second program from the memory after a preset condition is met; the preset conditions include: the remaining available capacity of the memory is less than or equal to a preset capacity, a trigger request for the target driving function is not received within a preset time period, the utilization rate of the memory is greater than or equal to a preset ratio, a second program corresponding to the target driving function has been run for a preset time, or the second program corresponding to the target driving function has been run and ended.
8. The method according to claim 1, wherein the ECU is equipped with a server; the other ECU is provided with a client; the reliability of the ECU provided with the server is higher than that of the ECU provided with the client, and the performance of the ECU provided with the server is lower than that of the ECU provided with the client;
the server and the client communicate based on SOME/IP protocol, the method also includes:
and the server broadcasts the driving function to a client based on the SOME/IP protocol so that the client sends the trigger request for subscribing the driving function to the server.
9. The method according to claim 1, wherein the ECU comprises an MCU and an external memory, and the internal memory is the internal memory of the MCU; the MCU and the external memory are independent chips and are integrated on the same circuit board.
10. An ECU mounted in a vehicle, characterized in that the ECU is configured to perform driving functions including at least one first driving function and at least one second driving function; the operating requirement of the first driving function in the vehicle is higher than the operating requirement of the second driving function; the ECU includes:
the external memory stores at least one second program capable of realizing the second driving function;
the MCU comprises a processor and a memory; the memory stores at least one first program capable of realizing a first driving function; the processor is configured to:
receiving trigger requests from other ECUs and/or external equipment, wherein the trigger requests indicate target driving functions to be executed by the ECUs;
if the target driving function is the first driving function, running a first program corresponding to the target driving function stored in the memory;
and if the target driving function is the second driving function, loading a second program corresponding to the target driving function into a memory from the external memory, and operating the second program.
11. A vehicle, characterized in that the vehicle comprises:
a vehicle body;
the power assembly is used for driving the vehicle to move;
and an ECU as claimed in claim 10.
12. A computer-readable storage medium having stored thereon computer instructions which, when executed, perform the method of any of claims 1-9.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210963299.5A CN115390753A (en) | 2022-08-11 | 2022-08-11 | Data processing method of vehicle, ECU, vehicle and storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210963299.5A CN115390753A (en) | 2022-08-11 | 2022-08-11 | Data processing method of vehicle, ECU, vehicle and storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115390753A true CN115390753A (en) | 2022-11-25 |
Family
ID=84117803
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210963299.5A Pending CN115390753A (en) | 2022-08-11 | 2022-08-11 | Data processing method of vehicle, ECU, vehicle and storage medium |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115390753A (en) |
-
2022
- 2022-08-11 CN CN202210963299.5A patent/CN115390753A/en active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109164783B (en) | Vehicle diagnosis method, apparatus, device, and medium | |
CN111459518B (en) | Vehicle ECU upgrading method and system | |
US7584029B2 (en) | Telematics-based vehicle data acquisition architecture | |
US20190193653A1 (en) | On-board update device and on-board update system | |
CN114205386B (en) | Service architecture-oriented vehicle-mounted network communication method | |
EP3761605A1 (en) | Vehicle diagnosis method, related device and system | |
CN107608814A (en) | A kind of method of data sharing, the device and mobile terminal of data sharing | |
US20070106437A1 (en) | Apparatus and method of managing telematics application based on vehicle status | |
CN115167831A (en) | Software integration method and device based on AUTOSAR and use method | |
CN116540666A (en) | Vehicle diagnosis system, method, electronic equipment and medium based on TBOX | |
CN115047792A (en) | ECU control system for motorcycle | |
CN117376265A (en) | Data monitoring and sending method and device, electronic equipment and vehicle | |
CN115390753A (en) | Data processing method of vehicle, ECU, vehicle and storage medium | |
CN113505056A (en) | Vehicle diagnosis method, system, device and storage medium | |
CN116775375A (en) | Method and system for data storage | |
CN116719244A (en) | Simulation test method, system, device, equipment and storage medium | |
JP6695820B2 (en) | Mobile diagnostic system and method | |
US20230105426A1 (en) | In-vehicle information processing apparatus, information processing method, and client program | |
CN115657639A (en) | System, method, device and storage medium for monitoring functions of vehicle-mounted chip | |
KR20220024905A (en) | How to talk to a computer on the vehicle's onboard bus | |
CN114090508A (en) | Method and device for processing data in vehicle | |
RU2816885C2 (en) | Method of interacting with computing device on vehicle on-board bus | |
CN116088485B (en) | Vehicle fault data acquisition system and method and vehicle | |
CN112764986B (en) | Vehicle log acquisition method and device, electronic equipment and vehicle | |
CN114721355A (en) | Fault diagnosis method and device, terminal device and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |