Static allocation method for stack space in battery management system and battery management system

Abstract

The invention discloses a stack space static distribution method in a battery management system and the battery management system, relates to the technical field of battery management, and aims to solve the problem of shared stack peak value superposition caused by sudden fault trigger diagnosis deep call under static stack division and periodic monitoring interruption concurrence. A stack description table is generated in a compiling and linking stage, and a stack pointer is redirected according to an execution entity during operation, so that monitoring type and diagnosis type execution streams are operated on a physically isolated stack space, the stack expansion of one execution stream is prevented from occupying the stack frame of the other execution stream, and the stack overflow risk caused by instantaneous resource conflict is weakened from the source; a stack switching mechanism of an interrupt preamble code is introduced, so that an interrupt service routine is executed on a pre-planned interrupt stack storage area, and when the interrupt exits, the interrupt service routine is recovered to a stack to which an interrupted execution stream belongs, so that interrupt stack occupation is converted from scattered superposition to task stacks to centralized planning to interrupt stacks.

Description

Technical Field

[0001] This invention relates to the field of battery management technology, and in particular to a method for static allocation of stack space in a battery management system and a battery management system. Background Technology

[0002] In automotive-grade battery management systems (BMS), to meet real-time and verifiability requirements, most current operating systems and software resources are deployed using static configuration. For example, AUTOSAROS is a statically configured automotive-grade operating system that facilitates real-time performance inference. Due to limitations in the on-chip SRAM capacity of microcontrollers, the stack space for task / interrupt contexts needs to be planned during the system design phase. In engineering, stack usage analysis and stack boundary detection mechanisms are often used to mitigate risks. For example, specific markers are placed at the upper and lower boundaries of the stack, and checks are performed during task switching to detect some stack overflow / underflow faults.

[0003] However, to save RAM, some solutions introduce stack sharing / shared interrupt stack / or place specific diagnostic logic in a context that can be preempted with high priority. When multiple contexts are preempted and nested, stack frames are superimposed on the same contiguous stack space. When a serious fault such as a cell voltage jump triggers a fault diagnosis process with a deep computation link and forms urgent concurrency with periodic sampling / monitoring interrupts, the instantaneous stack peak of the system may exceed the static reservation and cause stack overflow, which may lead to memory corruption, exception handling, or failure of critical monitoring links. Related research also points out that under task sets with automotive-grade scheduling characteristics, the planning to minimize the shared stack requirement itself has high complexity, for example, it can reach NP-hard.

[0004] Existing isolation approaches (such as configuring independent stacks for different tasks and restricting preemptible paths) can reduce propagation, but under static allocation conditions, when facing extremely sudden concurrency and computationally intensive safety-critical processes, there is still a problem that stack capacity configuration cannot balance safety margin and SRAM usage. At the same time, there are also research schemes in the security field that disperse attack risks by randomizing stack layout, but their main goal is to resist exploitation rather than meet the capacity deterministic constraints under functional safety. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] This invention provides a method for static allocation of stack space in a battery management system and a solution to the problem that sudden concurrency in a static stack causes the peak values ​​of the shared stack to overlap, easily leading to overflow, interrupt loss, and failure.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, embodiments of the present invention provide a method for static allocation of stack space in a battery management system, defining real-time operating system tasks and interrupt service routines in the battery management system as execution entities, the steps of which include: Step S1: During the compilation and linking stage, obtain the critical level and maximum stack usage of each execution entity; based on the two, generate non-overlapping task stack storage areas for each real-time operating system task, and generate non-overlapping interrupt stack storage areas for interrupt service routines grouped by critical level, forming a stack description table. The stack description table includes at least the stack start address, stack boundary, stack size and critical level identifier, and a protection zone or verification mark is placed at the stack boundary. Step S2: During the running phase, detect the execution entity switching caused by task scheduling or interruption, save the context of the switched execution flow to its current stack storage area, redirect the stack pointer currently used by the processor to the stack storage area corresponding to the target execution entity according to the stack description table, and restore or create the context of the target execution entity in the stack storage area. When an interrupt is entered, the interrupt pre-code redirects the stack pointer before calling the interrupt service routine. When the interrupt is exited, the stack storage area of ​​the interrupted execution flow is restored, and the protected area or check flag is detected to output an overflow alarm. During the compilation and linking phase, critical level identifiers of execution entities are generated and static call relationships are established to deduce the maximum stack usage. The critical level identifiers and the maximum stack usage are written into the stack descriptor table to drive the grouping and isolation allocation of the stack storage area.

[0008] As a preferred embodiment of the static stack space allocation method in the battery management system described in this invention, the critical level includes at least high critical level and non-high critical level, and the stack description table contains the mapping relationship from critical level to stack storage area; multiple interrupt service routines of the same critical level share the same interrupt stack storage area.

[0009] As a preferred embodiment of the static stack space allocation method in the battery management system described in this invention, the key level is obtained by calculating the key level score of the execution entity. The key level score is at least related to the functional safety target level, the maximum permissible response delay, and the ability to directly handle battery hardware fault signals. The key level score is mapped to the key level according to a preset threshold. During the compilation and linking stage, a critical level score is constructed based on the functional safety target level, maximum permissible response delay, and direct handling capability. The critical level identifier is then output after synthesis correction by minimum value dominance. Based on engineering constraints, one of the following is selected: single threshold mapping, multi-threshold hierarchical mapping, and layered threshold mapping. The critical level identifier is written into the stack description table and used as the grouping basis for the interrupt service routines in the shared interrupt stack storage area.

[0010] As a preferred embodiment of the static stack space allocation method in the battery management system of the present invention, the maximum stack usage is obtained through static call relationship analysis. Its calculation takes into account the cumulative stack frame value of all possible call paths of the execution entity and the possible preemption nesting depth, and adds a safety margin to the calculation result. During the compilation and linking phase, the upper bound of the stack frames of each function is extracted from the compiler output, and the cumulative stack frame value of the worst call path is calculated based on the static call relationship. For indirect calls, recursion, and library functions, a candidate set, whitelist, and digest model are used to form a conservative closure. The possible preemption nesting depth of the shared interrupt stack storage area is derived based on priority and interrupt masking rules, and the context occupation of nested links is included in the maximum stack usage. The uncertainty level is determined based on the coverage of the stack analysis metadata list, and the safety margin is adjusted for stack size calibration in the subsequent compilation and linking phases.

[0011] As a preferred embodiment of the static allocation method for stack space in a battery management system according to the present invention, the stack storage area is allocated by the linker script in the form of independent segments during the compilation and linking stage, and each stack storage area is aligned according to a preset alignment granularity to ensure that the address space does not overlap.

[0012] As a preferred embodiment of the static stack space allocation method in the battery management system of the present invention, when the executing entity is a task, the stack pointer redirection includes setting the process stack pointer to the stack storage area of ​​the target task; When the executing entity is an interrupt service routine, the stack pointer redirection includes setting the main stack pointer to the stack storage area of ​​the target interrupt service routine.

[0013] As a preferred embodiment of the static stack space allocation method in the battery management system described in this invention, the interrupt preamble code first performs minimum context saving on the current stack before entering the interrupt service routine, then switches to the stack storage area of ​​the target interrupt service routine and calls the interrupt service routine. When interrupt nesting occurs, the nested interrupts are kept to be executed in the same interrupt stack storage area. When interrupt nesting occurs, the nested interrupts that meet the preset nesting conditions are executed in the interrupt stack storage area corresponding to their critical level.

[0014] In a second aspect, the present invention provides a battery management system, including a processor and on-chip SRAM, and comprising: The stack configuration unit is used to generate a stack description table and configure the address and size of each stack storage area during the compilation and linking stage; The event monitoring unit is used to monitor task scheduling and interruption events during the runtime phase and output switching instructions. The stack pointer management unit is used to save and restore the context in response to the switching instruction, and to redirect the stack pointer according to the stack description table.

[0015] In a preferred embodiment of the battery management system described in this invention, the processor includes a memory protection mechanism, and the stack configuration unit configures the protected area as an inaccessible region.

[0016] In a preferred embodiment of the battery management system described in this invention, the stack pointer management unit records the stack usage level information of each execution entity during operation and uses the level information for stack size calibration in the next compilation and linking stage.

[0017] Through the above technical solution, the present invention can achieve at least the following beneficial effects: 1) To address the issue of sudden faults triggering deep diagnostic calls under static stack partitioning, and the concurrent occurrence of periodic monitoring interruptions leading to the superposition of peak values ​​in the shared stack, this invention generates a stack description table during the compilation and linking stage and redirects the stack pointer according to the execution entity at runtime. This allows the execution flows of the monitoring class and the diagnostic class to run in physically isolated stack spaces, avoiding the stack expansion of one execution flow from crowding out the stack frame of another execution flow, thus fundamentally reducing the risk of stack overflow caused by instantaneous resource conflicts.

[0018] 2) To address the problem of inconsistent stack dimensions and difficulty in ensuring the stability of critical monitoring links caused by nested execution flows when interrupts are entered, this invention introduces a stack-switching mechanism for interrupt pre-code, which enables interrupt service routines to execute on a pre-planned interrupt stack storage area and to be restored to the stack to which the interrupted execution flow belongs when the interrupt exits. This transforms the interrupt stack occupancy from being scattered and superimposed on each task stack to being centrally planned and allocated to the interrupt stack, thereby improving the predictability and isolation of critical monitoring paths.

[0019] 3) To address the dilemma of excessive reservation due to full isolation and insecurity due to full sharing under limited on-chip SRAM, this invention maps critical level identifiers to stack description tables, grouping interrupt service routines by critical level and sharing the interrupt stack storage area, while maintaining physical isolation from the task stack. Without sacrificing the critical link isolation principle, the stack resource configuration changes from linear expansion by quantity to growth by grouping and worst-case nesting constraints, which is more conducive to completing feasible capacity planning under limited SRAM.

[0020] 4) To address the problem that the maximum stack usage is difficult to estimate accurately and that indirect calls and library functions introduce uncertainty that leads to either under-allocation or waste, this invention derives the worst-case stack frame accumulation value based on static call relationships during the compilation and linking stage. It also forms an upper bound by combining the possible preemption nesting depth and adds a safety margin related to the uncertainty level, making the stack size source traceable and the definition verifiable, thereby reducing hidden failures or conservative redundancy caused by estimation deviations.

[0021] 5) To address the problem that stack out-of-bounds faults are difficult to detect early and fault propagation is difficult to locate, this invention sets up a protection zone or verification mark at the stack boundary and performs overflow alarm detection at switching and exit nodes, so that stack anomalies are transformed from silent memory corruption into detectable events, which facilitates triggering security policies, preserving evidence and locating the specific execution entity and stack area.

[0022] 6) To address the issues of lack of runtime feedback in stack configuration and the risk of long-term maintenance due to stack requirement drift after version iteration, this invention records the stack usage level of each execution entity and uses it for stack size calibration in the next compilation and linking stage. This enables stack planning to form a closed-loop optimization mechanism based on actual runtime data, continuously converging the safety margin configuration calibrator, and improving the stability and maintainability of the system under different operating conditions and software evolution. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0024] Figure 1 This is a flowchart of a static stack space allocation method in a battery management system according to an embodiment.

[0025] Figure 2 This is a framework diagram of a battery management system in one embodiment. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0027] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] Example 1: like Figure 1 As shown, this application proposes a method for static allocation of stack space in a battery management system, including the following steps: The real-time operating system tasks and interrupt service routines in the battery management system are defined as execution entities. In this embodiment, the enumeration boundary of the execution entities is based on the construction configuration. The real-time operating system tasks are derived from the task entry symbols in the task configuration list and link artifacts, and the interrupt service routines are derived from the interrupt vector configuration and the actual set of interrupts enabled. A unique identifier is assigned to each execution entity and used as the index key of the stack descriptor table, so that the corresponding stack descriptor table entry can be stably located by the task control block or interrupt number during the runtime phase, avoiding ambiguity during concurrent switching. The steps include: Step S1: During the compilation and linking stage, obtain the critical level and maximum stack usage of each execution entity, generate non-overlapping stack storage areas for each execution entity based on the two, and form a stack description table. The stack description table includes at least the stack start address, stack boundary, stack size and critical level identifier, and place protection zones or verification marks at the stack boundary. Furthermore, the stack start address and stack boundary are constant addresses determined during the linking phase, the stack size is the capacity field of the stack space available to the execution entity, and the critical level identifier is the level field used for group isolation and shared interrupt stack allocation. The stack boundary is also used to define the out-of-bounds detection position corresponding to the stack growth direction, so that the subsequent protection zone or verification mark can be covered and an alarm triggered before the stack growth reaches the boundary, thereby transforming stack out-of-bounds from a hidden memory corruption into an observable event.

[0029] Optionally, the protected area is a reserved contiguous address space located outside the stack boundary. Its size can be a number of bytes according to the alignment granularity and keep it from overlapping with the stack storage area. When deployed as an inaccessible area, it can trigger an exception when an out-of-bounds access occurs. The verification mark is fixed pattern data written near the stack boundary. It is written once during construction and read for verification at the time of task switching or interruption. If it is overwritten, an overflow alarm is output and the execution entity identifier and stack description table entry index at the time of triggering are retained for subsequent location and calibration.

[0030] Specifically, the compilation and linking stage refers to the build pipeline stage that generates object files from source code and completes linking. The functional safety target level, maximum allowable response latency, and direct handling capability required for critical levels are derived from the project's requirement constraints and design constraints, and are solidified into the input of the stack configuration unit as configuration items during the build process. The maximum stack usage is statically derived by the stack configuration unit from the compiler output, debugging information, or intermediate representation of the same version. The derivation result is in bytes and is rounded up according to the preset alignment granularity before being written to the stack descriptor table to ensure consistency with the segment allocation granularity of the linker script.

[0031] Step S2: During the running phase, detect the execution entity switching caused by task scheduling or interruption, save the context of the switched execution flow to its current stack storage area, redirect the stack pointer currently used by the processor to the stack storage area corresponding to the target execution entity according to the stack description table, and restore or create the context of the target execution entity in the stack storage area. Similarly, task scheduling events can be detected by context switching hooks or scheduler entry points in the real-time operating system, with the target task obtained from the control block of the task to be run; interrupt entry events are triggered by hardware interrupt entry points, with the target interrupt service routine obtained by mapping the interrupt number to the vector; the event monitoring unit encodes the above information into switching instructions and carries the target execution entity identifier, enabling the stack pointer management unit to locate the target stack storage area in a constant time during high-frequency switching, thus avoiding the introduction of additional uncertainties during sudden concurrency.

[0032] When an interrupt is entered, the interrupt pre-code redirects the stack pointer before calling the interrupt service routine. When the interrupt is exited, the stack storage area of ​​the interrupted execution flow is restored, and the protected area or check flag is detected to output an overflow alarm, so that the concurrently active monitoring and diagnostic execution entities use physically isolated stack space. For example, the interrupt preamble is a sequence of instructions located between the interrupt entry point and the interrupt service routine. Its responsibility is to perform minimum context saving and stack pointer redirection before calling the interrupt service routine. The upper bound of the minimum context saving includes the register context automatically saved when the processor enters the interrupt and the register context additionally saved by the preamble to meet the calling convention. Both are combined and included in the upper bound of context occupancy, so that the capacity derivation of the shared interrupt stack can cover the fixed overhead of the entry point and maintain consistency. When restoring the stack storage area of ​​the interrupted execution flow at the interrupt exit point, the protected area or check flag is checked simultaneously. The check can be performed before the restoration is completed to avoid secondary damage caused by exceeding the bounds.

[0033] During the compilation and linking phase, the stack configuration unit generates the critical level identifier of the execution entity and establishes static call relationships to deduce the maximum stack usage. It then writes the critical level identifier and the maximum stack usage into the stack descriptor table to drive the grouping and isolation allocation of the stack storage area. In this embodiment, the stack configuration unit is the static analysis and configuration generation logic in the construction system. Its inputs are the three types of inputs required for executing the entity list and critical level scoring, as well as the stack analysis information output by the compiler. Its output is a stack description table that can be used by the linker script and runtime table lookup. After the stack configuration unit writes the critical level identifier and the maximum stack usage into the stack description table, the linker script allocates the stack storage area in groups and isolations according to the table, so that the stack space planning completes the closed loop in the compilation and linking stage and maintains repeatable construction.

[0034] In this embodiment, the criticality level includes at least high criticality level and non-high criticality level, and the stack description table contains the mapping relationship from criticality level to stack storage area; multiple interrupt service routines of the same criticality level share the same interrupt stack storage area. Specifically, high-criticality levels are used to characterize execution entities that are more sensitive to functional safety objectives and response time limits, while non-high-criticality levels are used to characterize relatively less critical execution entities. After the criticality level field is written into the stack description table, the stack pointer redirection during runtime only needs to rely on this field and the execution entity identifier to complete the mapping lookup, avoiding the additional computational burden introduced by recalculating the score during runtime. When multiple interrupt service routines of the same criticality level share the same interrupt stack storage area, the shared scope is based on the mapping relationship in the stack description table, and the maximum stack usage of the worst nested link within the shared group is used as the basis for the capacity of the shared interrupt stack.

[0035] In this embodiment, the critical level is obtained by calculating the critical level score of the execution entity. The critical level score is at least related to the functional safety target level, the maximum permissible response delay, and the ability to directly handle battery hardware fault signals. The critical level score is mapped to the critical level according to a preset threshold. During the compilation and linking phase, the stack configuration unit constructs a critical level score based on the functional safety target level, maximum permissible response latency, and direct handling capability, and outputs a critical level identifier after synthesis correction through minimum value dominance. The stack configuration unit selects one of single threshold mapping, multi-threshold hierarchical mapping, and layered threshold mapping according to engineering constraints, writes the critical level identifier into the stack description table, and uses it as the basis for grouping interrupt service routines in the shared interrupt stack storage area. In this embodiment, the critical level score is calculated as follows: During the compilation and linking phase, each execution entity is denoted as the [number]th [unit]. The system consists of an execution entity, and three types of inputs are extracted from the requirements and design constraints: functional safety target level, maximum permissible response delay, and the ability to directly handle battery hardware failure signals; the critical level score is constructed with the safety target level as the primary factor and the remaining items as secondary factors. Furthermore, the functional safety target level comes from safety requirements or safety target allocation results, the maximum permissible response delay comes from timing requirements or scheduling analysis conclusions, and the direct handling capability comes from the design constraint records of hardware protection links and software control permissions. The above three types of inputs are aligned with the same version configuration list during the compilation and linking stage. If an execution entity lacks any of these inputs, that item is processed in a way that is unfavorable to its criticality. As a result, the scoring mapping tends to output a more conservative criticality level identifier, avoiding the critical execution entity being misclassified to a lower level due to missing inputs.

[0036] a. Convert functional safety target levels into dominant scoring, and assign the first... The functional safety target level of each implementing entity is mapped to a normalized score: (1) In equation (1), Indicates the first Functional safety-led scoring for each implementing entity Indicates the first The functional safety target level identifier corresponding to each execution entity , , , , These represent different functional safety target level categories; Optionally, the functional safety dominant score is a normalized dimensionless value, typically ranging from 0.20 to 1.00, and is set to decrease monotonically from level D, level C, level B, level A, to level QM, so that the performing entity with a higher safety target level receives a higher dominant score; to reduce frequent level changes caused by boundary jitter, the mapping relationship of level categories remains fixed within the same project cycle, unless changes in safety requirements cause changes in the level categories themselves.

[0037] b. To avoid differences in absolute time scales between different projects, a piecewise linear approach is used to map the maximum permissible response delay to a corrected score: (2) In this embodiment, the maximum permissible response delay is recorded in time units and given by requirements or verification constraints. It can be recorded in milliseconds or microseconds and the unit is unified in the construction input. The tight response threshold and the wide response threshold are used to define the transition range of the correction score from high to low. In engineering, the tight response threshold can be set to a more stringent upper limit and the wide response threshold can be set to a more lenient upper limit, and the wide response threshold is greater than the tight response threshold. When the maximum permissible response delay is missing or uncertain, it can be handled as an unfavorable situation, which is not less than the wide response threshold, so that the corresponding correction score tends to a lower value, thereby ensuring the conservatism of the critical level score.

[0038] In equation (2), Indicates the first Response latency correction score for each execution entity Indicates the first The maximum allowable response latency for each execution entity This represents the tight response threshold, used to define the endpoints of an interval with a smaller upper limit for latency. This represents the wide response threshold, used to define the endpoints of an interval with a larger upper limit for latency; c. Classify direct handling capabilities according to the degree of resource closure, for example: only report without handling, can write protection registers or control a single path, can directly drive hardware protection links such as contactors / fuse / charge and discharge switches; Furthermore, the direct handling capability level is a discrete level value, with the meaning of the value based on the engineering authority and closed-loop capability: a value of 0 corresponds to reporting without handling, a value of 1 corresponds to being able to write protection registers or control a single path, and a value of 2 corresponds to being able to directly drive hardware protection links such as contactors, fuses, or charge / discharge switches; this level is given by design constraints or interface authority list and is fixed during the compilation and linking stage. If the handling capability of an execution entity changes in version iteration, its level value is updated with the design constraints, thereby ensuring that the score is consistent with the actual capability.

[0039] Use discrete levels and normalize: (3) In equation (3), Indicates the first The direct handling capability score of each implementing entity is adjusted. Indicates the first The direct handling capability level of each execution entity is determined by taking the following values: , or ; d. To reflect the effect of reducing criticality if any aspect of the response constraint or handling link is weak, a composite correction term is constructed using minimum dominance: (4) In equation (4), Indicates the first Synthetic modified score for each execution entity and The meaning is the same as the definition above; Similarly, minimum dominance is used to express the engineering implications of criticality when either of the two types of correction factors becomes a weak link, so that the composite correction score is determined by the lower of the two types of correction scores, thereby avoiding the risk that a high correction score may mask a low correction score. This construction makes the score remain monotonically changing when the input fluctuates slightly, which facilitates obtaining a more stable criticality level identifier in the threshold mapping stage.

[0040] Based on this, key level scores are formed: (5) In equation (5), Indicates the first Key rating of each implementing entity and The meaning is the same as the definition above. This represents the weighting coefficient of the correction term, taken as... This is used to limit the impact of correction items on the overall score, so that the functional safety target level remains dominant. In this embodiment, the weight coefficient of the correction item is used to limit the influence of the correction item on the total score. Its adjustable range is 0.10 to 0.40. The default value in the project is to take the middle value to balance stability and discrimination. Avoiding extreme values ​​close to zero can prevent the correction item from being ineffective and failing to reflect the difference in real-time performance and handling capabilities. Avoiding extreme values ​​close to the upper limit can prevent the correction item from being over-amplified and weakening the dominance of the functional safety target level. The weight coefficient can be preset in the system configuration stage in combination with the historical stack overflow alarm occurrence distribution and project safety strategy, and fine-tuned in subsequent versions through water level records and alarm results to maintain a consistent scoring output.

[0041] In this embodiment, the mapping strategy from the threshold interval to the key level set is as follows: After the scoring is calculated, a mapping method using single threshold, multiple threshold, or hierarchical threshold based on safety level is adopted according to different engineering constraints to obtain the key level identifier for the stack description table; Specifically, the high criticality threshold is used as the dividing point in secondary mapping, and its adjustable range is 0.85 to 0.95. The default value in engineering is 0.90 to maintain the stability of the level when the score fluctuates slightly. The medium criticality threshold is used for multi-threshold hierarchical mapping, and its adjustable range is 0.65 to 0.80. The default value in engineering is 0.75 to form a buffer zone for intermediate levels. The stratified threshold is used to adopt different high criticality thresholds under different functional safety target level categories. The value of the stratified threshold should not decrease as the safety target level category increases, and it can be selected in the direction with higher misclassification cost in the verification set, so that the protection class execution entity is more likely to fall into the high criticality level to reduce the boundary risk of the stack isolation strategy.

[0042] e. Single-threshold secondary mapping (high criticality level / non-high criticality level): (6) In equation (6), Indicates the first Key level identifier output for each execution entity, Indicates a high criticality level. Indicates a non-high criticality level. The meaning is the same as the definition above. This indicates the high criticality level threshold, taken as... ;when When the value is exactly equal to the threshold, it can be treated as falling into the high criticality level to reduce stack area changes caused by boundary jitter. f. Multi-threshold hierarchical mapping (for finer-grained stack isolation strategies): When a stack isolation strategy aims to differentiate between diagnostic, control, and protection execution entities, an intermediate level can be introduced: (7) In equation (7), Indicates the key level, The threshold value for the critical level is taken as follows: The meanings of the remaining parameters are the same as those defined above; this hierarchical result can be used to group and allocate stack storage areas with different isolation strengths when generating the stack description table, and can still be merged into the set expression of high-critical level / non-high-critical level as needed; g. Thresholds for stratification by functional safety target level (ASIL stratification thresholds): When the same score in a project is expected to use different entry thresholds under different security levels, the thresholds can be set in layers according to security levels: (8) In equation (8), Indicates and The associated stratification threshold; the stratification threshold can be expressed as follows: (9) In equation (9), The meaning is the same as the aforementioned definition; for The execution entity can be fixed to a high criticality level in the mapping implementation, so that the threshold selection of the protection class execution entity is not affected by the fluctuation of the correction term.

[0043] As can be seen, during the compilation and linking stage, the stack configuration unit collects raw information such as the functional safety target level, maximum allowable response delay, and direct handling capability of battery hardware fault signals for each execution entity, and converts the functional safety target level into a dominant score, as shown in Equation (1); then converts the maximum allowable response delay into a corrected score, as shown in Equation (2); at the same time, it gives a discrete level based on the resource closure degree of the handling link and normalizes it to obtain a handling capability score, as shown in Equation (3); then it forms a synthetic corrected score dominated by the minimum value, as shown in Equation (4), and combines it with the dominant score to synthesize a key level score, as shown in Equation (5), where the weight of the corrected item is preset by the system configuration stage in combination with historical stack overflow alarms and security policies. After the score is formed, the stack configuration unit selects single threshold mapping, multi-threshold hierarchical mapping or layered threshold mapping according to engineering constraints, and outputs the key level identifier as shown in Equations (6) to (9), respectively. The key level identifier is used for the key level field in the stack description table and serves as the grouping basis for the interrupt service routines sharing the interrupt stack storage area.

[0044] Specifically, the above implementation method generates a critical level score for each execution entity during the compilation and linking stage, and maps the score to a critical level identifier for partitioning and allocation of the stack description table. The score construction takes the functional safety target level as the primary item, and response latency and direct handling capability as correction items, taking into account the differences between functional safety constraints and real-time performance and hardware closed-loop capabilities. The response latency is converted into a corrected score in a segmented manner to facilitate consistent comparison logic across different time scales. The direct handling capability is quantified in a hierarchical manner to facilitate the distinction between execution entities that only report and those with hardware protection actions. The correction items are formed by a minimum value to form a composite correction, reflecting the risk characteristics of reduced criticality when any critical constraint is weak. The threshold mapping provides three strategies: single threshold, multiple threshold, and hierarchical threshold according to safety level. It supports two-level outputs of high critical level and non-high critical level, and also supports the formation of intermediate levels as needed for finer stack isolation allocation, thereby enabling concurrently activated monitoring and diagnostic execution entities to achieve more stable physical isolation in stack space usage. In this embodiment, the maximum stack usage is obtained through static call relationship analysis. Its calculation takes into account the cumulative stack frame value of all possible call paths of the execution entity and the possible preemption nesting depth, and adds a safety margin to the calculation result. During the compilation and linking phase, the stack configuration unit extracts the upper bound of the stack frames of each function from the compiler output and calculates the cumulative stack frame value of the worst call path based on the static call relationship. For indirect calls, recursion, and library functions, it uses candidate sets, whitelists, and digest models to form a conservative closure. The stack configuration unit derives the possible preemption nesting depth of the shared interrupt stack storage area based on priority and interrupt masking rules, and includes the context occupancy of nested links in the maximum stack usage. The stack configuration unit determines the uncertainty level and adjusts the safety margin based on the coverage of the stack analysis metadata list for stack size calibration in the subsequent compilation and linking phases. Furthermore, the upper bound of a function's stack frame includes local variable usage, save register usage, and additional stack usage due to calling conventions, and is represented in bytes. When the stack configuration unit reads this upper bound from compiler output, debugging information, or intermediate representations, it should be based on optimization settings and linking settings consistent with the final executable image to avoid inconsistencies in the upper bound due to differences in build options. When a function lacks extractable stack frame upper bound information, it can be considered as uncovered and a conservative upper bound can be given through a whitelist or digest model, while increasing the uncertainty level to drive a larger safety margin.

[0045] In this embodiment, the candidate set is used to cover the set of called functions that may be reached by the indirect call point. It can be derived from pointer analysis results, link symbol reference relationships, or engineering constraint lists. The whitelist is used to provide an alternative set when the candidate set cannot converge or the third-party code cannot be analyzed, so that the static call relationship remains closed and computable. The summary model is used to provide a conservative description of the stack frame upper bound for library functions or external functions. Call points not covered by the summary can be mapped to a unified conservative upper bound according to the whitelist to ensure the computability and reproducibility of the worst path accumulation value.

[0046] In this embodiment, the methods for obtaining static call relationship analysis, stack frame accumulation value, and preemptive nesting depth are defined as follows: During the compilation and linking stage, with the first Starting with the entry function of each execution entity, a static call relationship is established for the set of reachable functions. The stack frame accumulation value of the worst call path is calculated on this relationship. For the set of interrupt service routines that share the same interrupt stack storage area, the possible preemption nesting depth is derived by priority and interrupt masking rules. The two are then combined to form the maximum stack usage. h. Calculate the stack frame accumulation value of the worst path on the call graph: When the The entry function of each execution entity is denoted as... At this time, the upper bound of the stack frame for each function can be obtained from the stack usage information, debugging information, or intermediate representation output by the compiler, and the worst-case path stack frame accumulation value can be obtained from the call relationship; the first... Any reachable call path of an execution entity is denoted as The first on the path The function is denoted as Then the stack frame accumulation value for this path can be written as: (10) In equation (10), Indicates the first The execution entity in the first Call path The upper bound of the stack frame accumulation value. Indicates the call path Decrease the number of functions on by one. Representation function The upper bound of the stack frame includes the stack usage caused by the function's local variables and saved registers; In the The set of all reachable call paths of an execution entity Take the maximum value to obtain the worst-case stack frame accumulation value for the non-preemptive scenario of this execution entity: (11) In equation (11), Indicates the first Upper bound of the worst-case stack frame accumulation value for each executing entity Indicates entry function Starting from a static call relationship, the set of call paths reachable from that point. and The meaning is the same as the definition above; To cover the conservative upper bound of indirect calls, the function Inner The candidate callee set of indirect call points is denoted as . Directly calling the collection is denoted as And the set to be called is used in the above formula for constructing reachable paths, when When convergence cannot be achieved through pointer analysis, a whitelist model is used to provide an alternative set. This ensures that the indirect call point satisfies: (12) In equation (12), Representation function The A set of candidate called functions for each indirect call point. This represents the whitelist of candidate indirect call points. Indicates function identifier, Indicates the indirect call point number; For recursion and mutual recursion, the strongly connected components corresponding to the recursive loop can be denoted as... And give it the maximum number of expansions. (This can be given by a whitelist or rule constraints), and the upper bound of the stack frame contribution of this loop in the worst path is written as: (13) In equation (13), Indicates the first The stack frames of a recursive loop in the worst path contribute to the upper bound. Indicates the first The maximum number of times a recursive cycle can be expanded. Indicates the first A set of functions for a recursive cycle. Representation function The upper bound of the stack frame; For library functions, a library function summary model can be used to identify them as follows: And give its stack frame upper bound. Participate in the above The computation allows library calls not covered by the digest to be uniformly mapped to a conservative upper bound in a whitelist, in order to maintain the set of reachable paths. The closed nature; i. Deriving the possible preemptive nesting depth based on priority, interrupt masking rules, and critical sections: When multiple interrupt service routines share the same interrupt stack storage area, the set of interrupt service routines corresponding to that interrupt stack is denoted as... Within this set, interrupt service routines. The priority identifier is This interrupts the service routine. The maximum shielding threshold that can be reached on its worst path is Nested conditions are characterized by preemptive relationships: (14) In equation (14), Indicates interrupted service routine For interrupted service routines The preemptible relationship indicator quantity, Indicates interrupted service routine The priority indicator, whose value is used to compare the preemption order. Indicates interrupted service routine The maximum shielding threshold is used to constrain the range of nested interrupts that can be accessed. and Indicates the interrupted service routine identifier; exist Above, take the set of sequences that satisfy the consecutive preemption relationship. The possible preemptive nesting depth is given by the sequence length: (15) In equation (15), Indicates the first The preemption nesting depth of a shared interrupt stack memory area. Let f(x) represent a set of interrupt service routines, such that any two adjacent elements satisfy the following condition: , Indicates the sequence length. Represents the first in the sequence An interrupt service routine identifier; Combining the above nesting depth with the worst-case stack frame accumulation value of each interrupt service routine, we can obtain the maximum stack usage calculation item for the shared interrupt stack storage area; let the interrupt service routine The upper bound of the context occupancy of the exception entry point and its preceding code on the interrupt stack is: Then the calculation term for the shared interrupt stack can be written as: (16) In equation (16), Indicates the first The calculation item for the maximum stack usage of a shared interrupt stack storage area. Indicates interrupted service routine The worst-case stack frame accumulation value. Indicates interrupted service routine The context occupies the upper bound. , and The meaning is the same as the definition above; For task execution entities, since the task stack and interrupt stack are physically isolated, the preemption nesting depth is mainly reflected in the minimum context protection of the current task stack by the interrupt preamble code before switching to the interrupt stack; let the upper bound of this minimum context protection be... Then the calculation terms of the task can be written as: (17) In equation (17), Indicates the first The calculation item for the maximum stack usage of a task execution entity. This indicates the upper bound of the minimum context save data written to the task stack when the task is interrupted and before switching to the interrupt stack. The meaning is the same as the definition above; j. Percentage or graded addition of the total surplus: The calculation items are summed with a safety margin to obtain the final output for maximum stack usage; let the object... Represents the task execution entity Or share the interrupt stack storage area Let the safety margin ratio be The maximum stack usage can then be written as: (18) In equation (18), Representation Object Maximum stack usage, Representation Object The maximum stack usage calculation item, Representation Object The safety margin ratio This indicates the rounding up operation; Furthermore, the safety margin ratio is used to cover the difference between static analysis and engineering reality. Its basic safety margin ratio can be selected between 0.10 and 0.20, and the graded step ratio can be selected between 0.05 and 0.10. The engineering default can take a smaller step to avoid stack configuration oscillation. The maximum stack usage is rounded up after superimposing the safety margin and aligned according to the alignment granularity, so that the actual available space will not be less than the calculated value due to fragmentation when the linker script is allocated in segments, thereby ensuring feasibility and repeatable construction.

[0047] When there is uncertainty in indirect calls, recursive upper bounds, or library summaries in a project, the safety margin can be increased according to the uncertainty level; let the uncertainty level be 1. ,Pick , or And let the basic ratio be , graded steps ,but: (19) In equation (19), The meaning is the same as the definition above. This represents the basic safety margin ratio, taken as... , Indicates the step ratio, take , Representation Object Uncertainty level, It can be directly called and there is no recursion loop. It can indirectly call converged or recursive loops that have an upper bound on the whitelist. This could correspond to conservative alternatives that exist due to non-converged indirect calls or missing library summaries; In this embodiment, the uncertainty level is used to express the impact of stack analysis coverage on reliability. A value of 0 corresponds to direct calls without recursive loops and a complete library summary. A value of 1 corresponds to indirect calls that have converged, recursive loops that have a whitelist upper bound, or a basically complete library summary. A value of 2 corresponds to non-converged indirect calls or conservative substitutions caused by missing library summaries. When the stack analysis metadata list shows that a critical function of an execution entity lacks a stack frame upper bound or the candidate set cannot be closed, the uncertainty level of the object can be set to 2 to trigger a larger safety margin ratio, thereby maintaining the safety of capacity planning even in the case of missing tests.

[0048] In the implementation, the upper bound of the function stack frame, the indirect call candidate set, the upper bound of the recursion loop, the uncertainty level and the calculation results can be written into the stack analysis metadata list of the compilation product for subsequent version difference comparison and threshold verification, so that the derivation process of the maximum stack usage remains consistent across multiple compilation and linking processes. For example, the stack analysis metadata manifest, as part of the build artifacts, is bound to the same version as the executable image. It records at least the execution entity identifier, entry function identifier, criticality level identifier, source type of the upper bound of the function stack frame, version number of the candidate set or whitelist, uncertainty level, and final maximum stack usage. This allows subsequent versions to replay the derivation process according to the same rules and compare differences. When the source type recorded in the manifest changes, such as from compiler output to whitelist replacement or from summary model to missing data replacement, it can trigger an increase in safety margin or a reselection of threshold mapping strategy to maintain the interpretability and consistency of criticality level identifiers and stack size calibration.

[0049] During the compilation and linking phase, the stack configuration unit establishes a static call relationship of the set of reachable functions starting from the entry function of the execution entity, and extracts the upper bound of the stack frame of each function from the compiler output and intermediate representation. It calculates the stack frame accumulation value on the reachable call path, as shown in Equation (10); then it calculates the stack frame accumulation value of the worst path on all reachable call paths, as shown in Equation (11). For function pointers and indirect calls, the stack configuration unit replaces the set with a candidate callee set or a whitelist to close the call relationship, as shown in Equation (12); for recursion and mutual recursion, the stack configuration unit gives the upper bound of the number of expansions and forms the upper bound of the recursion contribution based on the whitelist or rule constraints, as shown in Equation (13); for library functions, the stack configuration unit gives the upper bound of the stack frame through the library function summary model and incorporates it into the path calculation. Subsequently, the stack configuration unit constructs a preemptible relationship for the set of interrupt service routines sharing the same interrupt stack storage area based on priority and interrupt masking threshold, and derives the possible preemption nesting depth, as shown in Equations (14) and (15). Then, the worst-case path accumulation value on the nested link is combined with the context occupancy to obtain the calculation item for the shared interrupt stack, as shown in Equation (16). For the task execution entity, the minimum context protection written to the task stack before the interrupt preamble code is switched to the interrupt stack is included in the calculation item, as shown in Equation (17). Finally, the stack configuration unit adds a safety margin to the calculation item to form the maximum stack usage, as shown in Equations (18) and (19). The uncertainty level is determined by the coverage and difference comparison results of the stack analysis metadata list, and is continuously updated in the subsequent compilation and linking stages, used for linking scripts to allocate stack storage area and calibrate stack size.

[0050] Specifically, the priority flag is used to compare the preemption order between interrupt service routines. The comparison rule for its value is based on the priority sorting rule of the target platform and remains fixed in the project. The maximum masking threshold is the highest masking level that an interrupt service routine may reach on its worst-case path. It can be derived from the setting point of the interrupt masking state and the range of the critical section in the code, and the upper bound is taken according to the worst-case path. When the maximum masking threshold of an interrupt service routine cannot be determined, it can be handled as an unfavorable case to allow more high-priority interrupts to enter, so that the derived preemption nesting depth is more conservative and safer when planning the capacity of the shared interrupt stack.

[0051] Specifically, the above implementation performs static derivation of the maximum stack usage of the execution entity during the compilation and linking stage. The derivation process consists of two parts: the worst-case accumulation of the call path and the preemptive nesting constraint. Regarding the call path, a static call relationship is constructed starting from the entry function, and the upper bound of the stack frame occupancy of each function is obtained based on the compiler output. Then, the maximum value is taken from the set of reachable call paths to form the worst path accumulation, thereby covering the differences brought about by conditional branches and different call sequences. For indirect calls, library functions, and recursive calls, a conservative closure is formed by using candidate sets, digest models, and whitelist upper bounds, so that static analysis can still provide a usable upper bound when function pointers and third-party code exist. Regarding preemption and nesting, for interrupt service routines sharing the same interrupt stack storage area, a preemptible relationship is constructed based on priority comparison, interrupt masking threshold, and critical section influence. The maximum nesting depth is then calculated based on this relationship. The worst-case path on the nested link is accumulated and merged with the context occupancy to obtain the maximum occupancy estimate of the shared interrupt stack. Finally, a safety margin is superimposed on the calculation item according to a proportional or uncertainty-level classification, so that the maximum stack usage is more adapted to the convergence degree of indirect calls and the completeness of the library summary in the project, which is convenient for subsequent static stack allocation. In this embodiment, the stack storage area is allocated by the linker script in the form of independent segments during the compilation and linking stage, and each stack storage area is aligned according to a preset alignment granularity to ensure that the address space does not overlap. In this embodiment, when the executing entity is a task, stack pointer redirection includes setting the process stack pointer to the stack storage area of ​​the target task; When the executing entity is an interrupt service routine, stack pointer redirection includes setting the main stack pointer to the stack storage area of ​​the target interrupt service routine; In this embodiment, the interrupt preamble code first performs minimal context saving on the current stack before entering the interrupt service routine, then switches to the stack storage area of ​​the target interrupt service routine and calls the interrupt service routine, and keeps the nested interrupts executed in the same interrupt stack storage area when interrupt nesting occurs.

[0052] Example 2: Based on Embodiment 1, this application also proposes a battery management system, including a processor and on-chip SRAM, and comprising: The stack configuration unit is used to generate a stack description table and configure the address and size of each stack storage area during the compilation and linking stage; The event monitoring unit is used to monitor task scheduling and interruption events during the runtime phase and output switching instructions. The stack pointer management unit is used to save and restore the context in response to switching instructions, and to redirect the stack pointer according to the stack descriptor table; In this embodiment, the processor includes a memory protection mechanism, and the stack configuration unit configures the protected area as an inaccessible area to trigger an exception when the boundary is exceeded. In this embodiment, the stack pointer management unit records the stack usage level information of each execution entity during operation and uses the level information for stack size calibration in the next compilation and linking stage.

[0053] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0054] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A method for static allocation of stack space in a battery management system, characterized in that, Defining real-time operating system tasks and interrupt service routines in the battery management system as execution entities includes the following steps: Step S1: During the compilation and linking stage, obtain the critical level and maximum stack usage of each execution entity; based on the two, generate non-overlapping task stack storage areas for each real-time operating system task, and generate non-overlapping interrupt stack storage areas for interrupt service routines grouped by critical level, forming a stack description table. The stack description table includes at least the stack start address, stack boundary, stack size and critical level identifier, and a protection zone or verification mark is placed at the stack boundary. Step S2: During the running phase, detect the execution entity switching caused by task scheduling or interruption, save the context of the switched execution flow to its current stack storage area, redirect the stack pointer currently used by the processor to the stack storage area corresponding to the target execution entity according to the stack description table, and restore or create the context of the target execution entity in the stack storage area. When an interrupt is entered, the interrupt pre-code redirects the stack pointer before calling the interrupt service routine. When the interrupt is exited, the stack storage area of ​​the interrupted execution flow is restored, and the protected area or check flag is detected to output an overflow alarm. During the compilation and linking phase, critical level identifiers of execution entities are generated and static call relationships are established to deduce the maximum stack usage. The critical level identifiers and the maximum stack usage are written into the stack descriptor table to drive the grouping and isolation allocation of the stack storage area.

2. The method for static allocation of stack space in a battery management system according to claim 1, characterized in that, The criticality level includes at least high criticality level and non-high criticality level, and the stack description table contains the mapping relationship from criticality level to stack storage area; multiple interrupt service routines of the same criticality level share the same interrupt stack storage area.

3. The method for static allocation of stack space in a battery management system according to claim 1, characterized in that, The critical level is obtained by calculating the critical level score of the execution entity. The critical level score is at least related to the functional safety target level, the maximum permissible response delay, and the ability to directly handle battery hardware fault signals. The critical level score is mapped to the critical level according to a preset threshold. During the compilation and linking stage, a critical level score is constructed based on the functional safety target level, maximum permissible response delay, and direct handling capability. The critical level identifier is then output after synthesis correction by minimum value dominance. Based on engineering constraints, one of the following is selected: single threshold mapping, multi-threshold hierarchical mapping, and layered threshold mapping. The critical level identifier is written into the stack description table and used as the grouping basis for the interrupt service routines in the shared interrupt stack storage area.

4. The method for static allocation of stack space in a battery management system according to claim 1, characterized in that, The maximum stack usage is obtained through static call relationship analysis. Its calculation takes into account the cumulative stack frame value of all possible call paths of the execution entity and the possible preemption nesting depth, and adds a safety margin to the calculation result. During the compilation and linking stage, the upper bound of the stack frame of each function is extracted from the compiler output, and the stack frame accumulation value of the worst call path is calculated on the static call relationship. For indirect calls, recursion and library functions, a candidate set, whitelist and digest model are used to form a conservative closure. The preemptive nesting depth of the shared interrupt stack storage area is derived based on priority and interrupt masking rules, and the context occupation of nested links is included in the maximum stack usage. The uncertainty level is determined and the safety margin is adjusted based on the coverage of the stack analysis metadata manifest, which is used for stack size calibration in the subsequent compilation and linking stages.

5. The method for static stack space allocation in a battery management system according to claim 1, characterized in that, The stack storage area is allocated by the linker script as an independent segment during the compilation and linking stage, and each stack storage area is aligned according to a preset alignment granularity to ensure that the address space does not overlap.

6. The method for static allocation of stack space in a battery management system according to claim 1, characterized in that, When the executing entity is a task, the stack pointer redirection includes setting the process stack pointer to the stack storage area of ​​the target task; When the executing entity is an interrupt service routine, the stack pointer redirection includes setting the main stack pointer to the stack storage area of ​​the target interrupt service routine.

7. The method for static allocation of stack space in a battery management system according to claim 1, characterized in that, Before entering the interrupt service routine, the interrupt preamble code first performs a minimum context save on the current stack, then switches to the stack storage area of ​​the target interrupt service routine and calls the interrupt service routine. When interrupt nesting occurs, the nested interrupts are kept to be executed in the same interrupt stack storage area. When interrupt nesting occurs, the nested interrupts that meet the preset nesting conditions are executed in the interrupt stack storage area corresponding to their critical level.

8. A battery management system, based on the static stack space allocation method in a battery management system according to any one of claims 1 to 7, characterized in that, Includes a processor and on-chip SRAM, and includes: The stack configuration unit is used to generate a stack description table and configure the address and size of each stack storage area during the compilation and linking stage; The event monitoring unit is used to monitor task scheduling and interruption events during the runtime phase and output switching instructions. The stack pointer management unit is used to save and restore the context in response to the switching instruction, and to redirect the stack pointer according to the stack description table.

9. A battery management system according to claim 8, characterized in that, The processor includes a memory protection mechanism, and the stack configuration unit configures the protected area as an inaccessible region.

10. A battery management system according to claim 8, characterized in that, The stack pointer management unit records the stack usage level information of each execution entity during operation, and uses the level information for stack size calibration in the next compilation and linking stage.

Images