Implementation method for compatibility of VCU software with different platform vehicle types
By identifying the hardware specifications of different platform models and achieving software compatibility through the underlying software, application layer software and VCU software, the problems of extended VCU software development cycle and increased costs caused by differences in different platforms and models are solved, and the software is realized on different platforms Seamless adaptability and reliability and stability between models.
Patent Information
- Application Number
- CN202411458963.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-18
- Publication Date
- 2025-02-11
AI Technical Summary
Due to the differences in body structure, power configuration, battery management system, etc. between different platforms and models, the VCU software development cycle has been extended, the cost has increased significantly, and the cost in the test and verification stage remains high.
By identifying the hardware specifications of different platform models, all I/O ports required to support are identified, and software compatibility is achieved through the underlying software, application-level software and VCU software, including configuring I/O ports, building input reception and output driver logic , build internal functional control strategies and fault diagnosis logic.
It realizes seamless adaptive compatibility between VCU software among different platform models, reduces the cost of software adaptability development, testing and verification, and software maintenance and upgrading, ensures the reliability and stability of the software, and avoids software bugs that may be brought into adaptability adjustment. , without additional hardware costs.
Smart Images
Figure CN119414808A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of whole vehicle control, and in particular, the present invention relates to a method for implementing VCU software compatibility with different platform models. Background Art
[0002] As an important part of green transportation, new energy commercial vehicles are gradually penetrating into a wide range of industries such as logistics and transportation, urban public transportation, sanitation operations, cold chain distribution, tourism and emergency rescue. Their efficient operation in different usage scenarios is of great significance to promoting the sustainable development of social economy. In order to meet the diverse needs of these industries, new energy commercial vehicle manufacturers often need to build a diversified product series, covering various types of models from light trucks to heavy trucks, from short-distance distribution to long-distance travel; Due to the differences in body structure, power configuration, battery management system, etc. between different platforms and models, even if the components with the same hardware specifications are used, the vehicle control unit (VCU) needs to be finely adapted. As the "brain" of new energy commercial vehicles, VCU is responsible for coordinating and managing the vehicle's power system, energy system, braking system, safety system and other key subsystems to ensure the safe, efficient and stable operation of the vehicle. Therefore, customized development of VCU software for different platforms and models requires not only an in-depth understanding of the specific needs of each model, but also a large amount of manpower and material resources for software programming, testing and verification, and subsequent software maintenance and upgrades. This situation has led to an extension of the software development cycle and a significant increase in costs. According to industry statistics, software adaptability development work due to differences in vehicle models can account for 30% to 40% of the total development cost, and the cost of the testing and verification phase is even higher, including performance testing, safety testing, durability testing under different working conditions, etc., each of which requires a lot of time and resources. Summary of the invention
[0003] The present invention provides a method for implementing VCU software compatibility with different platform models, which solves the problems raised in the above background technology.
[0004] In order to achieve the above object, the technical solution adopted by the present invention is: a method for implementing VCU software compatibility with different platform models, comprising the following steps: Step S10, identifying all I0 ports required to be supported according to different hardware specifications of different platform models, and transferring to step S20, step S30 and step S40 respectively according to the identification results; Step S20, achieving software compatibility through underlying software; Step S30, achieving software compatibility through application layer software; Step S40, achieving software compatibility through VCU software.
[0005] Preferably, the step S20 specifically includes the following steps: Step S21, performing bottom layer software configuration for all I0 ports; Step S22, fill in the information of all I0 ports into the configuration Excel according to the predefined format, including the port variable name, etc.; Step S23, writing the enabling control logic code of the fault diagnosis in the bottom layer software; Step S24, software integration, script automation extraction of I0 port configuration information; Step S25, the over-control calibration shields the faults diagnosed in the underlying software that are not applicable to the vehicle model.
[0006] Preferably, the step S30 specifically includes the following steps: Step S31, building input receiving and output driving logic for all I0 ports in the application layer software; Step S32, building internal function control strategy logic and application layer fault diagnosis logic for all ports in the application layer software; Step S33, building fault diagnosis enabling control logic in the application layer software; Step S34, software integration; Step S35, the over-control calibration shields the faults diagnosed in the application layer software that are not applicable to the vehicle model.
[0007] Preferably, the step S40 specifically includes the following steps: Step S40, bottom layer software I0 port configuration; application layer software I0 port input reception and output drive logic construction; Step S42, building internal function control strategy logic and application layer fault diagnosis logic in the application layer software; Step S43, developing enabling control logic for fault diagnosis in the bottom layer software and the application layer software respectively; Step S44, software integration; Step S45, overriding the calibration to shield faults in the software that are not applicable to the vehicle model.
[0008] The beneficial effects of adopting the above technical solution are: First, by configuring all ports to be enabled at the underlying software level, the interaction between the hardware IO port and the underlying software is realized. In addition, the enabling control logic of the underlying software diagnostic fault is set in the underlying software, so that the underlying diagnostic fault can also be shielded. In the application layer software, the control logic corresponding to all IO ports is built, including the core control strategy and the application layer fault diagnosis strategy, etc., and finally a version of VCU software is realized that is compatible with different platforms and different hardware specifications, which greatly reduces the software adaptive development work, test verification and software maintenance and upgrade costs, ensures the reliability and stability of the software, avoids the software bugs that may be introduced by adaptive adjustments, and does not require additional hardware costs. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Figure 1 It is a flow chart of the steps of the present invention as a whole; Figure 2 It is a flow chart of the method by which the underlying software achieves software compatibility; Figure 3 It is a flow chart of the method for application layer software to achieve software compatibility; Figure 4 It is the overall flow chart of VCU software to achieve software compatibility with different platform models. DETAILED DESCRIPTION
[0010] The specific implementation methods of the present invention are further explained in detail below by describing the embodiments with reference to the accompanying drawings, with the aim of helping those skilled in the art to have a more complete, accurate and in-depth understanding of the concept and technical solution of the present invention and facilitating its implementation.
[0011] Embodiment 1: Specifically, Figures 1 to 4 As shown, a method for implementing VCU software compatibility with different platform models includes the following steps: Step S10, identifying all I0 ports required to be supported according to different hardware specifications of different platform models, and transferring to step S20, step S30 and step S40 respectively according to the identification results; Step S20, achieving software compatibility through underlying software; Step S30, achieving software compatibility through application layer software; Step S40, achieving software compatibility through VCU software.
[0012] It should be noted that the present invention has successfully invented a software compatibility method that can achieve seamless adaptive compatibility for different hardware by exploring the VCU software compatibility implementation method of extended-range electric vehicle products between different platforms, greatly reducing the cost of software adaptive development, testing and verification, and software maintenance and upgrade, ensuring the reliability and stability of the software, avoiding software bugs that may be introduced by adaptive adjustments, and without increasing additional hardware costs.
[0013] The step S20 specifically includes the following steps: Step S21, performing bottom layer software configuration for all I0 ports; Step S22, fill in the information of all I0 ports into the configuration Excel according to the predefined format, including the port variable name, etc.; Step S23, writing the enabling control logic code of the fault diagnosis in the bottom layer software; Step S24, software integration, script automation extraction of I0 port configuration information; Step S25, the over-control calibration shields the faults diagnosed in the underlying software that are not applicable to the vehicle model.
[0014] It should be noted that by identifying the different input and output ports caused by the hardware differences of different platform models, the types and quantities of IO ports that need to be maximized compatible are extracted, and the underlying software is adapted for the IO ports that need to be maximized supported; The so-called maximizing supported IO ports for underlying software adaptation mentioned above refers to performing port integration configuration on all required input and output ports to preset connections between hardware IO ports and software; The so-called port integration configuration mentioned above means that before the embedded software is integrated, all the hardware IO port information that needs to be enabled is written to the carrier through a certain carrier, including the port PIN number, the software variable name connected to the software, etc.; The so-called information carrier mentioned above is in the form of Excel. Each column of Excel needs to indicate the corresponding port information, including the port PIN number, whether the port information is enabled, Enable for enabled and Disable for disabled, port type, including AI, DI, DO, PWMI and PWMO, etc., digital input high and low side information, high effective input and low effective input, etc., variable name, i.e. the software and hardware bridge, and the data type of the variable name, including floating point, Boolean and integer, etc.; The so-called carrier information mentioned above needs to be extracted to help the underlying software establish a mapping relationship with the application layer software. By writing an automated script tool, all relevant information in Excel can be read and key information can be automatically written into the underlying software code. When the software is integrated to generate HEX, one-click automatic extraction and generation can be performed.
[0015] In addition, a bridge for information interaction is built between software and hardware through software variable names. The input port is responsible for collecting analog, digital or PWM signals, and passing the collected results to the application layer software through the software variable name mapped by the port, providing input for the application layer control logic of the embedded software. The output port has power positive, power ground, low-effective drive, high-effective drive and PWM drive signals. The application layer control logic of the embedded software calculates the result to be driven in real time, and passes the result to the underlying software through the software variable name mapped by the port. The underlying software associates the hardware driver layer to perform physical hardware driving.
[0016] The step S30 specifically includes the following steps: Step S31, building input receiving and output driving logic for all I0 ports in the application layer software; Step S32, building internal function control strategy logic and application layer fault diagnosis logic for all ports in the application layer software; Step S33, building fault diagnosis enabling control logic in the application layer software; Step S34, software integration; Step S35, the over-control calibration shields the faults diagnosed in the application layer software that are not applicable to the vehicle model.
[0017] It should be noted that after all required IO ports are configured, the application layer software also needs to match all IO ports that are enabled for maximum compatibility. Therefore, the application layer software needs to synchronously establish the corresponding input and output control logic to connect the hardware information channel with the software logic channel. In addition, the entry or exit variable name of the software logic channel that matches the hardware port one by one is the variable name described in step 5. If it is an input port, the input variable of the application layer software signal flow is the input port variable name. If it is an output port, the output variable of the application layer software signal flow is the output port variable name. The connection entity at the boundary between hardware and software is the variable name filled in the configuration table. Furthermore, after the application layer software completes the variable name data corresponding to the receiving port and before sending the variable name data corresponding to the sending port, it needs to have corresponding control logic to perform operations to complete the control of the entire vehicle function. Therefore, the corresponding internal core control logic needs to be built after the signal is received and before the signal is sent to implement the vehicle function control strategy.
[0018] The step S40 specifically includes the following steps: Step S40, bottom layer software I0 port configuration; application layer software I0 port input reception and output drive logic construction; Step S42, building internal function control strategy logic and application layer fault diagnosis logic in the application layer software; Step S43, developing enabling control logic for fault diagnosis in the bottom layer software and the application layer software respectively; Step S44, software integration; Step S45, overriding the calibration to shield faults in the software that are not applicable to the vehicle model.
[0019] It should be noted that in order to achieve software compatibility, the control logic of the application layer software needs to cover all hardware IO ports. When different hardware of different models needs to enable corresponding ports, the application layer software has been preset and the logic path is switched by setting the calibration quantity to complete the connection between the hardware IO port and the software control logic. For fault diagnosis of different hardware IO ports, it is necessary to decide whether to enable fault diagnosis of corresponding IO ports and fault diagnosis related to internal control logic according to the IO ports enabled by different vehicle models. For faults reported by application layer diagnosis, the override enable calibration quantity can be directly set in the application layer software to control whether fault diagnosis is enabled. For IO port faults diagnosed by the underlying software, such as short power faults, short ground faults or open circuit faults, some faults are directly diagnosed by the diagnostic chip to decide whether to report or cure, which cannot be controlled in the application layer software. If the enabling of the underlying software fault diagnosis cannot be controlled, such as the enabling of short-to-ground or open-circuit faults, then when a certain vehicle model needs to enable the port and another vehicle model does not need to enable the port, the PIN wireless beam connection here will falsely report a short-to-ground or open-circuit fault and affect the vehicle control. Therefore, in order to avoid this situation, it is necessary to add the logic code of the fault enable control in the handwritten code of the underlying software, and complete the enabling control of the underlying diagnostic fault by setting the underlying calibration quantity. In this way, the enabling control of the fault diagnosis between different IO ports corresponding to different vehicle models can be perfectly realized. If fault monitoring is required, the fault diagnosis logic should be enabled, otherwise it can be directly shielded by overriding the control; In order to achieve compatibility of fault diagnosis, the fault diagnosis logic of the application layer software also needs to cover the diagnosis of all hardware IO ports and related control logic. In this way, for the software compatibility of IO ports, first, IO configuration compatibility is required to achieve compatibility of underlying software, second, application layer control logic compatibility is required, including input and output and control strategy, and third, fault diagnosis compatibility is required. The above fault diagnosis requires the interaction between the bottom layer software and the application layer software. The fault information is also filled in the fault information list. According to the standard format, it includes the fault name, starting with DFC, PCODE, the storage priority of the fault in the memory, high, mid and low, etc., the fault debounce time, including the confirmation time of the fault report and the confirmation time of the fault recovery, whether the fault is latched, and the fault level. Finally, fault information is also automatically extracted with one click through automated scripts during software integration, and the fault information is automatically written into the underlying software, and automatically extracted and generated with one click when the software integration generates HEX. Example 2
[0020] Assume that the brake switch of the A platform model is a dual-way switch, one is normally open and the other is normally closed, while the brake switch of the B model has only one way, and it is normally closed. Then, for the acquisition of the brake switch signal, two voltage-type analog inputs need to be set up for the A model, and the control logic of the application layer software also needs to match the electrical properties of the dual-way switch. The B model only needs to use one of the dual-way switches of the A model. The control logic of the application layer software also needs to calibrate the control logic path to only judge the port variable of the PIN corresponding to one brake switch of the B model. At the same time, inapplicable faults are shielded in the underlying software and application layer software. In this way, the software logic is adaptively compatible with different hardware specifications of different platform models. There is no need to redevelop the software and perform software testing and verification, as well as subsequent maintenance and upgrades. One version of the software adaptive calibration can be compatible with different hardware configurations of different platform models.
[0021] The same is true for the output port. For example, the condensing fan of model A has two gears, high speed and low speed, while the condensing fan of model B has a single gear. The VCU controls the relay to close and drive the fan through a low effective drive signal. The condensing fan speed request message signal sent by the air conditioning control unit CLM of model A is defined as: 0x0: No request 0x1: Request high-speed operation 0x2: Request low speed operation The condensing fan speed request message signal sent by the CLM of model B is defined as: 0x0: No request 0x1: Request to run Since the message signal definition of the condensing fan request operation of model B is the same as the request for high-speed operation of model A, when being compatible with model B, it is only necessary to keep the condensing fan drive port of model B consistent with the drive port corresponding to the high-speed operation of the condensing fan of model A. At the same time, inapplicable faults are shielded by overriding control in the underlying software and application layer software. In this way, software compatibility of different hardware specifications of models A and B is achieved. There is no need to redevelop the software, conduct software testing and verification, and perform subsequent maintenance and upgrades. One version of the software can be compatible with different hardware configurations of different platform models.
[0022] The angle sensor of model A is single-channel, while the angle sensor of model B is dual-channel. Using the same method, model A only needs to use one of the two angle sensors used by model B for power supply, ground and signal voltage acquisition. Similarly, the control logic of the application layer software also needs to calibrate the control logic path to only judge the port variable of the PIN corresponding to one angle sensor of model A. At the same time, inapplicable faults are shielded in the underlying software and application layer software. In this way, adaptive compatibility of software logic with different hardware types is achieved, without the need to redevelop the software and perform software testing and verification, as well as subsequent maintenance and upgrades. One version of software adaptive calibration can be compatible with different hardware configurations of different platform models.
[0023] That is, by configuring all ports to be enabled at the underlying software level, the interaction between the hardware IO port and the underlying software is realized. In addition, the enabling control logic of the underlying software diagnostic fault is set in the underlying software, so that the underlying diagnostic fault can also be shielded. In the application layer software, the control logic corresponding to all IO ports is built, including the core control strategy and the application layer fault diagnosis strategy, etc., and finally a version of VCU software is made compatible with different platforms and different hardware specifications, which greatly reduces the software adaptive development work, test verification, and software maintenance and upgrade costs, ensures the reliability and stability of the software, avoids software bugs that may be introduced by adaptive adjustments, and does not require additional hardware costs.
[0024] The present invention is described above by way of example in conjunction with the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-mentioned method. As long as various non-substantial improvements are made using the method concept and technical solution of the present invention; or the above-mentioned concept and technical solution of the present invention are directly applied to other occasions without improvement, they are all within the protection scope of the present invention.
Claims
1. A method for implementing VCU software compatibility with different platform models, characterized in that: The following steps are involved: Step S10, identifying all I0 ports required to be supported according to different hardware specifications of different platform models, and transferring to step S20, step S30 and step S40 respectively according to the identification results; Step S20, achieving software compatibility through underlying software; Step S30, achieving software compatibility through application layer software; Step S40, achieving software compatibility through VCU software.
2. A method for implementing VCU software compatibility with different platform models according to claim 1, characterized in that: The step S20 specifically includes the following steps: Step S21, performing bottom layer software configuration for all I0 ports; Step S22, fill in the information of all I0 ports into the configuration Excel according to the predefined format, including the port variable name, etc.; Step S23, writing the enabling control logic code of the fault diagnosis in the bottom layer software; Step S24, software integration, script automation extraction of I0 port configuration information; Step S25, the over-control calibration shields the faults diagnosed in the underlying software that are not applicable to the vehicle model.
3. The method for implementing VCU software compatibility with different platform models according to claim 1, characterized in that: The step S30 specifically includes the following steps: Step S31, building input receiving and output driving logic for all I0 ports in the application layer software; Step S32, building internal function control strategy logic and application layer fault diagnosis logic for all ports in the application layer software; Step S33, building fault diagnosis enabling control logic in the application layer software; Step S34, software integration; Step S35, the over-control calibration shields the faults diagnosed in the application layer software that are not applicable to the vehicle model.
4. The method for implementing VCU software compatibility with different platform models according to claim 1, characterized in that: The step S40 specifically includes the following steps: Step S40, bottom layer software I0 port configuration; application layer software I0 port input reception and output drive logic construction; Step S42, building internal function control strategy logic and application layer fault diagnosis logic in the application layer software; Step S43, developing enabling control logic for fault diagnosis in the bottom layer software and the application layer software respectively; Step S44, software integration; Step S45, overriding the calibration to shield faults in the software that are not applicable to the vehicle model.