LBMS underlying software architecture based on AUTOSAR

Abstract

The invention relates to an LBMS underlying software architecture based on AUTOSAR, and belongs to the technical field of automobile controllers, and the software architecture comprises a management module which comprises a target Os, a target EcuM, a target CanTp, a target Com, a target CanNm, a target NvM, a target WdgM and a target E2e which are redesigned based on LBMS requirements; the target E2e is also used for realizing the verification function of the Crc. According to the software architecture provided by the invention, the standard AUTOSAR underlying software architecture is simplified, nine MCAL modules and three complex driving modules are inherited, Dcm and Dem are statically reserved and dynamically optimized, eight management modules are redesigned according to LBSM requirements, seven non-essential modules are directly deleted, and the modules are further subjected to function integration, so that the number of the modules is reduced; therefore, the FLASH memory occupation of the MCU is obviously reduced, and the system performance is optimized.

Description

Technical Field

[0001] This invention relates to the field of automotive controller technology, and more particularly to an LBMS underlying software architecture based on AUTOSAR. Background Technology

[0002] Currently, mainstream low-voltage battery management systems (LBMS) generally adopt the classic automotive open system architecture (Classic AUTOSAR) as their underlying software architecture. The characteristics of the Classic AUTOSAR underlying software architecture are as follows: Classic AUTOSAR is a standardized underlying software architecture for traditional automotive electronic control units (ECUs), primarily targeting scenarios with high real-time requirements, limited resources, and high functional safety levels (such as engine control, chassis control, and body electronics). Its core objective is to solve problems in automotive electronic systems such as "tight coupling of software and hardware, difficulty in supplier collaboration, and low functional reusability" through standardized interfaces and layered design.

[0003] Classic AUTOSAR employs a layered architecture, consisting of three core layers from bottom to top. Each layer interacts through standardized interfaces, achieving "hardware independence" and "functional modularity." The specific structure is as follows: (1) Basic Software Layer (BSW): Located between the RTE (Runtime Environment) and the Microcontroller, the BSW interacts directly with the hardware, abstracting hardware details and providing basic services. It is further subdivided into four sub-layers (from bottom to top): The Microcontroller Abstraction Layer (MCAL) includes Microcontroller Drivers, Memory Drivers, Communication Drivers, and I / O Drivers. The MCAL directly accesses the microcontroller's (MCU) peripherals, encapsulating hardware operations into standardized interfaces (such as Can_Init() and Adc_Read()). Its purpose is to shield the hardware differences between different MCUs (such as chips from different manufacturers), allowing upper-layer software to adapt to different hardware without modification.

[0004] The ECU Abstraction Layer comprises Onboard DeviceAbstration, Memory Hardware Abstration, Communication Hardware Abstration, and I / O Hardware Abstration. This layer abstracts ECU-level hardware (such as sensors, actuators, and external chips, rather than MCU internal peripherals). For example, it encapsulates "temperature sensor readings" into a unified interface. Its purpose is to shield the hardware configuration differences between different ECUs under the same MCU (e.g., when the same MCU is installed in ECUs of different vehicle models, the sensor models may differ).

[0005] The Services Layer includes System Services, Memory Services, and Communication Services. This layer provides the core services required for ECU operation and is the core functional layer of the BSW. It includes: Operating System (OS, compliant with OSEK / VDX standards, supporting real-time functions such as task scheduling, interrupt management, and resource synchronization); Communication Services (COM, responsible for communication between internal ECU modules and between ECUs, such as CAN, LIN, and Ethernet protocol processing); Diagnostic Services (Diagnostic, supporting diagnostic protocols such as UDS, enabling fault detection and code flashing); Storage Services (NVM, managing non-volatile storage, such as parameter configuration and fault code storage); and System Services (such as clock management and error management).

[0006] Complex Drivers are used to adapt to complex hardware (such as certain dedicated sensors or chips) that cannot be fully abstracted by the MCAL or ECU abstraction layer. They allow some hardware-related code to be directly integrated while adhering to standardized interfaces as much as possible.

[0007] (2) Runtime Environment (RTE): The RTE is the "middleware" between the application layer and the BSW, and is one of the core innovations of Classic AUTOSAR. Its function is: Manage communication between application layer software components (SWCs): Through a standardized "interface-port" mechanism, data interaction (such as signal transmission and function calls) between SWCs is realized without needing to know the specific location of the other party (within the same ECU or different ECUs).

[0008] Bridging the application layer and BSW: Mapping the application layer's needs for basic services (such as calling OS tasks and using communication services) to the specific interfaces of the BSW, so that the application layer is completely free from hardware details.

[0009] Configuration-based generation: RTEs are not handwritten code, but are automatically generated by AUTOSAR configuration tools (such as VectorDaVinci) based on the functional requirements of the ECU, ensuring interface consistency.

[0010] (3) Application Layer: The application layer is the core of function implementation and is composed of software components (SWCs). SWC is the smallest modular unit of function (such as "anti-lock braking control", "lighting adjustment", etc.) and has the following characteristics: It only interacts with the outside through "ports" (such as "providing port" for providing data and "receiving port" for receiving data), and the internal implementation is completely decoupled from the outside; it does not directly access hardware or BSW, and all hardware operations are indirectly called through RTE; it has strong reusability: the same SWC can be reused in different ECUs or vehicle models (as long as the interface is compatible).

[0011] Currently, most mainstream LBMS systems use CAN communication. Based on the characteristics of LBMS software and the underlying software architecture of AUTOSAR, the current mainstream LBMS underlying software architecture is as follows: Figure 1 and Figure 2 As shown, the included modules are as follows: The AUTOSAR operating system (OS) includes: Basic Software Modules (BSW) Mode Manager (BswM), Communication Manager (COMM), Default Error Tracer (Det), ECU State Manager (EcuM), Watchdog Interface (WdgIf), Watchdog Manager (WdgM), Diagnostic Communication Manager (Dcm), Diagnostic Event Manager (Dem), Flash EEPROM Emulation (Fee), Memory Abstraction Interface (MemIf), Non-volatile Memory Manager (NVRAM Manager, NvM), Communication Manager (Com), CAN Interface (CanIf), Network Management Interface (Nm), PDU Router (PduR), CAN Network Management (CanNm), CAN State Manager (CanSM), and CAN Transport Protocol. Layer (CanTp), Cyclic Redundancy Check (CRC Library, Crc), End-to-End Protection (E2E Library, E2e), Digital Input / Output Hardware Abstraction (I / O Hardware Abstraction, DioHwAb), Analog Front End (AFE), System Basis Chip (SBC), CAN Transceiver Driver (CANTrcv), System Timer (Stm), Serial Peripheral Interface (SPI Handler Driver, Spi), CAN Driver (CAN (Controller Area Network) Driver, Can), Interrupt Management (Interrupt Router, ...Ir), Analog-to-Digital Converter (ADC), Digital Input / Output (DIO), Port (General Purpose I / O Ports and Peripheral I / O Lines) Driver, Flash Driver (FLS), and Runtime Environment (RTE).

[0012] The above underlying software architecture comprises a total of 34 modules and is a standard AUTOSAR underlying software architecture. However, using this architecture to develop the underlying software for LBMS has the following drawbacks: (1) The problem of excessive resource consumption of the standard AUTOSAR architecture in LBMS: The software generated by the standard Classic AUTOSAR occupies a lot of MCU FLASH memory, while the LBMS (Lithium Battery Management System) is a resource-constrained controller (the larger the MCU FLASH memory, the higher the cost), and its memory resource requirements are more streamlined. (2) The development cost and efficiency problem caused by relying on commercial AUTOSAR configuration tools: The module configuration of standard AUTOSAR relies on expensive commercial tools (usually costing millions, and the toolchain must be repurchased after changing projects), with many configuration items, time-consuming development and high personnel requirements. (3) The problem of redundant modules and complex functions in the standard architecture not being suitable for LBMS scenarios: The modules MemIf, Nm, PduR, BswM, Det, WdgIf included in the standard AUTOSAR are functionally redundant in LBMS (e.g., LBMS usually does not require external EEPROM and only needs one CAN channel), resulting in wasted resources. (4) Performance issues caused by the complexity of standard module scheduling and interaction mechanisms: The standard AUTOSAR modules such as Os, EcuM, and Com have a high degree of functional generalization (e.g., support for multiple communication protocols and multiple state subdivisions), and the scheduling mechanism is complex (e.g., priority preemption and multi-level state transitions), resulting in long LBMS startup time and high communication latency. (5) Insufficient adaptability of key functions (e.g., diagnosis, storage, E2E): The generalized design of standard AUTOSAR modules such as CanTp, NvM, and E2E (e.g., multi-level calls and fixed algorithms) cannot meet the LBMS's requirements for diagnostic efficiency, data storage reliability, and signal verification flexibility. Summary of the Invention

[0013] Therefore, it is necessary to provide an AUTOSAR-based LBMS underlying software architecture to simplify the LBMS underlying software architecture and reduce the MCU FLASH usage.

[0014] To achieve the above objectives, this invention provides an AUTOSAR-based LBMS underlying software architecture, comprising: MCAL module, complex driver module, diagnostic module, and management module; The MCAL module includes Fee, Stm, Spi, Can, Ir, Adc, Dio, Port, and Fls from the AUTOSAR architecture; The complex driving module includes AFE, SBC, and CanTrcv in the AUTOSAR architecture; The diagnostic module includes Dcm and Dem, which are implemented using static and dynamic code separation. The management module includes target Os, target EcuM, target CanTp, target Com, target CanNm, target NvM, target WdgM, and target E2e, which have been redesigned based on LBMS requirements. The target E2e is also used to implement the CRC verification function; The target CanTp, the target Com, and the target CanNm are also used to implement the Can interface function of CanIf; The target CanNm is also used to implement the communication mode switching function of ComM and the CAN Busoff function of CanSM.

[0015] In one possible implementation, the target Os is scheduled using a time-slice scheduling method; The target Os is specifically used for: During the power-on initialization phase, the hardware interfaces of CAN, SPI, ADC and GPIO are initialized sequentially according to configuration priority. During the periodic task management phase, a clock extraction method is implemented based on the system timer to classify tasks according to their periods; the tasks include at least 10ms high-frequency core tasks, 20ms medium-high frequency tasks, and 100ms low-frequency tasks; For scenarios with high real-time requirements, an interrupt mechanism is used to handle the situation, and the latency is controlled within 1ms.

[0016] In one possible implementation, the target WdgM employs an SBC-integrated window watchdog; The total period of the target WdgM is 1024ms, of which the first 512ms is the closed window period and the last 512ms is the open window period; feeding the dog during the closed window period is ineffective, while feeding the dog during the open window period is effective. The target WdgM is specifically used for: In the 10ms task, WdgM_Mainfunction is called to automatically execute the dog-feeding instruction when the window period reaches 50% of the time point; and a global counter is allocated to the critical process for program flow monitoring. Before each monitoring point is executed, the counter value is checked. If the check passes, the counter is incremented by 1. If it fails, it is cleared and reported to Dem.

[0017] In one possible implementation, the target EcuM adopts a simplified three-state model; The target EcuM is used to retain three core states; the core states include state transition condition configuration, wake-up source management and hibernation process management; the wake-up sources include at least battery-related wake-up, external wake-up and timed wake-up.

[0018] In one possible implementation, the target Com is used for CAN message transmission, CAN message reception, and communication timing management between the LBMS and an external CAN. The CAN message transmission includes: defining a structure for each frame of message transmission based on DBC information, assigning the corresponding data in RTE to the structure in a periodic task, and sending the message by calling the Can_Write function; The CAN message reception includes: periodically executing the Com_Mainfunction function in a periodic task, parsing the received message data, and then passing it to the application layer via RTE; The communication timing management includes: using a System timer to time periodically sent messages and executing the sending after the sending period is reached; and executing the sending of event-type messages based on event conditions.

[0019] In one possible implementation, the target CanTp is used to process the segmentation or reassembly of CAN diagnostic messages; The target CanTp is specifically used for: CanTp message reception, CanTp message transmission, and error handling mechanism; The CanTp message reception includes: periodically executing the CanTp_Mainfunction function in a periodic task to parse the received message data and reassemble the segmented frames into the original SDU in order; The CanTp message transmission includes: grouping the data to be sent into packets, and splitting data exceeding the transmission length of one frame into multiple CAN frames for transmission; The error handling mechanism includes timeout error handling and protocol format error handling, and sends corresponding negative response messages.

[0020] In one possible implementation, the target CanNm is used to manage the active or sleep state of the CAN bus, and the state is switched according to the LBMS mode in CanNm_Mainfunction; The target CanNm is also used to access the CAN controller hardware registers to determine the Busoff status and call the hardware-bound RecoverBusOff() function to restore Busoff.

[0021] In one possible implementation, the target NvM employs a dual-path storage architecture; The target NvM is specifically used for: The direct write mode, which skips FEE and directly calls the Fls interface, is used to write critical data to a fixed physical address in DFLASH. Using the FEE abstraction layer and the standard path of periodic synchronization, write ordinary data; All NVM Blocks use CRC16 verification, and critical data is stored in duplicate using the REDUNDANT type.

[0022] In one possible implementation, the architecture of the target E2e adopts an architecture of configuration resolution, core processing, code generation, and interface adaptation. The target E2e is specifically used for: After obtaining the CAN message from the Com layer, the signal that needs to be protected is filtered, the frame header is assembled, the CRC is calculated and appended to the array before being sent. And after obtaining the message from the CAN driver, parse the frame header, perform CRC check, determine the error type, and return the result; It also maintains an error counter, automatically reporting errors when the number of errors exceeds the configured threshold, and automatically clearing the error counter after N consecutive successful verifications.

[0023] In one possible implementation, the dynamic code is generated in the following way: Fill the valid data from the customer diagnostic questionnaire into a pre-formatted Excel spreadsheet to obtain an Excel spreadsheet with the diagnostic configuration items filled in. Import the Excel spreadsheet with the diagnostic configuration items filled in into the preset LBMS software configuration and analysis tool to generate the dynamic code.

[0024] The beneficial effects of this invention are as follows: The LBMS underlying software architecture based on AUTOSAR provided by this invention is simplified on the standard AUTOSAR underlying software architecture. It inherits 9 MCAL modules and 3 complex driver modules, statically retains and dynamically optimizes Dcm and Dem, redesigns 8 management modules according to LBSM requirements, directly deletes 7 unnecessary modules, and further integrates the functions of the modules, thereby reducing the number of modules, significantly reducing the MCU FLASH memory usage, and optimizing system performance. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 One of the schematic diagrams of the underlying software architecture of LBMS provided for existing technologies; Figure 2 The second schematic diagram of the underlying software architecture of LBMS provided for existing technologies; Figure 3 One of the schematic diagrams of an embodiment of the LBMS underlying software architecture based on AUTOSAR provided by the present invention; Figure 4 This is a second schematic diagram of an embodiment of the LBMS underlying software architecture based on AUTOSAR provided by the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0028] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0029] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0030] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0031] Because software generated using the standard Classic AUTOSAR architecture consumes a significant amount of MCU (Microcontroller Unit) FLASH memory, this application provides a simplified LBMS (Balanced Load Management System) underlying software architecture based on the AUTOSAR underlying software architecture to reduce MCU FLASH memory usage. The simplified underlying software architecture is as follows: Figure 3 and Figure 4 As shown. Figure 3 and Figure 4 As shown, the underlying software architecture of LBMS based on AUTOSAR includes: MCAL module, complex driver module, diagnostic module, and management module; The MCAL module includes Fee, Stm, Spi, Can, Ir, Adc, Dio, Port, and Fls from the AUTOSAR architecture; The complex driving module includes AFE, SBC, and CanTrcv in the AUTOSAR architecture; The diagnostic module includes Dcm and Dem, which are implemented using static and dynamic code separation. The management module includes target Os, target EcuM, target CanTp, target Com, target CanNm, target NvM, target WdgM, and target E2e, which have been redesigned based on LBMS requirements. The target E2e is also used to implement the CRC verification function; The target CanTp, the target Com, and the target CanNm are also used to implement the Can interface function of CanIf; The target CanNm is also used to implement the communication mode switching function of ComM and the CAN Busoff function of CanSM.

[0032] It should be noted that the AUTOSAR-based LBMS underlying software architecture, in its streamlined form, comprises 18 core functional modules, categorized into five main types based on a "retention / optimization / reduction / integration" strategy, as detailed below: Category 1: Fully Retained (Consistent with Standard AUTOSAR). These modules are essential to the LBMS and have no redundancy; they adapt without modification. They include two subcategories (MCAL modules and complex driver modules).

[0033] The MCAL modules (9 in total) are: Fee (Flash simulated EEPROM), Stm (timer module), Spi (serial peripheral interface), CAN (CAN driver), Ir (interrupt management), Adc (analog-to-digital converter), Dio (digital input / output), Port (port configuration), and Fls (flash driver).

[0034] The design strategy involves reusing the MCAL static code provided by the MCU manufacturer. The LBMS low-level developers generate dynamic code based on the circuit schematic using the MCAL configuration tool, and then integrate the static and dynamic code into the LBMS project.

[0035] For the nine modules—Fee, STM, Spi, CAN, Ir, Adc, Dio, Port, and Fls—the MCU manufacturer typically provides the MCAL static code and configuration tools. The LBMS low-level software developers then use the MCAL configuration tools to generate dynamic code based on the LBMS circuit schematic, and finally integrate the MCAL static and dynamic code into the LBMS project. Therefore, in this application, these nine modules inherit the advantages of the existing AUTOSAR low-level software architecture, remaining identical to the standard AUTOSAR.

[0036] The complex driver modules (three in total) are AFE (Analog Front End), SBC (System Base Chip), and CanTrcv (CAN Transceiver). The code for these three modules has been extremely streamlined; therefore, their implementation is consistent with the standard AUTOSAR architecture, allowing direct interaction with the application layer software via RTE.

[0037] For the three complex driver modules AFE, SBC, and CanTrcv, since the code of these three modules is already very concise, their implementation is consistent with the standard AUTOSAR architecture, and they can directly interact with the application layer software through RTE.

[0038] The second category: Static retention + dynamic optimization. The core functions of this type of module are adapted to LBMS, but the dynamic configuration needs to be simplified to reduce tool dependence. It only includes two modules: Dcm (Diagnostic Communication Management) and Dem (Fault Diagnosis Management) (and a diagnostic module).

[0039] The design strategy is as follows: static code directly reuses mature AUTOSAR standard static code, retaining the adaptability of complex functions; dynamic code, on the other hand, gets rid of the dependence on commercial AUTOSAR configuration tools and is generated through the "LBMS software configuration and analysis tool". Valid data from customer diagnostic questionnaires are filled into an Excel spreadsheet in a specified format, and the tool automatically generates dynamic code after importing it, without the need to manually adjust configuration items.

[0040] For the Dcm and Dem modules, due to their complex functions and numerous configuration items, and since most of the configuration items defined in the standard AUTOSAR are applicable to LBMS, the static code implementation of these two modules is consistent with the standard AUTOSAR in the streamlined underlying software architecture. The static code directly uses the mature AUTOSAR Dcm and Dem static code.

[0041] To avoid relying on commercial AUTOSAR configuration tools, this application provides an "LBMS software configuration and analysis tool" for the dynamic code of the Dcm and Dem modules. The implementation method of the dynamic code of Dcm and Dem is as follows: fill the valid data of the customer diagnostic questionnaire into an Excel file with a specified format, import the Excel file with the diagnostic configuration items filled in into the "LBMS software configuration and analysis tool", and then generate the dynamic code of Dcm and Dem through the "LBMS software configuration and analysis tool".

[0042] Category 3: Replace and rename.

[0043] Due to the high resource consumption or redundant functions of the standard AUTOSAR version, this type of module needs to be redesigned for LBMS requirements, totaling 8 modules (i.e., management modules).

[0044] To distinguish them from the standard versions, all are marked with "_L" after their names: Target Os (Time Slice Operating System Os_L), Target EcuM (System Management EcuM_L), Target CanTp (CAN Transmission Protocol CanTp_L), Target Com (Communication Management Com_L), Target CanNm (CAN Network Management CanNm_L), Target NvM (Non-Volatile Memory Management NvM_L), Target WdgM (Watchdog Management WdgM_L), and Target E2e (End-to-End Protection E2e_L).

[0045] The design strategy focuses on the core requirements of LBMS, reduces redundant functions (such as removing priority preemption in Os_L), optimizes resource consumption, and ensures the normal operation of core functions (such as communication, storage, and fault monitoring).

[0046] For the OS module, since the LBMS controls fewer objects and has low real-time requirements, a time-slice OS is used instead of the AUTOSAR OS to reduce the usage of MCU FLASH memory.

[0047] Category 4: Direct deletion.

[0048] These modules are not essential to LBMS or can be replaced by other methods. Removing them can significantly reduce FLASH usage. There are a total of 7 modules: MemIf (memory interface), Nm (network management), PduR (PDU routing), DioHwAb (digital input / output hardware abstraction), BswM (basic software mode management), Det (development error tracking), and WdgIf (watchdog interface).

[0049] The design strategy is as follows: MemIf is removed because LBMS does not require an external EEPROM and can directly achieve non-volatile storage through Fee / Fls. Therefore, the underlying software architecture provided removes the MemIf module, and Nvm and Fee directly achieve data transmission through interface calls.

[0050] Since LBMS typically only requires one CAN channel, the underlying software architecture eliminates the Nm module (which coordinates network management across multiple channels) and the PduR module (used for routing across multiple channels). After removing the PduR module, the CanTp, Com modules and the Can driver module directly communicate via interface calls to achieve data transmission.

[0051] For the acquisition of LBMS digital input signals, the implementation method of this application is as follows: read the register of the corresponding port in a periodic task, and then directly assign the data to the RTE; for the processing of LBMS digital output signals, the implementation method of this application is as follows: directly operate the register of the corresponding port according to the corresponding RTE data in a periodic task, thereby controlling the MCU pin to output high / low levels. Therefore, in the provided underlying software architecture, DioHwAb is deleted because LBMS digital signals can be directly processed by manipulating registers.

[0052] BswM, Det, and WdgIf can be removed due to functional redundancy or by simplifying logic replacement.

[0053] The main function of the BswM module is to implement system-level mode switching and state control. It is not very useful in the underlying software of LBMS. Therefore, the underlying software architecture removes the BswM module in order to reduce the occupation of MCU FLASH memory.

[0054] The Det module is mainly used to detect and record diagnostic events during development. This module's function must be turned off during mass production. In the LBMS software development process, if a bug is encountered in the underlying software development, it can be quickly resolved through the debugger. Therefore, the provided underlying software architecture removes the Det module to reduce the occupation of MCU FLASH memory.

[0055] The main function of the WdgIf module is to provide a standardized interface for the upper-layer WdgM, shielding the implementation differences of different hardware watchdogs at the lower level. In LBMS, only one hardware watchdog is usually used inside the SBC. Therefore, the underlying software architecture eliminates the WdgIf module, and the watchdog feeding operation is directly implemented by the WdgM module calling the corresponding interface of the SBC, thereby reducing the occupation of MCU FLASH memory.

[0056] Category 5: Functional integration.

[0057] This type of module has strong functionalities that are interdependent with other modules. After integration, it can reduce the number of layers and reduce resource consumption. It includes two modules: Crc (Cyclic Redundancy Check) and CanIf (CAN interface).

[0058] The design strategy is as follows: Since the CRC function is strongly related to the E2e function and LBMS usually only requires one CRC algorithm, the CRC function is merged into E2e_L; the CanIf function can be separated into other CAN-related modules to reduce the occupation of MCU FLASH memory, and its function is distributed into CanTp_L, Com_L, and CanNm_L, and the independent CanIf module is deleted.

[0059] For the ComM module, only the switching between Full Communication, Silent Communication, and No Communication is used in LBMS. In order to reduce the occupation of MCU FLASH memory, this application implements communication mode switching in the CanNm module.

[0060] For CanSM, only the CAN Busoff function is used in LBMS. In order to reduce the occupation of MCU FLASH memory, this application implements the CAN Busoff function in the CanNm module.

[0061] In summary, the AUTOSAR-based LBMS underlying software architecture provided by this invention simplifies the standard AUTOSAR underlying software architecture by inheriting 9 MCAL modules and 3 complex driver modules, statically retaining and dynamically optimizing Dcm and Dem, redesigning 8 management modules according to LBSM requirements, directly deleting 7 unnecessary modules, and further integrating the functions of the modules, thereby reducing the number of modules, significantly reducing the MCU FLASH memory usage, and optimizing system performance.

[0062] In some embodiments of the present invention, the target Os is scheduled using a time-slice scheduling method; The target Os is specifically used for: During the power-on initialization phase, the hardware interfaces of CAN, SPI, ADC and GPIO are initialized sequentially according to configuration priority. During the periodic task management phase, a clock extraction method is implemented based on the system timer to classify tasks according to their periods; the tasks include at least 10ms high-frequency core tasks, 20ms medium-high frequency tasks, and 100ms low-frequency tasks; For scenarios with high real-time requirements, an interrupt mechanism is used to handle the situation, and the latency is controlled within 1ms.

[0063] The target Os is the time-slice operating system module (Os_L), whose core function is to be responsible for the "initialization scheduling + periodic task management" of the LBMS system. It is the foundation for the operation of all modules and supports hardware initialization and periodic task execution.

[0064] Power-on initialization phase: After power-on, the pre-defined startup code is executed first to initialize the MCU core (including clock and stack configuration). Then, the "peripheral initialization sequence" is loaded (the hardware interfaces such as CAN, SPI, ADC, and GPIO are initialized in sequence according to the priority configured in Excel). This sequence is generated by Excel configuration and the priority order is: Port→Spi→Can→Adc→AFE→SBC, ensuring that the hardware interfaces are ready step by step according to their dependencies. After they are ready, the main loop is entered.

[0065] Periodic task management phase: Based on System Timer, the "clock picking method" is implemented to manage tasks according to their execution cycle (10ms / 20ms / 100ms, etc.).

[0066] The 10ms task is a high-frequency core task (such as CAN data reception, current and voltage sampling value processing, and the main functions of each BSW and ASW module); the 20ms task is a medium-to-high frequency task (such as SOC calculation and EcuM_Mainfunction); and the 100ms task is a low-frequency task (such as Idle Task, which is responsible for lighting up the LED).

[0067] Real-time performance guarantee: For scenarios with high real-time requirements such as CAN data reception (latency must be <1ms), it does not rely on periodic task scheduling, but directly handles the process through the interrupt mechanism. For example, after the CAN message reception interrupt is triggered, data parsing is executed immediately to avoid periodic delays.

[0068] The generation of the Os_L module code relies on an Excel configuration spreadsheet. This spreadsheet defines the parameters for all LBMS periodic tasks (including task execution cycles and associated module functions), which is the core basis for Os_L scheduling. Importing this Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool" will automatically generate the Os_L scheduling code, eliminating the need to manually write complex scheduling logic.

[0069] The Os_L module code generation is achieved by importing the Os configuration Excel spreadsheet into the preset "LBMS Software Configuration and Analysis Tool". The Os configuration spreadsheet, shown in Table 1, defines the parameters for all periodic tasks in the BMS, including the task execution cycle and associated module functions, and is the core basis for Os module scheduling. An example of filling out the Os configuration spreadsheet is shown in Table 2.

[0070] Table 1

[0071] Table 2

[0072] Compared to the standard AUTOSAR OS, Os_L is better suited to LBMS requirements, as compared in the following three dimensions: In terms of scheduling mechanisms, the standard AUTOSAR OS supports task priority preemption and time-triggered / event-triggered hybrid scheduling, but it has high resource overhead, insufficient flexibility, and is difficult to debug and locate problems. In contrast, the Os_L of this invention only retains "periodic polling + interrupt" and removes priority preemption (BMS tasks have low real-time requirements and do not require complex scheduling), which can meet the needs of LBMS, and occupies less FLASH memory while reducing resource consumption.

[0073] In terms of resource consumption, the standard AUTOSAR OS has high resource consumption, insufficient flexibility, and high difficulty in debugging and problem localization, while Os_L focuses on core functions and significantly reduces FLASH consumption.

[0074] In terms of configuration, the standard AUTOSAR OS requires configuring task attributes through ARXML, which involves many configuration items and time-consuming development. The Os_L of this invention directly defines "task cycle, associated modules, and enable status" in Excel, and automatically associates function calls when generating code, greatly reducing the workload of development.

[0075] In some embodiments of the present invention, the target WdgM employs an SBC-integrated window watchdog; The total period of the target WdgM is 1024ms, of which the first 512ms is the closed window period and the last 512ms is the open window period; feeding the dog during the closed window period is ineffective, while feeding the dog during the open window period is effective. The target WdgM is specifically used for: In the 10ms task, WdgM_Mainfunction is called to automatically execute the dog-feeding instruction when the window period reaches 50% of the time point; and a global counter is allocated to the critical process for program flow monitoring. Before each monitoring point is executed, the counter value is checked. If the check passes, the counter is incremented by 1. If it fails, it is cleared and reported to Dem.

[0076] The target WdgM is the watchdog management module (WdgM_L), whose core function is to ensure that the LBMS software does not get stuck in an infinite loop or crash through "task cycle monitoring + program flow monitoring", thereby improving the reliability of system operation and avoiding battery management failure due to software anomalies.

[0077] Hardware watchdog selection and configuration: A window watchdog integrated into the SBC (System Base Chip) is adopted. Compared with ordinary watchdogs, the window watchdog adds an "open window period / close window period" design to prevent accidental watchdog feeding. Core parameters are configured via Excel: total cycle 1024ms (MCU reset is triggered if watchdog feeding is not performed within the timeout); the close window period is the first 512ms (watchdog feeding is invalid during this stage to avoid accidental watchdog feeding in case of program abnormalities); the open window period is the last 512ms (only this stage can perform valid watchdog feeding).

[0078] Periodic dog-feeding logic: In the 10ms task, WdgM_Mainfunction is called to determine the window state through System Timer: When the window is 50% open (i.e., 512ms + 256ms = 768ms after power-on), the dog-feeding instruction is automatically executed; after the dog-feeding is completed, the window state is reset to "closed window" and waits for the next cycle.

[0079] Program flashing safety control: When flashing the program, the process must first jump to the BootLoader, which takes 300~500ms. To avoid watchdog timeout reset during flashing, the power-down process is only allowed to be triggered when the watchdog is within the "first 25% of the window" (i.e., the first 128ms), ensuring the safety of the flashing process.

[0080] Program flow monitoring: Allocate global counters for key processes such as charging and discharging protection logic (e.g., data storage logic). Before each monitoring point is executed, the counter value is checked (if the expected value is 1, the check passes). If the check passes, the counter is incremented by 1; if the check fails, the counter is cleared and reported to the Dem module. After the entire process is completed, the counter is reset and the next round of loop monitoring begins.

[0081] The generation of the WdgM_L module code relies on an Excel configuration spreadsheet. This spreadsheet defines the hardware watchdog (SBC integration) window parameters (total cycle, window closing period, window opening period), program write safety conditions (allowed power-down window periods), and program flow monitoring points (the locations of monitoring points for critical processes). Importing this spreadsheet into the "LBMS Software Configuration and Analysis Tool" automatically generates the WdgM_L driver binding and monitoring code, eliminating the need for manual hardware interface adaptation.

[0082] The WdgM_L module code generation is achieved by importing the WdgM configuration Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool". The WdgM configuration spreadsheet is shown in Table 3, which defines the window parameters for configuring the hardware watchdog (SBC integration), program flashing security conditions, and program flow monitoring points.

[0083] Table 3

[0084] The differences between WdgM_L and AUTOSAR WdgM are as follows: Standard AUTOSAR WdgM requires precise configuration of dozens of parameters (such as reference period, deviation range, and conversion rules), and parameter mismatch may lead to false alarms or missed alarms. Furthermore, standard AUTOSAR WdgM has high resource consumption and insufficient flexibility. This application directly defines the "window time and write security period" in Excel, and automatically binds the hardware driver when generating code, which can meet the requirements of LBMS, and has a small FLASH memory footprint and a small development workload.

[0085] In some embodiments of the present invention, the target EcuM adopts a simplified three-state model; The target EcuM is used to retain three core states; the core states include state transition condition configuration, wake-up source management and hibernation process management; the wake-up sources include at least battery-related wake-up, external wake-up and timed wake-up.

[0086] The target EcuM is the system management module (EcuM_L). Its core functions are: to act as the "system steward" of LBMS, manage the overall system state transitions and wake-up sources, ensure that the system starts / sleeps on demand, coordinate the operating logic of each module in different states, and reduce power consumption in non-working states.

[0087] State Management: The multi-state design of standard AUTOSAR is simplified, retaining only 3 core states (startup state, running state, and hibernation state). State transition conditions are configured via Excel (e.g., the hibernation state switches to the running state after the wake-up condition is met, and the running state switches to the hibernation state after the hibernation condition is met). The functional description and state transition conditions of state management are shown in Table 4.

[0088] Table 4

[0089] Wake-up source management: During the initialization phase, all wake-up sources are detected, categorized, managed, and synchronized to the application layer: Battery-related wake-ups are triggered by AFE (e.g., overcurrent / overvoltage / overtemperature, requiring hardware debouncing for 50ms); External wake-ups include hardwired wake-ups (e.g., key signals, tailgate switch signals), CAN wake-ups (network management messages), and timed wake-ups (e.g., 10-second cycle wake-ups to check battery status); After wake-up, operations such as clearing the wake-up flag, notifying the CanNm module to activate the network, and switching the EcuM to the running state are performed to ensure normal system startup.

[0090] The code generation of the EcuM_L module is achieved by importing the EcuM configuration Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool". The EcuM configuration spreadsheet is shown in Table 5, which defines the three-state transition conditions, wake-up source parameters and hibernation process parameters of EcuM.

[0091] Table 5

[0092] The differences between EcuM_L and the standard AUTOSAR EcuM are as follows: The standard AUTOSAR EcuM defines 8 to 10 sub-states (such as ECUMM_STATE_PRE_INIT, ECUMM_STATE_INIT, ECUMM_STATE_POST_INIT, ECUMM_STATE_RUN, ECUMM_STATE_SLEEP, ECUMM_STATE_SHUTDOWN, etc.) and also introduces "sub-states" (such as RUN_REQUESTED / RUN_ACTIVE under RUN). State transitions need to meet the generalized triggering conditions for multi-ECU collaboration (such as "running permission" for multi-ECU collaboration), which leads to code redundancy and increases the risk of state transition failures.

[0093] EcuM_L simplifies the core LBMS scenario of "startup → running → hibernation / shutdown" into a three-state model and removes sub-states. The state transition logic is directly bound to the BMS hardware characteristics, which greatly reduces FLASH usage.

[0094] Meanwhile, the initialization process of the standard AUTOSAR EcuM is "multi-level waiting", which has a long startup time; EcuM_L is changed to "linear execution", which has higher initialization efficiency and shortens the LBMS startup time.

[0095] In addition, the standard AUTOSAR EcuM abstracts the wake-up source through "wake-up source enumeration" and does not bind to specific hardware types. The "mapping relationship between wake-up source and hardware pin" needs to be configured through ARXML. The wake-up source detection only provides a general "level / edge trigger" judgment and does not link with the LBMS core hardware (such as AFE, SBC).

[0096] The EcuM_L in this application uses "LBMS hardware features as the core" to achieve "classification management + hardware linkage detection" of wake-up sources, without the need for an additional adaptation layer, thus improving development efficiency.

[0097] As an independent battery management unit, LBMS does not require complex state switching involving multiple ECUs; too many states lead to code redundancy and increase the risk of state transition failures (such as abnormal sub-state switching).

[0098] In some embodiments of the present invention, the target Com is used for CAN message transmission, CAN message reception and communication timing management between LBMS and an external CAN; The CAN message transmission includes: defining a structure for each frame of message transmission based on DBC information, assigning the corresponding data in RTE to the structure in a periodic task, and sending the message by calling the Can_Write function; The CAN message reception includes: periodically executing the Com_Mainfunction function in a periodic task, parsing the received message data, and then passing it to the application layer via RTE; The communication timing management includes: using a System timer to time periodically sent messages and executing the sending after the sending period is reached; and executing the sending of event-type messages based on event conditions.

[0099] The target Com is the communication management module (Com_L), whose core function is to be responsible for the transmission and reception of CAN messages between LBMS and external devices (such as vehicle controllers and DC-DC converters), including the processing of "periodic messages + event messages", as well as the parsing and mapping of CAN signals. It is the core channel for LBMS to interact with the outside world.

[0100] CAN message transmission: Based on the imported DBC information, a dedicated structure (such as structTx_LBM_334_Tag) is defined for each frame of the message to be transmitted. The signal fields in the structure are divided according to the byte / bit layout defined by DBC (such as LBMS_DischrgMosTemp_bit11_4). In periodic tasks, the corresponding data in RTE (such as Rte_AswData) is assigned to the structure fields. Then, according to the transmit handle Hth allocated in MCAL, the Can_Write function is called to pass the message to be transmitted to the Can driver module, thus completing the message transmission.

[0101] For example, based on the imported DBC information, a structure is defined for each frame of message transmission, such as: struct Tx_LBM_334_Tag { struct { uint8 LBMS_DischrgMosTemp_bit11_4; .......................... }Byte0; }; struct Tx_LBM_334_Tag Tx_LBM_334_Msg; Then, in the periodic task, the corresponding data Rte_AswData in Rte is assigned to the structure. Then, according to the transmit handle Hth allocated in MCAL, the message to be sent is passed to the CAN driver module for message transmission by calling the Can_Write function. An example of CAN message transmission is as follows: Tx_LBM_334_Msg.Byte0.LBMS_DischrgMosTemp_bit11_4 = Rte_AswData; PduInfo_Temp.sdu =&Tx_LBM_334_Msg.Byte0.LBMS_DischrgMosTemp_bit11_4; Can_Write(Hth,&PduInfo_Temp); CAN message reception: The Com_Mainfunction function is executed periodically in periodic tasks such as 10ms. When the Can_Callback function in MCAL obtains a message from the COM module, the message data is first assigned to a specified array (such as array A). In the Com_Mainfunction function, the data in array A is parsed according to DBC, the valid signals are extracted, and then passed to the application layer through RTE for processing by the application layer.

[0102] Communication timing management: For periodically sent messages, a System Timer is used for timing. When the message sending period specified in the DBC is reached, the corresponding message is automatically sent. For event-type messages, conditions are judged based on the signals obtained from the RTE (such as specific fault signal triggering). When the event message sending conditions are met, the corresponding message is sent immediately to ensure timely event response.

[0103] The code generation for the Com_L module depends on the DBC file and the "LBMS Software Configuration and Analysis Tool": Before generating the code, the DBC file is imported into the tool, which automatically parses the message information (such as ID, period, and signal layout). For periodic CAN message transmission, the "LBMS Software Configuration and Analysis Tool" parses the transmission period of each frame from the DBC file, sets a transmission flag for each frame, and sets the flag to a valid state when the transmission time expires. When Com_Mainfunction detects the valid flag, it assigns signal values ​​and assembles packets according to the DBC file and calls Can_Write to send the message. For event-based CAN message transmission, the tool generates condition judgment logic. When the event condition is met, the transmission flag is set to valid, triggering message transmission.

[0104] In Com_Mainfunction, when the send flag is valid, the corresponding signal is assigned and the packet is assembled according to DBC. Then, according to the send handle Hth allocated in MCAL, the message to be sent is passed to MCAL by calling the Can_Write function for transmission.

[0105] For event-driven CAN message transmission, the transmit flag is set to an active state when the corresponding event conditions are met. The following is sample code for periodic CAN message transmission.

[0106] if(1==Rte_ASW_CANO_Struct_Data.CAN_SendSignal_10ms_Cnt1000) { Tx_LBM_334_Msg.Byte0.LBMS_DischrgMosTemp_bit11_4 = (uint8)(Rte_ASW_CANO_Struct_Data.CANO_DischrgMosTemp_SR_PP>>4); Tx_LBM_334_Msg.Byte1.LBMS_DischrgMosTemp_bit3_0 = (uint8)(Rte_ASW_CANO_Struct_Data.CANO_DischrgMosTemp_SR_PP&0x0F); ............................................... .............................................. PduInfo_Temp.sdu =&Tx_LBM_334_Msg.Byte0.LBMS_DischrgMosTemp_bit11_4; PduInfo_Temp.length=48; PduInfo_Temp.id=0x40000334; Can_Write(5,&PduInfo_Temp); } For CAN message reception, the Can_Callback function in MCAL places the message from the home COM module read by the interrupt into an array (e.g., RxMsg_0xB0_Buf). The Com_Mainfunction function executes in a periodic task, parsing the data in this array according to the DBC (Database Configuration Code), and then transmitting the parsed signal to the application layer software via RTE (Real-Time Transmission). The following is an example code for CAN message reception: CanRxSignal_Struct_Data.PC_Cal_SocCalEnable_valid=RxMsg_0xB0_Buf[2]&0x01; CanRxSignal_Struct_Data.PC_Cal_SocCalValue_valid=RxMsg_0xB0_Buf[3]; The differences between Com_L and standard AUTOSAR COM are as follows: The standard AUTOSAR COM module, as a standardized general-purpose module, needs to support multiple communication protocols such as CAN, LIN, and Ethernet. It includes a complex layered structure such as PDU Router, signal / PDU mapping, and status management, adapting to different ECUs and application scenarios. It is highly versatile but has high redundancy. In contrast, the Com_L module is specifically designed for CAN communication between the LBMS and external devices (vehicle controller, DC-DC converter, etc.). It strips away the redundant functions of the general-purpose module, retaining only the core functions such as periodic / event transmission and reception of CAN messages and signal parsing and mapping. Its architecture is more streamlined and suitable for resource-constrained scenarios of BMS controllers (such as limited MCU computing power and storage), which can reduce operating overhead.

[0107] The standard AUTOSAR COM module follows a strict layering principle. The signal needs to go through multiple layers of mapping: "Signal→IPDU→LPdu". It interacts with the PDU Router through RTE and is finally sent by the underlying communication. The inter-layer interaction process is long.

[0108] The Com_L module uses a direct mapping of "signal-structure-hardware driver": When sending, the RTE data is directly assigned to the structure of the corresponding message (according to the byte / bit layout defined by DBC), and the MCAL driver is directly called through Can_Write.

[0109] During reception, CAN message data is directly stored in an array, parsed in Com_Mainfunction using DBC, and then directly passed to RTE. This reduces intermediate layer conversion overhead and improves signal processing efficiency.

[0110] In some embodiments of the present invention, the target CanTp is used to process the segmentation or reassembly of CAN diagnostic messages; The target CanTp is specifically used for: CanTp message reception, CanTp message transmission, and error handling mechanism; The CanTp message reception includes: periodically executing the CanTp_Mainfunction function in a periodic task to parse the received message data and reassemble the segmented frames into the original SDU in order; The CanTp message transmission includes: packetizing the data to be sent, and splitting data exceeding the transmission length of one frame into multiple CAN frames for transmission; The error handling mechanism includes timeout error handling and protocol format error handling, and sends corresponding negative response messages.

[0111] The target CanTp is a CAN transmission protocol module (CanTp_L). Its core function is to process the "segmentation / reassembly" of CAN diagnostic messages. When the length of the diagnostic data is greater than 8 bytes, it needs to be split into multiple frames for transmission. At the same time, it adapts to the UDS (Unified Diagnostic Service) protocol to ensure normal interaction between diagnostic commands and responses.

[0112] CanTp_L interacts directly with the CAN driver and Dcm module, eliminating the need for the CANIF (CAN interface) and PDUR (PDU routing) intermediate layers required in standard AUTOSAR. During reception, Can_Callback directly writes the message data into the array of CanTp_L (such as array B), and during transmission, CanTp_L directly calls Can_Write. Dcm and CanTp_L directly transmit data without the need for PDUR routing, which reduces communication latency (especially in emergency fault response) and reduces the resource consumption caused by intermediate layer buffers and state machines.

[0113] CanTp message reception: The CanTp_Mainfunction function is executed periodically in periodic tasks (e.g., 10ms tasks). When the Can_Callback function in MCAL obtains a message belonging to the CanTp module, the data of the message is first assigned to array B. In the CanTp_Mainfunction function, the data in array B is parsed according to the diagnostic survey table. If the received frame is a segmented frame, it needs to be reassembled into the original SDU in order. After parsing out the corresponding service, the data is passed to the Dcm module for processing.

[0114] CANTp Message Transmission: After the DCM module processes the diagnostic request, it calls the CanTp_Transmit function to pass the data to be sent to the CanTp module. The CanTp module assembles the data into packets according to the diagnostic questionnaire and assigns the assembled data to array C. Then, the CanTp module calls the Can_Write function to pass the message to be sent to MCAL for message transmission. When a single message frame cannot be completely transmitted, the CanTp module splits the SDU (Service Data Unit) into multiple CAN frames (first frame FF, subsequent frames CF) for transmission.

[0115] Error handling includes: 1. Timeout error handling: Taking the sender's N_As timeout as an example, N_As is periodically monitored in CanTp_Mainfunction. If the sender does not receive the receiver's flow control frame (FC) within N_As time after sending the first frame (FF), a timeout error is reported, and CanTp calls the Can_Write function to send the corresponding negative response message.

[0116] 2. Protocol format error handling: Taking receiver sequence error as an example, the CanTp module checks consecutive frames. If the receiver has received the first frame (FF) and the first consecutive frame (CF, sequence number 0), but the sequence number of the next CF is 2 (expected to be 1), then a protocol error is reported. CanTp calls the Can_Write function to send the corresponding negative response message.

[0117] The code generation for the CanTp_L module is achieved by importing the CanTp configuration Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool". The CanTp configuration spreadsheet is shown in Table 6, which defines the transmission parameters of the configuration diagnostic message, including timeout, number of retries, segmentation rules, and compatibility with the ISO 15765-2 protocol.

[0118] Table 6

[0119] The differences between CanTp_L and the standard AUTOSAR CanTp are as follows: In standard AUTOSAR, CanTp and MCAL's Can drivers (Can_Write / Can_Callback) must interact indirectly through CANIF. However, in this application, CanTp interacts directly with MCAL. When receiving data, Can_Callback (MCAL callback) directly writes the message data into array B of CanTp, without the need for CANIF relay.

[0120] When sending data, CanTp directly calls Can_Write (MCAL function) to send the data without going through CANIF's queue scheduling.

[0121] This can reduce communication latency, eliminate intermediate processing steps of CANIF (such as queue sorting and resource verification), and significantly improve the real-time performance of diagnostic messages (such as emergency fault response); it can also reduce resource consumption, eliminate the need for CANIF layer buffers (such as send queues and receive filter tables) and state machines, and reduce ECU RAM / ROM overhead.

[0122] In standard AUTOSAR, PDU transmission between CanTp and Dcm must be routed via PDUR: Receiving path: CanTp reassembles SDU → PDUR (routes according to PDU ID) → Dcm. PDUR needs to query the routing table and handle PDU multiplexing (such as the same ID carrying multiple services).

[0123] Sending path: Dcm generates response → PDUR (routes to CanTp) → CanTp assembles packets. PDUR needs to verify the validity of PDU and handle cross-layer adaptation (such as length conversion).

[0124] In this application, CanTp interacts directly with Dcm: Upon receiving, CanTp parses the service data and "passes it directly to Dcm".

[0125] When sending, Dcm processes the request and "directly calls CanTp_Transmit" without the need for PDUR relay.

[0126] This can shorten the diagnostic data path, eliminate the need for PDUR route lookup and multiplexing processing, and reduce the processing time of diagnostic requests / responses; it can also simplify diagnostic configuration association, as CanTp directly relies on the "diagnostic survey table" parsing service and shares the configuration context (such as SID / DID mapping) with Dcm, avoiding dual configuration of PDUR routing table and diagnostic table (reducing the risk of configuration errors).

[0127] In some embodiments of the present invention, the target CanNm is used to manage the active or sleep state of the CAN bus, and the state is switched according to the LBMS mode in CanNm_Mainfunction; The target CanNm is also used to access the CAN controller hardware registers to determine the Busoff status and call the hardware-bound RecoverBusOff() function to restore Busoff.

[0128] The target CanNm is the CAN network management module (CanNm_L), whose core functions are: managing the "active / sleep" state of the CAN bus to reduce power consumption when the LBMS is in sleep mode; and handling CAN bus offline recovery to ensure the stability of CAN communication.

[0129] Busoff status is detected by directly reading the CAN controller hardware registers (such as the BOFF bit of the CANx_ESR register in the NXP S32K series), eliminating the need for the CANIF and CANSM (CAN Status Management) intermediate layers and reducing status judgment latency. Upon detecting Busoff, the hardware-bound RecoverBusOff function is directly called to reset the CAN controller, resulting in faster recovery. Furthermore, a fixed-address SRAM region (e.g., 0x20000800-0x200008FF) is reserved to store network status information (such as the online node list and sleep request flag). CanNm_L directly reads and writes to this region, and other modules access it through address mapping, eliminating the need for COMM module synchronization and reducing code redundancy.

[0130] State Management: Based on the AUTOSAR specification, this application designs 5 states: Bus Sleep Mode, PrepareBus-Sleep Mode, Repeat Message State, Normal Operation State, and Ready Sleep State. The state switching is performed in CanNm_Mainfunction according to the LBMS mode. The functional descriptions and transition triggering conditions of the 5 states of CanNm_L are shown in Table 7.

[0131] Table 7

[0132] In the LBMS state design, a fixed address SRAM area (such as 0x20000800-0x200008FF) is reserved for storing network state information (such as online node list, sleep request flag). CanNm_L can directly read and write this area, and other modules can access it directly through address mapping, without the need for the COMM module's state synchronization interface.

[0133] The NM message sending process is as follows: 1) During the LBMS startup phase, the CanNm module initializes by calling CANNm_Init(), loading the configuration parameters of NM messages (such as message ID, period, data length, node ID, etc.). After initialization, the CanNm module enters the "initialization complete" state, waiting for the upper layer to trigger network activation.

[0134] 2) When the CANNm module enters Repeat Message State or Normal Operation State, it begins preparing to send NM messages.

[0135] 3) Before sending an NM message, CanNm needs to assemble the message data. The data format of an NM message typically includes: control bits (such as wake-up flag, sleep request flag), local node ID, and network status information (such as whether to prepare for hibernation). The CANNm module fills in these fields to generate the final NM message data.

[0136] 4) After the CanNm message is assembled, the CanNm module triggers message transmission by calling CANNm_RequestTransmit(). This function will call the Can_Write function in the Can driver to send the message to the CAN bus.

[0137] NM messages typically need to be sent periodically (e.g., every 100ms) to maintain network activity, with the period configured by NmCycleTime. CanNm_MainFunction() is the main loop function of CANNm (scheduled by RTE and executed periodically), responsible for checking the transmission timer and triggering periodic transmission.

[0138] The NM message reception process is as follows: 1) After receiving an NM message, the CANNm_RxIndication() function is called in the Can driver function to notify the CANNm module (only if the message ID matches the NM message ID).

[0139] 2) For valid messages, the CANNm module parses their content, extracts the status information of the sending node, and updates the local network status (such as recording that the node is online and processing wake-up requests).

[0140] The timeout monitoring process is as follows: 1) Initialization phase: Load the configuration parameters for timeout monitoring and complete the initialization of the timer to prepare for subsequent monitoring.

[0141] 2) Runtime monitoring phase: If a valid NM frame is received, the timer is reset; if no valid NM message is received, wait for the timer to time out.

[0142] 3) Timeout processing phase: When the timeout timer expires (no valid NM frame is received), timeout processing is triggered, including state switching, recording diagnostic events, etc. For example, if the Nm-Timeout timer expires, the network management mode will be switched from Ready SleepState to Prepare Bus-Sleep Mode.

[0143] The CAN Busoff processing flow is as follows: In CanNm_Mainfunction, the Busoff status bit of the CAN controller is checked periodically. If a Busoff event occurs, the RecoverBusOff function is called periodically to restore CAN communication according to the fast or slow recovery time defined by network management requirements.

[0144] The code generation for the CanNm_L module is achieved by importing the CanNm configuration Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool". The CanNm_L configuration spreadsheet is shown in Table 8, which defines the CAN network management state transition parameters, NM message period, and Busoff recovery strategy.

[0145] Table 8

[0146] The differences between CanNm_L and the standard AUTOSAR CanNm are as follows: (1) CAN BusOff processing.

[0147] Traditional AUTOSAR CanNm requires multiple layers of abstraction to perceive CAN bus status (such as Busoff and transmit buffer status). The process is as follows: CAN controller hardware status → CAN driver (CanDrv) → CAN interface (CANIF) → CAMSM (CAN status management) → CanNm. Status interaction needs to be done through standardized interfaces (such as CanIf_GetControllerState()), which results in data forwarding delay.

[0148] In this application, the Busoff status is determined in real time by directly accessing the CAN controller hardware registers (such as the BOFF bit of the CANx_ESR register in the NXP S32K series) in the CanNm_Mainfunction, without needing to go through CANIF or CAMSM state transitions. For Busoff recovery, when Busoff is detected, the hardware-bound RecoverBusOff() function is directly called. This function achieves physical layer recovery by manipulating the CAN controller's reset register (such as the RESET bit of CANx_MCR), rather than indirectly scheduling through CAMSM's CanSM_RequestBusOffRecovery(). This design reduces status determination latency and improves CAN communication recovery speed. Furthermore, this design has a smaller code size, reducing FLASH space usage.

[0149] (2) Discard COMM and CANIF modules.

[0150] Traditional AUTOSAR CanNm requires interaction with the COMM module to synchronize network status. Information such as node online status and sleep requests need to be synchronized through interfaces such as Comm_SyncNetworkState(). The COMM module, as an intermediate layer, maintains the status table, which increases the amount of code and memory usage.

[0151] In this application, a designated SRAM region is used for state sharing. A fixed-address SRAM region (e.g., 0x20000800-0x200008FF) is reserved during the LBMS design to store network status information (such as online node lists and sleep request flags). CanNm_L directly reads and writes this region, and other modules access it directly through address mapping, eliminating the need for a COMM module's state synchronization interface. The message sending function CANNm_RequestTransmit() directly calls the underlying register operation functions of the CAN driver, instead of using the CanIf_Transmit() abstract interface. This design reduces three layers of function calls (simplifying the process from CanNm→CANIF→CanDrv to CanNm→hardware registers), reducing transmission latency and also reducing FLASH usage.

[0152] In some embodiments of the present invention, the target NvM adopts a dual-path storage architecture; The target NvM is specifically used for: The direct write mode, which skips FEE and directly calls the Fls interface, is used to write critical data to a fixed physical address in DFLASH. Using the FEE abstraction layer and the standard path of periodic synchronization, write ordinary data; All NVM Blocks use CRC16 verification, and critical data is stored in duplicate using the REDUNDANT type.

[0153] The target NvM is a non-volatile storage management module (NvM_L), whose core function is to manage the "storage / reading / verification" of critical data in the LBMS, ensuring that data is not lost when power is off (such as calibration data, SOC, DTC), while extending the lifespan of DFlash (data flash memory).

[0154] NvM_L employs a "dual-path storage architecture." For critical data with high reliability requirements, such as current calibration data and BMS serial numbers, it skips the FEE (Flash Abstraction Layer) and directly calls the Fls interface to write to a fixed address in the DFLASH, reducing intermediate layer latency and minimizing the loss of critical data due to FEE malfunction. For ordinary data such as SOC and DTC, it retains the "FEE abstraction layer + periodic synchronization" path, using FEE to achieve wear leveling. Simultaneously, a "dynamic storage strategy" is introduced: SOC data uses threshold-triggered storage (triggered when SOC changes exceed 3%), combined with periodic FEE writes. This avoids SOC jumps caused by software resets and reduces wear on the DFlash from invalid writes, lowering the storage frequency by over 60%.

[0155] For data management, data with high reliability requirements, such as current calibration data, BMS serial number, and voltage calibration data, are directly stored in a fixed address in the DFLASH memory. Taking current calibration data as an example, after the current is calibrated using the host computer, the LBMS performs a CRC check on the current calibration data, and then directly calls the Fls data write interface in the NvM module to write the current calibration data to the fixed address in the DFlash.

[0156] For SOC storage, in order to prevent SOC jump caused by software reset, the SOC is stored immediately. According to the lifespan of DFLASH, when the SOC changes by more than 3%, the NvM_WriteBlock interface will be called immediately to pass the data storage to the FEE module. When the Fee_Mainfunction is executed periodically, the data will be written to DFLASH.

[0157] Other data, such as DTC data and BMS service time, are stored via FEE when the BMS is powered off.

[0158] Error handling: All NVM Blocks use CRC16 checksum. During data storage, the CRC checksum value of each NVM Block is written to the DFLASH. Every time data is read from the DFLASH upon power-up, the CRC value of each NVM Block is checked. If the CRC check fails, the LBMS uses the default value and notifies the Dem module to record the corresponding DTC.

[0159] All data that needs to be stored is set with default values. In the event of a data storage failure, the corresponding storage interface is assigned a default value.

[0160] To ensure that data is written correctly, the NvM_ReadBlock interface is called to read the written data and verify it after each write operation. If the verification fails, the NvM_WriteBlock interface is called again to write the data. The number of attempts is usually set to 3. If all 3 attempts fail, the Dem module is notified to record the corresponding DTC.

[0161] For ordinary data, the NVM Block Management Type uses the NATIVE type, meaning that each data item is stored only once. For critical data, the NVM Block Management Type uses the REDUNDANT type, meaning that each data item is stored twice. Upon power-up, the two copies of the data are verified. If the verification fails, the default value is used, and the Dem module is notified to record the corresponding DTC.

[0162] The code generation of the NvM_L module is achieved by importing the NvM_L configuration Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool". The NvM_L configuration spreadsheet is shown in Table 9, which defines the storage strategy, Flash address and verification method of key BMS data to ensure that data is not lost when power is off. An example of filling in the NvM_L configuration spreadsheet is shown in Table 10.

[0163] Table 9

[0164] Table 10

[0165] The differences between NvM_L and the standard AUTOSAR NvM are as follows: (1) Layered reconstruction of data storage paths. The standard AUTOSAR NVM adopts a strict five-level call stack of "application layer → NvM → MemIf → Fee → Fls". All data is allocated and worn down through the FEE module, and the application layer is prohibited from directly manipulating physical storage addresses.

[0166] This invention innovatively constructs a dual-path storage architecture: For core parameters such as current calibration data and BMS serial number, a direct write mode is adopted that "skips the FEE and directly calls the Fls interface," and the data is written to a fixed physical address in DFLASH. This "hardware bypass" mechanism reduces intermediate layer latency by 40% while avoiding the risk of critical data corruption that may be caused by dynamic address allocation in the FEE module.

[0167] For ordinary data such as SOC and DTC, the standard path of "FEE abstraction layer + periodic synchronization" is still retained, and wear leveling is achieved through FEE block management. This tiered strategy satisfies the real-time requirements of critical data while ensuring the storage lifespan of ordinary data.

[0168] (2) Scenario-based innovation of dynamic storage strategies.

[0169] In terms of data write triggering mechanism, this design breaks through the generalized design framework of standard NVM and adopts a threshold-triggered SOC storage mechanism. Standard NVM only supports storage triggering methods with fixed periods or explicit calls. This design innovatively introduces a SOC change threshold (>3%) as a trigger condition, combined with the periodic write mechanism of FEE, reducing the storage frequency of SOC data by more than 60%. Through the coordinated scheduling of the NvM_WriteBlock interface and the Fee_Mainfunction, it avoids SOC jumps caused by software resets and reduces the wear and tear on DFlash caused by invalid writes.

[0170] In some embodiments of the present invention, the architecture of the target E2e adopts an architecture of configuration parsing, core processing, code generation and interface adaptation; The target E2e is specifically used for: After obtaining the CAN message from the Com layer, the signal that needs to be protected is filtered, the frame header is assembled, the CRC is calculated and appended to the array before being sent. And after obtaining the message from the CAN driver, parse the frame header, perform CRC check, determine the error type, and return the result; It also maintains an error counter, automatically reporting errors when the number of errors exceeds the configured threshold, and automatically clearing the error counter after N consecutive successful verifications.

[0171] The target E2e is an end-to-end protection module (E2e_L). Its core function is to provide end-to-end protection for CAN signals. Through CRC verification, counter monitoring, and other methods, it ensures that the signals are not tampered with or lost during transmission, thereby improving communication reliability.

[0172] It adopts a four-layer architecture of "configuration parsing - core processing - code generation - interface adaptation". The configuration parsing layer parses Excel configurations and extracts signals and E2E parameters; the core processing layer implements the sending / receiving logic, CRC calculation, and error handling; the code generator automatically generates adaptation code; and the interface adaptation layer interfaces with COM, CAN drivers, and DEM modules. It supports visual configuration in Excel (no ARXML syntax required) and custom CRC algorithms. Users can specify custom CRC function paths in Excel, and the tool automatically binds the functions without modifying the core logic, resulting in stronger adaptability.

[0173] The E2e_L module adopts a four-layer architecture of "configuration parsing - core processing - code generation - interface adaptation", as follows: Configuration parsing layer: Parses the Excel configuration, extracts information such as signal list, E2E parameters, and CRC algorithm, and generates an intermediate configuration structure.

[0174] Core processing layer: Implements E2E sending / receiving logic, CRC calculation, error checking and handling.

[0175] Code generator: Automatically generates adaptation code (send / receive functions, CRC binding, error mapping, etc.) based on intermediate configuration.

[0176] Interface adaptation layer: interfaces with the COM layer (retrieves CAN messages), CAN driver (sends messages), and DEM module (reports errors).

[0177] By adopting a multi-sheet structured configuration, the user's operational threshold is reduced (no need to master ARXML syntax), as shown in Table 11: Table 11

[0178] The E2E transmission logic (based on configuration driver) is as follows: Signal filtering: After obtaining CAN messages from the Com layer, the signals that need to be protected are filtered according to the "Enable E2E" flag in SignalConfig, and an array to be verified is formed.

[0179] Frame header assembly: Automatically add DataId (to distinguish different signal groups) and Counter (incrementing counter) according to E2EProfileConfig.

[0180] The counter width is configurable (1-8 bits), and it automatically rewinds when it exceeds the range.

[0181] CRC Calculation: Based on CRCSettings, the corresponding algorithm (built-in lookup table method / user-defined function) is called to generate a check value and append it to the array.

[0182] Send trigger: Pass the assembled array to the CAN driver to complete the transmission.

[0183] The E2E receiving logic (based on configuration driver) is as follows: Frame header parsing: After obtaining the message from the CAN driver, the DataId (verify the legality of the signal combination) and Counter (check the continuity) are parsed according to E2EProfileConfig.

[0184] CRC check: Extract the CRC value from the message, call the corresponding algorithm to recalculate it, and compare the check results.

[0185] The following errors were detected: If the CRC does not match: trigger E2E_ERR_CRC (corresponding to the error code in ErrorHandling).

[0186] If the Counter exceeds the window range: trigger E2E_ERR_COUNTER.

[0187] Results feedback: The verification result (success / error code) and the original signal data are passed to the application layer, and errors are reported through the DEM module (when the number of errors reaches the threshold in ErrorHandling).

[0188] The error handling mechanism is as follows: Error logging: Maintain error counters (distinguished by signal group + error type), and record the number of consecutive errors and the total number of errors.

[0189] Intelligent reporting: When the number of errors exceeds the "reporting threshold" configured in ErrorHandling, the Dem_ReportError() interface is automatically called to avoid system overhead caused by frequent reporting.

[0190] Recovery mechanism: If the verification is successful N times consecutively (configurable), the corresponding error counter will be automatically cleared.

[0191] The CRC algorithm is adapted as follows: Built-in algorithm: Supports AUTOSAR standard CRC (such as CRC8, CRC16), implemented by table lookup (reusing the user-provided crc8Table_1D).

[0192] Custom extension: Users can specify a custom CRC function path in Excel's CRCSettings, and the code generator will automatically bind the function without modifying the core logic.

[0193] The code generation process is as follows: Configuration Import: Users import Excel files through the tool and configure the parser to perform format validation (such as required field checks and numerical range checks).

[0194] Intermediate code generation: The parser converts Excel data into structured intermediate configurations (C language structures). Example: / / Automatically generated configuration structure (example) typedef struct { uint32 CanId; / / 0x123 uint8SignalCount; / / 3 (These 3 signals under this CAN ID require E2E protection) E2E_SignalType Signals[3]; / / Signal details (extracted from SignalConfig) E2E_ProfileType Profile; / / Profile parameters (DataId=0x01, CounterWidth=4bit) E2E_CrcType CrcConfig; / / CRC8, initial value 0x00, XOR value 0x00 E2E_ErrorType ErrorConfig; / / CRC error code = 0x01, counter error code = 0x02 E2E_ConfigType; Target code generation: The code generator automatically generates code based on intermediate configuration and templates. Send / receive functions (binding specific CAN IDs to signals); CRC algorithm adaptation code (built-in / custom function calls); Error handling and DEM reporting codes.

[0195] Integration output: The generated code is output as a standalone file (such as E2E_Generated.c / h) and can be directly integrated into existing projects.

[0196] The differences between E2e_L and standard AUTOSAR E2E are as follows: (1) Configuration method: The standard AUTOSAR E2E relies on ARXML files + dedicated toolchain, which has a high learning cost. However, this application uses Excel to generate E2E code, which supports operation by non-professionals and lowers the threshold.

[0197] (2) Profile flexibility: The standard AUTOSAR E2E profile (such as Profile 1 / 2 / 4) is fixed and difficult to extend, while this application supports custom profile parameters (DataId / Counter / CRC can be freely configured).

[0198] (3) CRC algorithm scalability: The standard AUTOSAR E2E only supports standard algorithms, and custom algorithms require modification of the underlying code. However, this application supports user-defined algorithms (without changing the core logic).

[0199] In some embodiments of the present invention, the dynamic code is generated in the following manner: Fill the valid data from the customer diagnostic questionnaire into a pre-formatted Excel spreadsheet to obtain an Excel spreadsheet with the diagnostic configuration items filled in. Import the Excel spreadsheet with the diagnostic configuration items filled in into the preset LBMS software configuration and analysis tool to generate the dynamic code.

[0200] DCM is for diagnostic communication management, and Dem is for diagnostic event management. In standard AUTOSAR development, DCM and Dem require manual editing of the Cdd (Diagnostic Description Database) or Odx (Open Diagnostic Exchange Format) diagnostic database, which relies on commercial AUTOSAR configuration tools. There are many configuration items (such as the Did parameter of DCM and the DTC attribute of Dem). Developers need to be proficient in the module details, otherwise it is easy to make configuration errors, resulting in code generation failure, low development efficiency and high threshold.

[0201] The optimization scheme provided by this invention is as follows: Simplified configuration input: Valid data from the LBMS diagnostic questionnaire provided by the customer (including Did requirements, DTC definitions, etc.) is filled into a standardized Excel spreadsheet. Dcm corresponds to the Did configuration table (defining Did ID, number of signals, associated signals, etc.), and Dem corresponds to the DTC configuration table (defining DTC values, severity levels, functional units, etc.). It also supports AI tools to assist in generating tables (because Did / Dtc attributes are similar, repetitive formats can be filled in batches through AI), reducing the difficulty of configuration.

[0202] Automatic code generation: Import the completed Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool". The tool automatically parses the spreadsheet data and generates dynamic code for Dcm and Dem, such as the Dcm_DspDidCfg structure of Dcm (which stores the Did configuration) and the DemDTC array of Dem (which stores the DTC configuration). There is no need to manually adjust the configuration items, eliminating the need for commercial tools and saving development time.

[0203] For the diagnostic-related Dcm and Dem modules, in order to reduce reliance on commercial AUTOSAR configuration tools, this application refers to the AUTOSAR specification and uses the "LBMS software configuration and analysis tool" to generate the dynamic code for the Dcm and Dem modules.

[0204] The standard AUTOSAR configuration tool's process for generating dynamic code for Dcm and Dem modules involves manually editing the Cdd or Odx diagnostic database, importing it into the AUTOSAR configuration tool, adjusting configuration items based on tool errors, and then generating the code. This standard AUTOSAR development process has three drawbacks: 1. The AUTOSAR configuration tool architecture is expensive; 2. Manually editing the Cdd or Odx diagnostic database is time-consuming; 3. Adjusting configuration items based on tool errors places high demands on developers, requiring them to be very familiar with the functions of each option in AUTOSAR Dem and Dcm. If an option is configured incorrectly, the corresponding dynamic code cannot be generated.

[0205] The approach in this application is as follows: Based on the client's LBMS diagnostic questionnaire, the valid data from the questionnaire is filled into an Excel file in a specified format. Since the Did / Dtc attributes in the diagnostic questionnaire are similar, free AI tools can be used to assist in generating the Excel spreadsheet, thereby improving the efficiency of Excel spreadsheet creation. After the Excel spreadsheet is completed, it is directly imported into the underlying code configuration tool to generate DCM and Dem dynamic code, without the need for manual adjustment of configuration items, thus saving development time.

[0206] Table 12

[0207] Table 12 shows a partial configuration Excel spreadsheet for the Dcm module. Importing the configuration Excel spreadsheet for the Dcm module into the "LBMS Software Configuration and Analysis Tool" will generate the dynamic code for the Dcm module as shown below.

[0208]

[0209] Table 13

[0210] Table 13 shows the configuration Excel spreadsheet for some DTCs corresponding to the Dem module. Importing the DTC configuration Excel spreadsheet into the "LBMS Software Configuration and Analysis Tool" will generate the dynamic code for the Dem module as shown below.

[0211]

[0212] Furthermore, the RTE is a runtime environment that serves as a bridge connecting the BSW (base software) and ASW (application software). Code generation relies entirely on the configuration table: First, fill out the "BSW-ASW Interface Table" according to project requirements. The table defines all interaction interfaces (including CAN message transmission and reception interfaces, AFE input / output interfaces, NVM input / output interfaces, GPIO and ADC sampling interfaces, DTC trigger interfaces, etc.). Then, import the table into the "LBMS Software Configuration and Analysis Tool." The tool automatically generates the corresponding RTE interface functions based on the interface type—such as the CAN message reception interface function (the application layer obtains the received signal by calling this function, such as Rte_IRead_ASW_Mainfunction_10ms_CANI_SocCalEnable_SR_RP) and the DTC trigger interface function (the application layer sets the DTC status by calling this function, such as Rte_Call_DIAG_CellOvLev1_CS_RP_SetEventStatus). The application layer does not need to pay attention to the underlying implementation; it can achieve data interaction with the BSW simply by calling the RTE functions, reducing inter-layer coupling.

[0213] Table 14

[0214] For the RTE module, the RTE module code is generated by importing the "BSW-ASW Interface Table" into the "LBMS Software Configuration and Analysis Tool". The generation of the RTE module code depends on the "BSW-ASW Interface Table," as shown in Table 14, which contains an example of a CAN message received from the "BSW-ASW Interface Table." Before generating the RTE code, the "BSW-ASW Interface Table" is filled out according to project requirements. Then, the table is imported into the "LBMS Software Configuration and Analysis Tool," which generates the required interface code based on the table content. The following is an example of CAN message reception code, which will periodically be called in the application layer software to retrieve data. Other RTE functions, such as CAN message transmission, AFE input / output, NVM input / output, GPIO, and ADC sampling, are generated using a similar RTE code generation method to CAN message reception.

[0215] Boolean Rte_IRead_ASW_MainFunction_10ms_CANI_SocCalEnable_SR_RP_CANI_SocCalEnable_SR_RP(void) { return CanRxSignal_Struct_Data.PC_Cal_SocCalEnable_Valid; } UInt8 Rte_IRead_ASW_MainFunction_10ms_CANI_SocCalValue_SR_RP_CANI_SocCalValue_SR_RP(void) { return CanRxSignal_Struct_Data.PC_Cal_SocCalValue_Valid; } Table 15 shows an example of DTC triggering from the "BSW-ASW Interface Table". To trigger a DTC, import the table shown in Table 15 into the "LBMS Software Configuration and Analysis Tool". The "LBMS Software Configuration and Analysis Tool" generates the required interface code based on the fault signal name and Event ID. The following is an example of DTC triggering code. In the application layer software, the following function will be periodically called to set up the DTC recording function.

[0216] Std_ReturnType Rte_Call_DIAG_CellOvLev1_CS_RP_SetEventStatus(constDem_EventStatusType EventStatus) { return Dem_SetEventStatus(1, EventStatus); } Std_ReturnType Rte_Call_DIAG_CellOvLev2_CS_RP_SetEventStatus(constDem_EventStatusType EventStatus) { return Dem_SetEventStatus(2, EventStatus); } Table 15

[0217] The AUTOSAR-based LBMS underlying software architecture provided by this invention is described in detail below from four major scenarios: "startup process", "normal operation", "sleep and wake-up" and "fault handling".

[0218] (1) Startup process: the entire interaction from hardware power-on to system readiness.

[0219] The startup process is the core stage of module initialization and state coordination. With Os_L as the scheduling center and EcuM_L as the state management core, each module is activated step by step according to priority, ensuring end-to-end coordination from hardware power-on to system readiness. The specific connection logic is as follows: Hardware power-on and low-level initialization: After Os_L is powered on, the startup code is executed first to initialize the MCU core (clock, stack), and then the MCAL module initialization function is called according to the "peripheral initialization sequence" configured in Excel (priority order: Port→Spi→Can→Adc→AFE→SBC).

[0220] MCAL module: Os_L calls Port_Init() (configures GPIO direction), Spi_Init() (initializes AFE, SBC, and CanTrcv communication interfaces), Can_Init() (configures CAN baud rate and filtering), and Adc_Init() (activates voltage sampling channel) in sequence.

[0221] Complex driver: Initialize the three peripheral devices SBC, AFE, and CanTrcv to ensure that the hardware interface is ready.

[0222] System state management activation: Os_L calls EcuM_L_Init, EcuM_L initializes the three-state machine (enters "startup state" by default) and starts wake-up source detection. It calls AFE_CheckWakeup to detect battery-related wake-ups (such as overvoltage / overcurrent, hardware debounce 50ms), calls Can_CheckWakeup to detect CAN wake-up (network management message), and reads GPIO registers to detect hard-wired wake-up (such as tailgate button signal). After confirming the wake-up source, it prepares to switch states.

[0223] Diagnostics and Storage Readiness: Os_L calls Dcm_Init and Dem_Init. Dcm loads the dynamic code generated by the tool (such as Dcm_DspDidCfg), Dem loads the DTC configuration (such as the DemDTC array) and initializes the fault storage area through Dem_InitializeDTC().

[0224] At the same time, CanTp_L_Init is called, CanTp_L loads diagnostic transmission parameters (such as N_As timeout 500ms, 3 retries), and establishes a direct interactive channel with Dcm (CanTp_L_RegisterDcmCallback()).

[0225] In the first 100ms task, Os_L calls NvM_L_Init. NvM_L reads key data from DFLASH (such as current calibration value) and performs CRC16 verification, storing it in the RAM buffer. If the verification fails, the default value is used and Dem is reported.

[0226] System readiness confirmation: After EcuM_L switches to "running mode", it calls WdgM_L_Enable. WdgM_L configures the SBC window watchdog (total cycle 1024ms, 512ms before window closing).

[0227] After all modules are initialized, Os_L sets the global flag System_Ready=1. The application layer obtains the ready status through Rte_Read_SystemStatus and starts the core control logic such as cell balancing and charge / discharge management, thus completing the startup process.

[0228] (2) Normal operation (coordination logic of periodic tasks and real-time interaction): During the normal operation phase, the Os_L periodic scheduling serves as the framework. Each module executes its function according to a period of 10ms / 20ms / 100ms. At the same time, real-time events are handled through interrupts to ensure the stable operation of the core functions. The specific connection logic is as follows: 10ms high-frequency task: Os_L triggers scheduling once every 10ms, calling the module main function in the order of "CanNm_L→Com_L→CanTp_L→WdgM_L→NvM_L→E2e_L→Asw_Mainfunction→Dcm→Fee→Fls→MCAL→AFE" (CanNm_L must be placed first to avoid inaccurate CanNm message period during fast transmission).

[0229] Com_L handles CAN message transmission and reception (packet assembly and Can_Write call during transmission, array data parsing and passing to RTE during reception); WdgM_L performs dog-feeding operation and program flow monitoring; NvM_L detects SOC changes, triggering storage if it exceeds 3%; E2e_L performs CRC check on CAN signals and monitors the counter; other modules handle data processing and hardware interaction.

[0230] Com_L and CAN drivers: Sending: Com_L checks the 10ms periodic message flag (e.g., Rte_ASW_CANO_Struct_Data.CAN_SendSignal_10ms_Cnt1000), assigns the RTE data (e.g., Rte_ASW_CANO_Struct_Data.CANO_DischrgMosTemp_SR_PP) to the Tx_LBM_334_Msg structure, and calls Can_Write(5,&PduInfo_Temp) to send; Reception: The CAN driver writes the received message to RxMsg_0xB0_Buf through Can_Callback(), and Com_L parses the array data (such as CanRxSignal_Struct_Data.PC_Cal_SocCalEnable_valid= RxMsg_0xB0_Buf[2]&0x01), and updates the application layer data through Rte_Write_ASW_Data().

[0231] E2e_L and Com_L: For signals with E2E enabled (such as SOC values), Com_L calls E2e_L_Protect(&SocSignal,&ProtectedData) before sending, and E2e_L adds DataId=0x01, Counter (auto-increment), and CRC8 value; when receiving, Com_L calls E2e_L_Validate(&RxData,&Result), and if the CRC check fails, E2e_L reports it through Dem_ReportError(DTC_E2E_CRC_ERR).

[0232] WdgM_L and SBC: WdgM_L checks the system time (via Stm_GetCurrentTime()). If it's within the open window (768ms~1024ms), it calls SBC_WdgRefresh() to feed the watchdog. Simultaneously, before each monitoring point, it verifies the counter value (if expected to be 1, the verification passes). If the verification passes, the counter is incremented by 1; otherwise, it is reset to zero and reported to the Dem module. After the entire process is complete, the counter is reset, and the monitoring continues cyclically.

[0233] CanNm_L and CAN driver: CanNm_L checks the NM message transmission period (100ms). If the time is reached, it assembles the message and calls Can_Write(6,&NmPdu) to send it. At the same time, it detects the received NM messages and updates the local network status (such as recording that the node is online and processing wake-up requests).

[0234] NvM_L and Fee / Fls: If the SOC change is greater than 3% (detected by Rte_Read_SOC_Change()), NvM_L calls NvM_L_WriteBlock(NVM_BLOCK_SOC,&SocData) to write to DFLASH through the Fee module (Fee calls Fls_Write() in the main function).

[0235] Dem module: Scans faults reported by each module (such as DTC_CANTP_TIMEOUT) and updates the DTC status (such as from "Pending Confirmation" to "Stored") for diagnostic queries.

[0236] 20ms Intermediate Frequency Task: Os_L schedules EcuM_L and the SOC calculation function every 20ms. EcuM_L performs state management (such as detecting sleep conditions), and the SOC calculation function calculates the current SOC value based on the Adc sampling data and synchronizes it to RTE for use by other modules.

[0237] 100ms low-frequency task: Os_L schedules Idle Task every 100ms to perform non-core functions such as LED lighting, reducing high-frequency resource consumption.

[0238] Real-time event triggering (interrupt-level interaction): After the CAN controller receives a message, it triggers an interrupt. The Can_Callback function directly calls CanTp_L_RxIndication (diagnostic message) or Com_L_RxIndication (normal message) to write the data into the buffer of the corresponding module, avoiding real-time problems caused by the delay of periodic tasks.

[0239] (3) Sleep-wake (low-power switching): The sleep-wake process is dominated by EcuM_L, CanNm_L manages the network state, and Os_L controls the start and stop of tasks, so as to achieve a balance between low power consumption and fast wake-up. The specific connection logic is as follows: Sleep preparation: EcuM_L periodically checks the sleep conditions (such as no wake-up source, no application layer running requirements) through EcuM_L_CheckSleepCondition. After confirming that the conditions are met, it starts the power-down process, calls NvM_L_Flush, and NvM_L writes the cached data (such as the latest DTC, SOC) to DFLASH through Fee_WriteBlock. After completion, it reports the status. EcuM_L then calls Os_L_StopScheduling. Os_L stops the 10ms / 20ms / 100ms tasks, sets System_Ready=0, and reports the task stop status.

[0240] Entering Sleep (Low Power Mode): EcuM_L selects the mode based on the sleep command before power-down from the application layer. If the sleep command is a shallow sleep, it calls the corresponding interface of the AFE to put it into shallow sleep mode (enabling sleep mode sampling, overvoltage wake-up, overcurrent wake-up, and overtemperature wake-up), and calls the corresponding interface of the SBC to enable its timed wake-up function. If the sleep command is a deep sleep, it calls the corresponding interface of the AFE to put it into deep sleep mode (disabling sleep mode sampling, overvoltage wake-up, overcurrent wake-up, and overtemperature wake-up), and calls the corresponding interface of the SBC to disable its timed wake-up function. After the sleep mode is set, it calls the corresponding interface of the SBC to put the SBC into Standby mode, shuts down its power output, and the LBMS enters low-power sleep state.

[0241] Wake-up trigger: Based on the AFE / SBC configuration before hibernation, LBMS can be woken up by AFE (battery failure), SBC (timed or hardwired), or CanTrcv (CAN message); after waking up, the startup process is automatically executed, starting from hardware initialization to gradually activate each module and restore normal operation.

[0242] (4) Fault handling (collaboration in abnormal scenarios): Fault handling needs to cover scenarios such as communication abnormalities, data errors, and program abnormalities. Each module records faults uniformly through the Dem module to ensure that the problem is traceable. At the same time, recovery operations are performed to reduce the impact of faults. The specific connection logic is as follows: CAN Busoff fault (hardware communication interruption): CanNm_L directly reads the CAN controller register (e.g., CANx_ESR.BOFF = 1) in the 10ms task to detect the Busoff status; after detecting Busoff, it immediately calls the RecoverBusOff function (operating on the CANx_MCR.RESET bit) to reset the CAN controller and starts a 100ms recovery timer.

[0243] After the timer expires, Can_Init is called to reinitialize the CAN driver. If the initialization fails three times in a row, Dem_ReportError is called to report the DTC (such as DTC_CAN_BUSOFF) and the fault is recorded.

[0244] NVM data verification failure (storage reliability issue): When NvM_L reads data, it compares the calculated CRC value with the CRC value stored in DFLASH. If the verification fails, it calls Dem_ReportError to report a DTC (such as DTC_NVM_CRC_ERR), while using the default value (such as default SOC=50%) to ensure the normal operation of the system.

[0245] When writing data, NvM_L_WriteBlock is called and the data is immediately read for verification. If the verification fails, the data will be retried (up to 3 times). If the data still fails, DTC_NVM_WRITE_ERR will be reported.

[0246] Critical data (such as calibration values) is stored redundantly (two copies of the data). If both fail to be verified, DTC_NVM_CRITICAL_ERR is reported.

[0247] Watchdog timeout (program crash or deadlock): If the program fails to feed the watchdog during the WdgM_L window period (e.g., 10ms task deadlock), the SBC triggers a hardware reset; after the MCU restarts, WdgM_L reads the SBC reset reason register (e.g., SBC_RST_REASON=WDG_TIMEOUT) during the initialization phase, confirms the watchdog timeout, and then calls Dem_ReportError to report the DTC (e.g., DTC_WDG_TIMEOUT).

[0248] In addition, if the counter verification fails during program flow monitoring (such as an abnormal charge / discharge protection process), WdgM_L clears the counter and reports DTC_PROG_FLOW_ERR.

[0249] Diagnostic message transmission error (UDS protocol anomaly): When CanTp_L receives diagnostic messages, if the sequence number of consecutive frames is incorrect (e.g., expected = 1, actual = 3), it calls CanTp_L_SendNegativeResponse to send a protocol error negative response (e.g., 0x24) and reports DTC_CANTP_PROTOCOL_ERR.

[0250] After sending the first frame (FF), if no flow control frame (FC) is received within 500ms, an N_As timeout is triggered, DTC_CANTP_TIMEOUT is reported, and a retransmission is triggered (up to 3 times). If the retransmission fails, the transmission is terminated and the fault is recorded.

[0251] The software integration, testing, and optimization are as follows: Software integration and compilation: Copy all module code (dynamic and static code of the 9 MCAL modules Fee, Stm, Spi, Can, Ir, Adc, Dio, Port, Fls; code of the 3 complex driver modules AFE, SBC, CanTrcv; dynamic and static code of Dcm and Dem; code generated by the 8 modules Os_L, EcuM_L, CanTp_L, Com_L, CanNm_L, NvM_L, WdgM_L, and E2e_L; RTE_L code and application layer code) into the compiler (such as Keil or IAR), configure compilation parameters (such as MCU model and memory address), and generate an executable file (hex format).

[0252] HIL testing: Download the generated hex file to the LBMS hardware, build a test environment through HIL (Hardware-in-the-Loop) devices, simulate the vehicle's operating conditions (such as charging and discharging, CAN communication, and fault injection), and verify the correctness of the functions of each module (such as CAN transmission and reception, data storage, and fault handling) and the connection logic (such as startup, hibernation, and fault recovery).

[0253] Integration testing: After HIL testing is passed, integration testing is performed using tools such as VECTOR CAST to generate code coverage reports (including statement coverage and branch coverage), detect uncovered code segments and logical branches, and ensure code execution integrity.

[0254] The optimization strategy (based on test results) involves code optimization based on the integration test coverage report, functional verification results, and the "LBMS software configuration and analysis tool." The core strategy is as follows: Unused code deletion: Filter functions or modules with "zero coverage" from the coverage report. For example, if a function (such as Dcm_CopyRxData_CheckProtocol) is not called in all test scenarios and is an early reserved function that does not actually need to be implemented, delete the function directly; if a module branch (such as redundant handling of extreme failures) is almost impossible to trigger in actual scenarios, delete the branch logic and reduce the .text code segment.

[0255] Functional Redundancy Merging: When duplicate functional modules are found during testing, they are merged. For example, if two SWCs (software components) A and B both implement the "voltage signal filtering" function and have the same algorithm but different parameters, the filtering function of one SWC is retained and the parameter configuration (such as filter_param) is added, while the redundant function of the other SWC is deleted. The calling relationship is modified to call the retained function through the RTE interface, reducing redundancy in the .text and .rodata sections (parameter constants).

[0256] Streamlined communication code: Optimize communication logic based on test interface interaction data. For example, instead of SWC3 calling Rte_Call_Swc4_GetData 100 times per second via RTE and only getting 1 byte of data each time, it is now batched (getting 10 bytes at a time), reducing the number of calls. As a result, the call code generated by RTE (parameter validation, signal transmission) is reduced, thus reducing the .text segment size.

[0257] Debug / log code trimming: Remove test-specific debug code, such as Debug_PrintAllSignals (which prints all signal values). This function is only used for test verification and is not called in production scenarios. Wrap this function with conditional compilation (#ifdef DEBUG_MODE). After the integration test passes, turn off DEBUG_MODE. The compiler will automatically remove this function and associated string constants, freeing up FLASH space.

[0258] Calibration data optimization: The storage strategy was adjusted for low-frequency functions. For example, the ECU factory calibration function is only called during the production stage. The test found that it used a "space-for-time" strategy (pre-calculating a large number of lookup tables). It was changed to a "time-for-space" scheme (real-time calculation). The pre-calculated array in the .rodata segment was deleted, sacrificing a small amount of production efficiency to save FLASH.

[0259] Regression testing requires re-executing HIL tests and integration tests on the optimized source code: HIL tests verify the correctness of the functionality (especially whether the interaction logic of the modified module is normal), and integration tests verify whether the code coverage meets the standards and whether the optimized code introduces new problems.

[0260] The AUTOSAR-based LBMS underlying software architecture provided by this invention has the following advantages: 1. Significantly reduce MCU FLASH memory usage by removing redundant modules (such as MemIf, Nm, PduR, BswM, etc.), integrating functions (such as merging CRC into E2e_L), and simplifying module implementation (such as replacing AUTOSAR OS with time-slice Os_L). The streamlined modules (such as simplifying EcuM_L to a three-state model and removing multi-protocol support from Com_L) further reduce code redundancy.

[0261] 2. Reduce development costs and complexity, and improve development efficiency by developing an "LBMS software configuration and analysis tool." This tool uses Excel spreadsheets for configuration instead of ARXML and commercial tools, supporting operation by non-professionals and reducing reliance on expensive tools. The diagnostic modules (Dcm, Dem) dynamically generate code based on Excel files converted from customer questionnaires, avoiding manual editing of complex databases and reducing configuration errors and development time.

[0262] 3. Optimize system performance to adapt to LBMS scenario requirements and simplify the startup process (e.g., change EcuM_L initialization from "multi-level waiting" to "linear execution") to shorten LBMS startup time. The communication modules (Com_L, CanTp_L) adopt direct mapping of "signal-structure-hardware driver" to reduce intermediate layer conversion and lower communication latency; CanNm_L directly operates on hardware registers to improve CAN Busoff recovery speed.

[0263] 4. Enhanced system reliability and flexibility: NvM_L employs a dual-path storage architecture (critical data is directly written to a fixed DFLASH address, while ordinary data is managed via FEE), balancing real-time performance and storage lifespan; it introduces CRC checksums and redundant storage to improve data reliability. E2E_L supports custom profiles and CRC algorithms to adapt to the diverse signal protection requirements of LBMS; WdgM_L uses a window watchdog and program flow monitoring to prevent program deadlocks or crashes.

[0264] 5. Extremely streamlined code: Based on integration test results, tools are used to locate unused code, redundant functions, and inefficient interfaces, and targeted optimizations are made (such as deleting zero-coverage functions and merging duplicate functions) to further streamline the code and reduce MCU FLASH memory usage.

[0265] The AUTOSAR-based LBMS underlying software architecture provided by this invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. An AUTOSAR-based LBMS underlying software architecture, characterized in that, include: MCAL module, complex driver module, diagnostic module, and management module; The MCAL module includes Fee, Stm, Spi, Can, Ir, Adc, Dio, Port, and Fls from the AUTOSAR architecture; The complex driving module includes AFE, SBC, and CanTrcv in the AUTOSAR architecture; The diagnostic module includes Dcm and Dem, which are implemented using static and dynamic code separation. The management module includes target Os, target EcuM, target CanTp, target Com, target CanNm, target NvM, target WdgM, and target E2e, which have been redesigned based on LBMS requirements. The target E2e is also used to implement the CRC verification function; The target CanTp, the target Com, and the target CanNm are also used to implement the Can interface function of CanIf; The target CanNm is also used to implement the communication mode switching function of ComM and the CAN Busoff function of CanSM.

2. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target Os is scheduled using a time-slice scheduling method; The target Os is specifically used for: During the power-on initialization phase, the hardware interfaces of CAN, SPI, ADC and GPIO are initialized sequentially according to configuration priority. During the periodic task management phase, a clock extraction method is implemented based on the system timer to classify tasks according to their periods; the tasks include at least 10ms high-frequency core tasks, 20ms medium-high frequency tasks, and 100ms low-frequency tasks; For scenarios with high real-time requirements, an interrupt mechanism is used to handle the situation, and the latency is controlled within 1ms.

3. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target WdgM uses an SBC-integrated window watchdog; The total period of the target WdgM is 1024ms, of which the first 512ms is the closed window period and the last 512ms is the open window period; feeding the dog during the closed window period is ineffective, while feeding the dog during the open window period is effective. The target WdgM is specifically used for: In the 10ms task, WdgM_Mainfunction is called to automatically execute the dog-feeding instruction when the window period reaches 50% of the time point; and a global counter is allocated to the critical process for program flow monitoring. Before each monitoring point is executed, the counter value is checked. If the check passes, the counter is incremented by 1. If it fails, it is cleared and reported to Dem.

4. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target EcuM adopts a simplified three-state model; The target EcuM is used to retain three core states; the core states include state transition condition configuration, wake-up source management and hibernation process management; the wake-up sources include at least battery-related wake-up, external wake-up and timed wake-up.

5. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target COM is used for CAN message transmission, CAN message reception, and communication timing management between LBMS and an external CAN. The CAN message transmission includes: defining a structure for each frame of message transmission based on DBC information, assigning the corresponding data in RTE to the structure in a periodic task, and sending the message by calling the Can_Write function; The CAN message reception includes: periodically executing the Com_Mainfunction function in a periodic task, parsing the received message data, and then passing it to the application layer via RTE; The communication timing management includes: using a System timer to time periodically sent messages and executing the sending after the sending period is reached; and executing the sending of event-type messages based on event conditions.

6. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target CanTp is used to process the segmentation or reassembly of CAN diagnostic messages; The target CanTp is specifically used for: CanTp message reception, CanTp message transmission, and error handling mechanism; The CanTp message reception includes: periodically executing the CanTp_Mainfunction function in a periodic task to parse the received message data and reassemble the segmented frames into the original SDU in order; The CanTp message transmission includes: packetizing the data to be sent, and splitting data exceeding the transmission length of one frame into multiple CAN frames for transmission; The error handling mechanism includes timeout error handling and protocol format error handling, and sends corresponding negative response messages.

7. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target CanNm is used to manage the active or sleep state of the CAN bus, and the state is switched according to the LBMS mode in CanNm_Mainfunction; The target CanNm is also used to access the CAN controller hardware registers to determine the Busoff status and call the hardware-bound RecoverBusOff() function to restore Busoff.

8. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target NvM adopts a dual-path storage architecture; The target NvM is specifically used for: The direct write mode, which skips FEE and directly calls the Fls interface, is used to write critical data to a fixed physical address in DFLASH. Using the FEE abstraction layer and the standard path of periodic synchronization, write ordinary data; All NVM Blocks use CRC16 verification, and critical data is stored in duplicate using the REDUNDANT type.

9. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The target E2e architecture adopts a configuration parsing, core processing, code generation, and interface adaptation architecture. The target E2e is specifically used for: After obtaining the CAN message from the Com layer, the signal that needs to be protected is filtered, the frame header is assembled, the CRC is calculated and appended to the array before being sent. And after obtaining the message from the CAN driver, parse the frame header, perform CRC check, determine the error type, and return the result; It also maintains an error counter, automatically reporting errors when the number of errors exceeds the configured threshold, and automatically clearing the error counter after N consecutive successful verifications.

10. The LBMS underlying software architecture based on AUTOSAR according to claim 1, characterized in that, The dynamic code is generated in the following way: Fill the valid data from the customer diagnostic questionnaire into a pre-formatted Excel spreadsheet to obtain an Excel spreadsheet with the diagnostic configuration items filled in. Import the Excel spreadsheet with the diagnostic configuration items filled in into the preset LBMS software configuration and analysis tool to generate the dynamic code.

Images