Modularized vehicle-mounted controller Bootloader

Abstract

The invention discloses a modularized vehicle-mounted controller Bootloader. The modularized vehicle-mounted controller Bootloader comprises a microcontroller abstraction layer MCAL, a communication and diagnosis module and an application layer, the abstraction layer MCAL of the microcontroller is driven by the MCAL of the AUTOSAR standard; the communication and diagnosis module is used for CAN communication and UDS diagnosis based on the AUTOSAR specification; the application layer comprises a BM module, an FBL module and a SecM module; the BM module is used for initializing an ECU (Electronic Control Unit), checking downloading of the ECU after initialization, managing skipping executed by a BootLoader or refreshing an APP (Application) program, and executing initialization of a microcontroller abstraction layer MCAL (Microcontroller Abstraction Layer) driver; the FBL module provides a related downloading service processing interface for the UDS for executing data processing of a downloading process; and the SecM module is used for executing a data verification task. The modularized vehicle-mounted controller Bootloader disclosed by the invention has the advantages that the quick transplantation of the Bootloader can be realized, the transplantation cost is reduced, the parameter configuration is convenient and quick, and the like.

Description

Technical Field

[0001] The invention relates to a startup technology of an embedded system, in particular to a modular vehicle-mounted controller Bootloader. Background Art

[0002] With the improvement of automobile electronics and the increase of vehicle functions, modern automobiles are undergoing a technological revolution. In daily life, cars are no longer just traditional means of transportation, but have become mobile terminals with intelligent, interconnected and electric features. Consumers have higher and higher requirements for automobile energy saving (economic and regulatory requirements for emissions), comfort, connectivity, and safety (functional safety and information security).

[0003] In recent years, the rise of new energy electric vehicles, car networking and autonomous driving technology has greatly accelerated the development of automotive electronic technology. The functions integrated in automotive electronic ECU (Electronic Control Unit) are becoming increasingly complex. To ensure that the on-board electronic system can start and run safely and efficiently, the boot loader BootLoader, as the first component in the system startup process, plays a vital role.

[0004] Bootloader is the first code executed by the embedded system after power-on. After it completes the initialization of the CPU and related hardware, it loads the operating system image or the solidified embedded application into the memory and then jumps to the space where the operating system is located to start the operating system. For embedded systems, Bootloader is implemented based on a specific hardware platform. Therefore, it is almost impossible to establish a universal Bootloader for all embedded systems. Different processor architectures have different Bootloaders. Bootloader depends not only on the CPU architecture, but also on the configuration of the embedded system board-level device (chip). For two different embedded system board-level devices, even if they use the same processor architecture, in order to make the Bootloader program running on one embedded system board-level device also run on another embedded system board-level device, it is generally necessary to modify the Bootloader source program.

[0005] Traditional BootLoader exists in the form of SDK (Software Development Kit), which has problems such as high coupling, poor portability, and poor software reusability. SDK code has no layering concept, so the coupling is high. For products that need to run on multiple hardware platforms (chips), each time the platform is switched, the BootLoader needs to be modified in a targeted manner. This behavior not only reduces the stability and reliability of the system, but also poses a huge obstacle to rapid product iteration and function upgrades. Summary of the invention

[0006] The present invention is to avoid the deficiencies existing in the above-mentioned prior art and provide a modular vehicle-mounted controller Bootloader to realize the rapid transplantation of the BootLoader and make the parameters of the BootLoader easier to configure.

[0007] The present invention adopts the following technical solutions to solve the technical problems.

[0008] A modular vehicle-mounted controller Bootloader of the present invention comprises a microcontroller abstraction layer MCAL, a communication and diagnosis module and an application layer; the microcontroller abstraction layer MCAL adopts the MCAL driver of the AUTOSAR specification; the communication and diagnosis module is CAN communication and UDS diagnosis based on the AUTOSAR specification;

[0009] The application layer includes a BM module, a FBL module and a SecM module;

[0010] The BM module is used to initialize the ECU and check the download of the ECU after initialization, manage the jump of BootLoader execution or the refresh of APP program and execute the microcontroller abstraction layer MCAL driver initialization;

[0011] The FBL module is used to provide the UDS with a relevant download service processing interface for executing data processing of the download process;

[0012] The SecM module is used to perform data verification tasks.

[0013] The modular vehicle-mounted controller Bootloader of the present invention is also characterized in that:

[0014] Furthermore, the workflow of the BM module includes the following steps:

[0015] Step 1: The user sends the initialization command BM_InitEcu to the ECU through the BM module, and the BM module performs ECU initialization;

[0016] Step 2: After initialization is completed, check the ECU download through the BM_CheckEcuDownload command; then decide whether to jump the program based on the response of the BM_CheckEcuDownload command.

[0017] Furthermore, the workflow of the FBL module includes the following steps:

[0018] Step 01: Step 34; first, set the step to step 34 during initialization. After receiving the 34 service sent by the host computer, save the starting address and length carried by the 34 service, and change the step to step 36;

[0019] Step 02: Step 36; after receiving the 36 service sent by the host computer, check the data range and record the transmitted data, and at the same time detect whether the segment data is downloaded; when the segment data is downloaded, change the step to step 37;

[0020] Step 03: Step 37; after receiving the 37 service sent by the host computer, stop data transmission and change the step to step 34 or verification step;

[0021] like Figure 4 , the 34 steps or verification steps are two different step states, indicating that when receiving the 34 service or 31 verification routine, both can pass correctly;

[0022] Step 04: Verification step; after the host computer sends the 31 verification routine, save the data verification value sent by the host computer and change the step to an erase step or a dependency check step;

[0023] Step 05: Erase step; after receiving the 31 erase routine sent by the host computer, record the starting address and length of the erase, verify whether the erase range is within the specified range, and change the step to 34 after completing the pre-erase preparation to download the APP data;

[0024] Step 06: Dependency check step; at this time, the dependency check sent by the host computer will be received. After the dependency check is completed, the APP validity flag will be changed to valid and written into the memory space, and the program will wait for reset.

[0025] Furthermore, in the FBL module, the status of the Flash driver is divided into a waiting-to-download status, a downloading status, a verifying status, a waiting-to-initialize status, an idle status, an erasing status and a programming status.

[0026] Furthermore, the SecM module performs data CRC check.

[0027] Furthermore, the SecM module includes a SecM_CreatCrc verification interface and a SecM_SoftwareCheck verification interface.

[0028] Furthermore, the configuration parameters of the application layer are configured by a configurator, and the configuration file code generated after the parameter configuration is completed is imported into the engineering code of the vehicle controller Bootloader.

[0029] Furthermore, the configurator includes a configurator body with basic functions and a module plug-in with module functions; the configurator body includes an application service module and a database service module; the application service module includes a backend service module and a WEB page service module;

[0030] The module plug-in includes a general plug-in module; the general plug-in module is used to generate a module parameter configuration page according to the user's module page description file, then perform constraint verification on the user's parameter configuration in the module parameter configuration page, and finally generate a descriptive code file after the constraints are correct.

[0031] Furthermore, the general plug-in module includes a module page plug-in, a module constraint plug-in and a generated code template plug-in, which communicate with the configurator body through respective access paths.

[0032] Furthermore, the module page plug-in is implemented as follows:

[0033] The user customizes the module arxml file that complies with the AUTOSAR specification, converts it through the corresponding plug-in interface, and interacts with the configurator body through the page access path to generate a module visual configuration interface. The visual configuration interface uses a micro-frontend to access the configurator body for data interaction.

[0034] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0035] The invention discloses a modular vehicle-mounted controller Bootloader, comprising a microcontroller abstraction layer MCAL, a communication and diagnosis module and an application layer; the microcontroller abstraction layer MCAL adopts the MCAL driver of the AUTOSAR specification; the communication and diagnosis module is the CAN communication and UDS diagnosis based on the AUTOSAR specification; the application layer comprises a BM module, an FBL module and a SecM module; the BM module is used for initializing an ECU and checking the download of the ECU after initialization, managing the jump executed by the BootLoader or the refresh of the APP program and executing the initialization of the microcontroller abstraction layer MCAL driver; the FBL module provides a related download service processing interface for the UDS to execute data processing of the download process; and the SecM module is used for executing the task of data verification.

[0036] The modular vehicle controller Bootloader of the present invention has a standard AUTOSAR interface based on the MCAL bottom-layer driver of the AUTOSAR architecture and the communication protocol stack and UDS diagnostic protocol of the BSW layer, which can realize the rapid adaptation and replacement of product modules of different manufacturers. The three driver modules of the BootLoader application layer are modularly packaged to reduce the coupling with other modules, and the relevant parameters of the application layer are packaged to realize the visual configuration of the parameters on the configurator side. In chip transplantation, the modular BootLoader can replace the MCAL driver according to actual needs, configure the application layer parameters, realize the rapid transplantation of the BootLoader, and reduce the transplantation cost.

[0037] The modular vehicle-mounted controller Bootloader of the present invention has the advantages of being able to realize rapid transplantation of the BootLoader, reducing transplantation costs, and being convenient and fast in parameter configuration. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 The figure is an architecture diagram of a modular vehicle-mounted controller Bootloader of the present invention.

[0039] Figure 2 A schematic diagram of calling a BM module of a modular vehicle-mounted controller Bootloader of the present invention.

[0040] Figure 3 A schematic diagram of calling the FBL module of the modular vehicle-mounted controller Bootloader of the present invention.

[0041] Figure 4 The present invention is a step change diagram of each step when the FBL module of the modular vehicle controller Bootloader is called.

[0042] Figure 5The present invention is a modular vehicle controller Bootloader FBL module Flash drive state and Figure 4 A diagram showing the relationships between the steps in the .

[0043] Figure 6 A schematic diagram of calling the SecM module of the modular vehicle-mounted controller Bootloader of the present invention.

[0044] Figure 7 The present invention is a schematic diagram of the implementation principle of a modular vehicle-mounted controller Bootloader configurator.

[0045] Figure 8 is a diagram of the main components of a WEB configurator according to an embodiment of the present invention;

[0046] Fig. 9 A plug-in implementation method based on a WEB configurator according to an embodiment of the present invention is shown.

[0047] Fig.10 is a flow chart of using the WEB configurator according to an embodiment of the present invention.

[0048] The present invention will be further described below through specific implementation modes in conjunction with the accompanying drawings. DETAILED DESCRIPTION

[0049] See also Figures 1 to 10 A modular vehicle-mounted controller Bootloader of the present invention comprises a microcontroller abstraction layer MCAL, a communication and diagnosis module and an application layer; the microcontroller abstraction layer MCAL adopts the MCAL driver of the AUTOSAR specification; the communication and diagnosis module is CAN communication and UDS diagnosis based on the AUTOSAR specification;

[0050] The application layer includes a BM module, a FBL module and a SecM module;

[0051] The BM module is used to initialize the ECU and check the download of the ECU after initialization, manage the jump of BootLoader execution or the refresh of APP program and execute the microcontroller abstraction layer MCAL driver initialization;

[0052] The FBL module is used to provide the UDS with a relevant download service processing interface for executing data processing of the download process;

[0053] The SecM module is used to perform data verification tasks.

[0054] The present invention provides a modular vehicle-mounted controller Bootloader, the specific architecture of which is as follows: Figure 1As shown. The modular vehicle controller Bootloader of the present invention adopts MCAL (Microcontroller Abstraction Layer) driver of AUTOSAR (AUTomotive Open System Architecture) specification at the bottom layer, and the BSW (Basic Software) layer communication and diagnosis module of BootLoader adopts CAN (Controller Area Network) communication and UDS (Unified Diagnostic Services) diagnosis based on AUTOSAR specification, and MCAL driver, communication and diagnosis based on AUTOSAR architecture have standardized interfaces and functions, and the driver interface and related parameters are the same on different platforms (chips), and the platform (chip) can be transplanted quickly without changing or with minor changes to the upper layer code, and the application layer of BootLoader adopts modular BM (BootLoader Manage, boot loader management) module, FBL (Flash BootLoader, download processing in boot loader) module and SecM (Security Module, security module) module. Modularization can make BootLoader transplant and adapt quickly.

[0055] In specific implementation, the workflow of the BM module includes the following steps:

[0056] Step 1: The user sends the initialization command BM_InitEcu to the ECU through the BM module, and the BM module performs ECU initialization;

[0057] Step 2: After initialization is completed, check the ECU download through the BM_CheckEcuDownload command; then decide whether to jump the program based on the response of the BM_CheckEcuDownload command.

[0058] The specific flow chart of BM module is as follows Figure 2 As shown, the ECU is initialized first, and after the initialization is completed, the download of the ECU will be checked. If the check shows that no download is required (no programming request is received and the APP data is verified to be correct), the program will be jumped and the APP (Application) application will be run to realize the management of the BootLoader.

[0059] In specific implementation, the workflow of the FBL module includes the following steps:

[0060] Step 01: Step 34; first, set the step to step 34 during initialization. After receiving the 34 service sent by the host computer, save the starting address and length carried by the 34 service, and change the step to step 36;

[0061] In step 34, the 34 service of UDS calls the FBL_Dcm0x34Call interface to process the data download request, and returns the processing result after the processing is completed;

[0062] Step 02: Step 36; after receiving the 36 service sent by the host computer, check the data range and record the transmitted data, and at the same time detect whether the segment data is downloaded; when the segment data is downloaded, change the step to step 37;

[0063] In step 36, the 36 service of UDS calls the FBL_Dcm0x36Call interface for data transmission. In FBL_Dcm0x36Call, the data transmission can choose whether to perform verification calculation on the data.

[0064] Step 03: Step 37; after receiving the 37 service sent by the host computer, stop data transmission and change the step to step 34 or verification step;

[0065] like Figure 4 , the 34 steps or verification steps are two different step states, indicating that when receiving the 34 service or 31 verification routine, both can pass correctly;

[0066] Step 04: Verification step; after the host computer sends the 31 verification routine, save the data verification value sent by the host computer and change the step to an erase step or a dependency check step;

[0067] The erase step is set when the 31 verification routine is received after the Flash driver download is completed, and the dependency check step is set when the 31 verification routine is received after all APP data is downloaded;

[0068] Step 05: Erase step; after receiving the 31 erase routine sent by the host computer, record the starting address and length of the erase, verify whether the erase range is within the specified range, and change the step to 34 after completing the pre-erase preparation to download the APP data;

[0069] When the APP data download in step 05 is completed and verified to be correct, the step changes to the dependency check step in step 06;

[0070] Step 06: Dependency check step; at this time, the dependency check sent by the host computer will be received. After the dependency check is completed, the APP validity flag will be changed to valid and written into the memory space, and the program will wait for reset.

[0071] The dependency check in the present invention is a fixed service in the download process, and the specific processing needs to be written according to the requirements of the automobile OEM;

[0072] The specific flow chart of FBL module is as follows Figure 3 As shown in the figure, the data processing steps in FBL are 34, 36, 37, erasing, verification, and dependency checking. When receiving the service sent by the host computer, the service will be compared with the current step. If the service and the current step are consistent, the relevant data processing will be executed, otherwise the current download process will be stopped.

[0073] As a processing module for downloading data, FBL has a strict data processing and process control mechanism. During the data processing process, the integrity of the data and the scope of data download will be checked. At the same time, the current operation steps will be checked to see if they are correct according to the data download situation and the download process. The parameters involved, such as the address and length of the logical block, can be configured through the configurator. The FBL module provides a diagnostic UDS-related service processing interface for UDS to call. For example: UDS's 34 service calls the FBL_Dcm0x34Call interface to process the data download request, and returns the processing result after the processing is completed; UDS's 36 service calls the FBL_Dcm0x36Call interface for data transmission. In FBL_Dcm0x36Call, data transmission can choose whether to perform verification calculations on the data. UDS's 31 routine integrity verification service calls the FBL_Dcm0x310202Call interface to perform integrity verification of the downloaded data.

[0074] In a specific implementation, in the FBL module, the status of the Flash driver is divided into a waiting-to-download status, a downloading status, a verification status, a waiting-to-initialize status, an idle status, an erase status and a programming status.

[0075] The various states of the Flash driver change process as follows Figure 5 The Flash driver performs relevant operations on the data according to the status. The specific status changes include the following 11 states.

[0076] State 1: The program initializes the Flash state to be downloaded;

[0077] State 2: When receiving 36 service data transmission, the state is changed to downloading state;

[0078] State 3: After receiving the 31 verification routine, the state is changed to the verification state, and the downloaded Flash driver is verified and the calculated verification result is compared with the verification value sent by the host computer;

[0079] State 4: After verification is completed, the state changes to the waiting for initialization state, at which time the Flash driver is initialized;

[0080] State 5: After initialization is completed, the state changes to idle state;

[0081] State 6: After receiving the 31 erase routine, the state is set to the erase state, and the Flash executes the erase task. At this time, the erase is performed according to the erase address and length sent by the host computer;

[0082] State 7: The erase completion state changes to the idle state;

[0083] State 8: When receiving the 36 service data transmission, the state changes to programming state and executes the programming task. During programming, the temporary stored data length and the current data length to be programmed are checked to see if they meet the length that can be written into the Flash at one time. If not, the data is temporarily stored and waits for the next programming. If they meet the requirements, the data is written into the storage space according to the address.

[0084] State 9: After programming is completed, the state changes to idle state;

[0085] State 10: After receiving the 31 verification routine, the state changes to the verification state and executes the verification task. At this time, the data is read from the storage space and calculated and verified. The calculation result is compared with the verification value sent by the host computer to see if they are the same;

[0086] State 11: After verification is completed, the state changes to idle state.

[0087] During specific implementation, data CRC check is performed in the SecM module.

[0088] During specific implementation, the SecM module includes a SecM_CreatCrc verification interface and a SecM_SoftwareCheck verification interface.

[0089] The verification flow chart of the SecM module is as follows: Figure 6 As shown in the figure, the SecM module, as a security module, ensures the integrity and validity of the data and performs CRC (Cyclic Resundancy Check) verification on the data. SecM provides two verification interfaces for data verification: (1) SecM_CreatCrc is used for CRC verification of a small amount of data and returns the verification value after completion; (2) SecM_SoftwareCheck is used for integrity verification of APP applications and returns the verification result after completion.

[0090] In a specific implementation, the configuration parameters of the application layer are configured through a configurator, and the configuration file code generated after the parameter configuration is completed is imported into the engineering code of the vehicle controller Bootloader.

[0091] The relevant parameters of the application layer can be configured by the configurator according to the actual memory division. After the configuration is completed, the configuration file code is generated and imported into the project, avoiding the problem of manually modifying the code parameters. The specific parameter configuration is shown in Table 1 and Table 2. The specific configuration process includes the following steps:

[0092] Step S1: First enter the configurator and select the BM module; in the BM module, fill in the programming flag data (32-bit hexadecimal number) in the ProgramFlagData item according to the design plan;

[0093] Step S2: Choose whether to use the USPR register to store the programming flag according to the chip usage. If the USPR register is selected, click TRUE, otherwise no change is required (the default is FLASE).

[0094] Step S3: If the USPR register is not used to store the programming flag, it is necessary to configure the starting address of the programming flag to be written into the RAM and fill the address into FlagRAMAddrss;

[0095] Step S4: Choose whether to jump the program immediately after verifying that the APP is valid (the program jumps from Boot to APP) according to the needs. If not, set WaitMode to TRUE. Otherwise, no change is required (the default is FLASE).

[0096] Step S5: If WaitMode is set to TRUE, you need to fill in the waiting time in WaitTime, in ms;

[0097] Step S6: At this time, the configuration of the relevant parameters of the BM module is completed. Next, the relevant parameters in the FBL module will be configured. First, open the FBL module in the configurator and fill the starting address of the Flash driver in the RAM into FlashDriverStartAddress;

[0098] Step S7: Fill the Flash driver length into FlashDriverLength;

[0099] Step S8: Fill the starting address of the APP application into APPStartAddress according to the memory partitioning scheme;

[0100] Step S9: according to the memory partitioning scheme, fill the starting address storing programming information and APP valid flag data into EEPROMStartAddress;

[0101] Step S10: Write the erase length of the Flash drive into FlashEraseLength according to the size of the Flash sector;

[0102] Step S11: according to the content of the downloaded APP file, set the maximum number of download segments and fill the data into ParagraphMaxNumber;

[0103] Step S12: According to the startup requirements, select whether to use the enhanced check mode (when the APP flag is valid, all blocks will be CRC checked to re-check the validity of the APP data). If the enhanced check is used, EnhancesCheckMode is set to TRUE, otherwise no change is required (the default is FLASE);

[0104] Step S13: Write the logical block length into BlockLength according to the memory partitioning scheme;

[0105] Step S14: Write the starting address of the logic block into BlockAddress according to the memory partitioning scheme;

[0106] Step S15: After the relevant parameter configuration is completed, click the Verify button. After the verification is correct, click Generate Code. At this time, the configurator generates the configuration file (.c file and .h file) of the BM module according to the relevant configuration, and imports the file into the Boot project code;

[0107] Table 1: BM module configuration parameters

[0108]

[0109]

[0110] Table 2: FBL module configuration parameters

[0111]

[0112]

[0113] In specific implementation, the configurator includes a configurator body with basic functions and a module plug-in with module functions; the configurator body includes an application service module and a database service module; the application service module includes a backend service module and a WEB page service module;

[0114] The module plug-in includes a general plug-in module; the general plug-in module is used to generate a module parameter configuration page according to the user's module page description file, then perform constraint verification on the user's parameter configuration in the module parameter configuration page, and finally generate a descriptive code file after the constraints are correct.

[0115] In specific implementation, the general plug-in module includes a module page plug-in, a module constraint plug-in and a generated code template plug-in, which communicate with the configurator body through their respective access paths.

[0116] In specific implementation, the module page plug-in is implemented as follows:

[0117] The user customizes the module arxml file that complies with the AUTOSAR specification, converts it through the corresponding plug-in interface, and interacts with the configurator body through the page access path to generate a module visual configuration interface. The visual configuration interface uses a micro-frontend to access the configurator body for data interaction.

[0118] The configuration principle is as follows Figure 7 As shown. The configurator is a plug-in AUTOSAR configuration tool based on the WEB architecture. It adopts the B / S (browser / server) mode, concentrates the load balancer, application service and database service on the server, and sends requests to the server through the WEB browser. The server integrates the load balancer, and the user accesses the AUTOSAR configuration tool interface through the link address hidden by the load balancer. The interface initiates an http request during the operation, and the load balancer evenly forwards the request to the application service.

[0119] The user accesses the configurator interface through the link address hidden by the load balancer. The operation process of the interface will initiate an http request. The load balancer will evenly forward the request to the application service. After the application service parses the request, it will interact with the database service through logical processing and finally return the page data to the WEB browser, thus completing the entire interaction work.

[0120] The modules managed by the configurator in the prior art are fixed, and users cannot customize the module structure type in the configuration tool. In order to meet the independent needs of more users, the present invention has made plug-in processing for module configuration on the basis of the above-mentioned WEB configuration tool implementation. The application service is split according to the function, with the basic functions of the configuration tool as the core body and the module functions as extensible plug-ins. The main body of the WEB configurator is still a complete WEB service system.

[0121] The main components of the WEB configurator still include application services and database storage services. The application service also includes backend services and WEB page services. The backend service and the database interact directly to access configuration data, and the WEB page calls the backend service interface. The relationship between the three is as follows: Figure 8 shown.

[0122] The AUTOSAR module structure follows the AUTOSAR specification standard, laying a solid foundation for module plug-in. According to the specification, a set of standard plug-in interfaces are defined in the configurator body. These interfaces define the communication mode between the plug-in and the configurator body, including data input and output and function calls. The configurator body and the module plug-in communicate through the plug-in interface defined by the AUTOSAR specification standard to realize data input and output and function calls.

[0123] The module plug-in consists of three parts: module page, module constraint and generated code template. They communicate with the configurator through their own access paths, so that the module plug-in and the configurator can interact successfully and realize the module parameter configuration, constraint verification and code generation functions. Fig. 9 shown.

[0124] Module page implementation method: users customize the module arxml file that complies with the AUTOSAR specification, convert it through the corresponding plug-in interface, and interact with the configurator body through the page access path to generate a module visual configuration interface. The parameter configuration interface uses a micro-frontend to access the configurator body for data interaction. The interface contains description information of each parameter and unit controls of different parameter types, providing a convenient parameter configuration method.

[0125] Module constraint implementation method: script coding is performed according to the constraint code specification, and the configurator body is communicated through the constraint access path. The configurator body contains a script parsing method to verify the user's parameter configuration in the configuration interface and prompt incorrectly configured parameters.

[0126] Code generation implementation method: Write the template according to the generated code template specification, communicate with the configurator body through the template access path, process the parameter values ​​that have been correctly verified by the constraints, and generate the corresponding descriptive code file.

[0127] After the module plug-in is connected to the configurator, it will be integrated into a complete web configuration tool, and the module can be configured and used in the configuration tool. Fig.10 shown.

[0128] The WEB mode configuration tool only needs to be accessed directly through the browser, changing the original configuration tool form and using WEB technology for development, which can perfectly solve the drawbacks of desktop configuration tools and use link access to reduce the dependence of configuration tools on the device used. Users can easily access it through a browser using a mobile phone or computer, the server is updated uniformly, and the data is stored centrally, without the need for additional user operations, which is more suitable for enterprise users.

[0129] The plug-in module also includes a user plug-in module that is custom developed according to the interface standard. The plug-in design of the configuration tool allows users to customize the development according to project requirements, and the communication between the plug-in and the core body adopts the interface standard provided by the developer. Users can use the unified module plug-in provided by the developer, or customize the template plug-in according to the interface standard. The development of a general plug-in does not require modifying the core code of the application, and the cost is much lower than the overall architecture development of the configuration tool. The high flexibility can meet the needs of most customers in the market.

[0130] By splitting functions into independent plug-ins, developers can locate and solve problems more easily. In addition, the independence and modularity of plug-ins also make the code easier to understand and maintain. The plug-in design can limit the access rights of plug-ins to the core code of the application, thereby improving the security of the application and protecting the intellectual property rights of developers.

[0131] The present invention provides a modular vehicle-mounted controller Bootloader. The proposed BootLoader solution is based on the advanced concept of modular programming, and ingeniously adopts the mature and reliable AUTOSAR architecture to achieve the decoupling of software and hardware. Through standardized interfaces and parameter configuration sets, not only can the BootLoader software be easily transplanted between different chips, but also engineers can quickly adjust the software settings according to the specific chip characteristics and functional requirements. This solution greatly improves the portability and usability of the BootLoader software.

[0132] In order to improve the portability of the BootLoader software and solve the problems of making major changes to the BootLoader program when the hardware platform changes and manually modifying code parameters during debugging, the present invention relies on the concept of modular programming to construct a modular vehicle-mounted controller Bootloader that can be quickly ported and has configurable parameters. The present invention designs various functions such as communication, diagnosis, and underlying drive in the form of modules, and generates corresponding configuration sets with the help of a configurator to adapt to different chips, thereby significantly improving the portability and ease of use of the BootLoader software. The BootLoader application layer configures the key parameters in the BootLoader through the configurator, generates relevant configuration code files and imports them into the BootLoader project, so that the BootLoader application layer parameters can be configured.

[0133] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and scope of the equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

[0134] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A modular vehicle controller Bootloader, characterized in that: It includes a microcontroller abstraction layer MCAL, a communication and diagnosis module and an application layer; the microcontroller abstraction layer MCAL adopts the MCAL driver of the AUTOSAR specification; the communication and diagnosis module is CAN communication and UDS diagnosis based on the AUTOSAR specification; The application layer includes a BM module, a FBL module and a SecM module; The BM module is used to initialize the ECU and check the download of the ECU after initialization, manage the jump of BootLoader execution or the refresh of APP program and execute the microcontroller abstraction layer MCAL driver initialization; The FBL module is used to provide the UDS with a relevant download service processing interface for executing data processing of the download process; The SecM module is used to perform data verification tasks.

2. A modular vehicle-mounted controller Bootloader according to claim 1, characterized in that: The workflow of the BM module includes the following steps: Step 1: The user sends the initialization command BM_InitEcu to the ECU through the BM module, and the BM module performs ECU initialization; Step 2: After initialization is completed, check the ECU download through the BM_CheckEcuDownload command; then decide whether to jump the program based on the response of the BM_CheckEcuDownload command.

3. A modular vehicle-mounted controller Bootloader according to claim 1, characterized in that: The workflow of the FBL module includes the following steps: Step 01: Step 34; first, set the step to step 34 during initialization. After receiving the 34 service sent by the host computer, save the starting address and length carried by the 34 service, and change the step to step 36; Step 02: Step 36; after receiving the 36 service sent by the host computer, check the data range and record the transmitted data, and at the same time detect whether the segment data is downloaded; when the segment data is downloaded, change the step to step 37; Step 03: Step 37; after receiving the 37 service sent by the host computer, stop data transmission and change the step to step 34 or verification step; Step 04: Verification step; after the host computer sends the 31 verification routine, save the data verification value sent by the host computer and change the step to an erase step or a dependency check step; Step 05: Erase step; after receiving the 31 erase routine sent by the host computer, record the starting address and length of the erase, verify whether the erase range is within the specified range, and change the step to 34 after completing the pre-erase preparation to download the APP data; Step 06: Dependency check step; at this time, the dependency check sent by the host computer will be received. After the dependency check is completed, the APP validity flag will be changed to valid and written into the memory space, and the program will wait for reset.

4. The modular vehicle-mounted controller Bootloader according to claim 1, characterized in that: In the FBL module, the status of the Flash driver is divided into a waiting state, a downloading state, a verification state, a waiting initialization state, an idle state, an erasing state and a programming state.

5. The modular vehicle-mounted controller Bootloader according to claim 1, characterized in that: The SecM module performs data CRC check.

6. A modular vehicle-mounted controller Bootloader according to claim 5, characterized in that: The SecM module includes a SecM_CreatCrc verification interface and a SecM_SoftwareCheck verification interface.

7. The modular vehicle-mounted controller Bootloader according to claim 1, characterized in that: The configuration parameters of the application layer are configured by a configurator, and the configuration file code generated after the parameter configuration is completed is imported into the engineering code of the vehicle controller Bootloader.

8. The modular vehicle-mounted controller Bootloader according to claim 1, characterized in that: The configurator includes a configurator body with basic functions and a module plug-in with module functions; the configurator body includes an application service module and a database service module; the application service module includes a backend service module and a WEB page service module; The module plug-in includes a general plug-in module; the general plug-in module is used to generate a module parameter configuration page according to the user's module page description file, then perform constraint verification on the user's parameter configuration in the module parameter configuration page, and finally generate a descriptive code file after the constraints are correct.

9. A modular vehicle-mounted controller Bootloader according to claim 8, characterized in that: The general plug-in module includes a module page plug-in, a module constraint plug-in and a generated code template plug-in, which communicate with the configurator body through their respective access paths.

10. A modular vehicle-mounted controller Bootloader according to claim 9, characterized in that: The module page plug-in is implemented as follows: The user customizes the module arxml file that complies with the AUTOSAR specification, converts it through the corresponding plug-in interface, and interacts with the configurator body through the page access path to generate a module visual configuration interface. The visual configuration interface uses a micro-frontend to access the configurator body for data interaction.

Images