State transition design method and system for automobile air conditioning system based on Simulink and StateFlow

Abstract

The invention discloses an automobile air conditioning system state transition design method and system based on Simulink and StateFlow. The core lies in separating definition and execution links of state transition rules, constructing a two-dimensional state transition table through a visual table tool, and defining a current state, a transition condition and a transition result containing a target state, a memory command and a user-defined command; a Simulink module in the fixed execution framework analyzes the migration table and outputs a target state and a command signal, a StateFlow module executes stack operation to manage historical state memory, and an independent logic module processes a self-defined command; the historical state popped up by the stack is preferentially adopted during state updating, and the target state is switched when the state is invalid. According to the method, through rule and execution decoupling, stack type state management and a command expansion mechanism, the problems that a traditional state machine is complex in maintenance and migration table scale expansion and function expansion are difficult are solved, the configurability, operation efficiency and maintainability of the system are remarkably improved, and the method is particularly suitable for the multi-scene air conditioner control requirement of the electric vehicle.

Description

Technical Field

[0001] This invention belongs to the field of automotive air conditioning system technology, specifically relating to a state transition design method and system for automotive air conditioning systems based on Simulink and StateFlow. Background Technology

[0002] With the rapid development of automotive intelligence, automotive air conditioning systems have evolved from the basic mode of traditional fuel vehicles to diversified functions. New functions such as camping mode, remote control mode, and scenario-based mode of electric vehicles are constantly emerging, leading to a surge in the types of system states and a more complex mode switching logic. In particular, it places higher demands on multi-layer historical state memory and special function expansion.

[0003] However, existing state transition design techniques struggle to meet these requirements. First, in traditional designs, the definition and execution logic of state transition rules are often bound together in the same implementation. If graphical tools like StateFlow are used, transition paths must be manually drawn between states, and rule modifications require direct adjustments to the model structure, resulting in a cluttered graphical interface and high maintenance costs. If hard-coded implementation is used, rule modifications necessitate recompiling the execution logic, leading to extremely poor flexibility and an inability to adapt to rapid iteration requirements. This coupled architecture makes it difficult to balance independent rule editing with the stability of the execution logic. Second, typical state transition tables have limited expressive power for transition rules and high complexity in managing memory states. Existing state transition tables can only define a single mapping relationship: "current state + transition condition → target state." To achieve multi-layered state memory, the table must exhaustively list all combinations of the current state and all historical memory states, causing the size of the transition table to grow exponentially with the number of states. This increases the difficulty of rule design and significantly reduces system efficiency.

[0004] Therefore, there is an urgent need to provide a solution that can reduce the design complexity of state machines while taking into account the readability, maintainability, and complex pattern management requirements of the system. Summary of the Invention

[0005] The purpose of this application is to provide a state transition design method and system for automotive air conditioning systems based on Simulink and StateFlow, which has the advantages of decoupling state transition rules from execution logic, avoiding the expansion of the transition table size, and supporting flexible expansion for special events.

[0006] This application provides a state transition design method for an automotive air conditioning system based on Simulink and StateFlow. The technical solution is as follows: The definition and execution of state transition rules are separated. A visualization tool is responsible for rule definition, and a fixed execution framework is responsible for rule execution, achieving flexible configuration and stable operation of state transitions. Specifically: transition rules are used to define the logical rules for state transitions in the automotive air conditioning system; the visualization tool is an interactive tool that supports users in intuitively editing and independently maintaining state transition rules; the fixed execution framework is used to parse the transition rules and execute the state transition logic, including a Simulink module, a StateFlow module, and a preset logic module. The method includes the following steps: S1. Constructing a state transition table using a visualization tool. The state transition table is a two-dimensional data structure storing state transition rules, including the current state transition rules. The process involves several steps: S1) State transition, S2 transition, and S3 transition. The transition results include the target state, memory commands, memory states, and custom commands. Memory commands indicate whether to read or write to the memory state. The process is as follows: S2) Receive the current state and transition conditions via the Simulink module, query the state transition table to obtain the corresponding transition results, output the target state from the transition results, and parse the memory commands and custom commands. S3) Execute the memory commands and custom commands parsed in S2. Execute the memory commands via StateFlow to manage the memory state. Execute custom commands according to preset logic and handle special events. S4) Update the operating state of the automotive air conditioning system based on the target state parsed in S2 and the results of command execution in S3, completing the state transition.

[0007] This method decouples rule definition from execution logic through a separation architecture between visualization tools and a fixed execution framework. The visualization tools focus on the intuitive editing of migration rules, while the fixed execution framework handles rule parsing and execution, avoiding the problem in traditional designs where rule modifications depend on adjustments to the execution logic. Simultaneously, the migration table integrates remembered commands and custom commands, reduces exhaustive enumeration of remembered states through StateFlow stack management, and extends special functions through preset logic, significantly reducing the complexity of state transition design and improving system maintainability.

[0008] Furthermore, this application also proposes that in step S1, the migration result information is defined as encoded data containing a target status identifier field, a memory command identifier field, a memory status identifier field, and a custom command identifier field; each identifier field has a predetermined length, and the Simulink module parses each identifier information according to the preset field order.

[0009] Furthermore, this application proposes that in step S3, the memory command includes a stack control command, which includes a push command, a pop command, and a clear command; the memory state management specifically involves: when the stack control command is a push command, pushing the specified state element onto the top of the stack, where the specified state element is the current state or the target state; when the stack control command is a pop command, popping the most recently stored state element from the top of the stack; and when the stack control command is a clear command, resetting the stack structure to clear all stored state elements; the stack structure supports at least three levels of historical state memory, eliminating the need to exhaustively enumerate the combination relationships between the memory state and the current state in the state transition table.

[0010] Furthermore, this application also proposes that, in step S4, updating the operating state of the automotive air conditioning system based on the parsed target state and the result of command execution includes: if StateFlow executes the pop command and successfully pops the memory state, then the popped memory state is taken as the new operating state; otherwise, the target state parsed in S2 is taken as the new operating state.

[0011] Furthermore, this application also proposes that in step S3, the custom command is used to implement the joint judgment of the concurrent states of multiple actuators in the automotive air conditioning system, the derived control instructions under specific operating conditions, or the trigger instructions of user-defined scene modes; the preset logic is the logic implemented by an independent function call module or script execution unit in Simulink, which is decoupled from the rule definition of the state transition table.

[0012] Furthermore, this application also proposes that in step S1, the visualization tool is a two-dimensional table editing tool, which defines the current state through the table row dimension, defines the migration conditions through the column dimension, and stores the migration result information in the table cells; when modifying the table data, the module structure and connection relationship of the fixed execution framework remain unchanged.

[0013] Furthermore, this application also proposes that, in step S1, each state of the automotive air conditioning system is assigned a unique state index value as an identifier of the current state or target state in the migration table; and that migration conditions are independently numbered, and multiple migration conditions that trigger the same migration result information are associated with the same number to reduce the number of column dimensions in the migration table.

[0014] Furthermore, this application also proposes that the migration conditions include at least one of the following input signals: power control, mode switching, temperature adjustment, air volume adjustment, circulation mode, and special function buttons.

[0015] Furthermore, this application also proposes a state transition design system for an automotive air conditioning system based on Simulink and StateFlow, comprising: a visual rule definition module configured to construct and store a state transition table through a visual tool, and output rule data containing target state, memory commands, memory states, and custom commands; the visual tool is an interactive tool that supports users to intuitively edit and independently maintain state transition rules; and a fixed execution framework comprising: a parsing and transformation unit implemented based on Simulink, whose input is connected to the visual rule definition module, configured to receive the current state and transition condition input, query the transition table and parse the target state, convert the memory commands into stack operation signals, and convert the custom commands into stack operation signals. The system is converted into a logical trigger signal; the command execution unit includes: a stack management subunit, implemented based on StateFlow, whose input is connected to the stack operation signal output of the parsing and conversion unit, configured to maintain the stack structure and perform push, pop, or clear operations to realize historical state memory; a custom logic subunit, whose input is connected to the logical trigger signal output of the parsing and conversion unit, configured to execute special event handling logic through a preset function call; and a state update unit, whose first input is connected to the target state output of the parsing and conversion unit, and whose second input is connected to the stack operation result output of the stack management subunit, configured to: use this state update system when the stack operation result is a valid pop state; otherwise, use the target state update system.

[0016] The core of this invention lies in separating the definition and execution of state transition rules. A two-dimensional state transition table is constructed using a visual table tool to define the state transition logic. The Simulink module parses the transition rules, the StateFlow module implements stack-based historical state management, and independent logic modules process custom commands, forming a collaborative architecture that allows for flexible rule configuration and stable execution. Its advantages include: by decoupling rules and execution, it optimizes the traditional state machine approach, eliminating the need to adjust the model structure or recompile code for rule modifications, significantly reducing system maintenance complexity; the stack-based state management mechanism eliminates the need to exhaustively enumerate combinations of historical and current states in the transition table, effectively curbing the problem of the transition table's size expanding with the number of states, thus improving system efficiency; and the custom command extension mechanism supports flexible access to special functions in multiple scenarios, enabling functional iteration without modifying the core execution framework. The overall solution significantly improves the configurability, maintainability, and operational stability of automotive air conditioning systems, especially accurately adapting to the complex air conditioning control needs of diverse electric vehicle scenarios. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0018] Figure 1 This is a schematic diagram of the method flow provided in an embodiment of the present invention; Figure 2 A schematic diagram of the model implementation for parsing transfer results; Figure 3 This is a schematic diagram of a stack structure; Figure 4 This is a schematic diagram of the memory state management logic; Figure 5 A system structure diagram is provided for embodiments of the present invention.

[0019] Icon labels: 100. Fixed execution framework; 200. Visual rule definition module; 20. Parsing and transformation unit; 30. Command execution unit; 31. Stack management sub-unit; 32. Custom logic sub-unit; 40. State update unit. Detailed Implementation

[0020] The technical solution of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] like Figure 1 and Figure 2As shown, this application proposes a state transition design method for automotive air conditioning systems based on Simulink and StateFlow. It separates the definition and execution of state transition rules, with a visualization tool responsible for rule definition and a fixed execution framework responsible for rule execution, achieving flexible configuration and stable operation of state transitions. Specifically: transition rules define the logical rules for state transitions in the automotive air conditioning system; the visualization tool is an interactive tool that allows users to intuitively edit and independently maintain state transition rules; the fixed execution framework is a stable combination of modules used to parse transition rules and execute state transition logic, including a Simulink module, a StateFlow module, and preset logic modules. The method includes the following steps: S1, constructing a state transition table using a visualization tool. The state transition table is a two-dimensional data structure storing state transition rules, including the current state transition rules, the current state transition rules, and the state transition rules. The process involves several steps: S1) 1) Receive the current state and transition conditions through the Simulink module, query the state transition table to obtain the corresponding transition result information, output the target state from the transition result information, and parse the memory commands and custom commands in the transition result information; S2) Execute the memory commands and custom commands parsed in S2, execute the memory commands through StateFlow, and manage the memory state; execute custom commands according to preset logic and handle special events; S4) Update the operating state of the automotive air conditioning system based on the target state parsed in S2 and the command execution results in S3, completing the state transition.

[0022] Visualization tools, such as Excel, are interactive tools that allow users to intuitively edit and independently maintain state transition rules. Their core function is to define the correspondence between "current state - transition conditions - transition results" in a tabular format, and rule modifications do not require adjustments to the execution framework structure. A fixed execution framework, on the other hand, is a stable execution structure composed of Simulink modules, StateFlow modules, and pre-defined logic modules. Its module connections are fixed, and it is responsible for converting the rules defined by the visualization tool into executable logic. The Simulink module is the core of parsing and scheduling within the fixed execution framework. Implemented using MathWorks' Simulink graphical modeling environment, it primarily handles the parsing, signal conversion, and execution scheduling of state transition rules. The StateFlow module is the core carrier for memory state management within the fixed execution framework. Implemented using Simulink's StateFlow state machine modeling tool, it focuses on processing memory commands and maintains a stack structure to store and backtrack the multi-layered historical states of the automotive air conditioning system. The pre-defined logic modules are extension units within the fixed execution framework that handle special functions. Implemented using Simulink's function call subsystem or MATLAB function modules, they execute special event handling logic corresponding to custom commands and are completely decoupled from the rule definitions of the state transition table. The state transition table is the carrier of rules, using the current state as the row index and the transition condition as the column index. Each cell stores a structured transition result containing the target state, memory commands, memory states, and custom commands, avoiding the path crossing problem of traditional graphical state machines. The current state refers to the operating state of the automotive air conditioning system before the state transition. The target state refers to the operating state the system should switch to after the state transition. Memory commands are operation instructions that control the storage or retrieval of memory states, which can be implemented using stack operation commands, such as push, pop, or clear commands. StateFlow maintains the stack structure, supporting LIFO management of historical states, solving the need for multi-level state memory, and avoiding the efficiency degradation caused by exhaustively enumerating combinations of memory states. Custom commands are extended instructions independent of the state transition table, which can be implemented using function calls or script execution.

[0023] Specifically, the working process and principle of this application are as follows: First, a state transition table is constructed. This table is a two-dimensional array that stores the current state, transition conditions, and transition result information of the automotive air conditioning system. The transition results include the target state, memory commands, memory states, and custom commands. Memory commands are used to indicate read or write operations on the memory states. Next, the Simulink module takes the current state and transition conditions as input and queries the corresponding transition result information in the state transition table. The Simulink module outputs the target state from the transition result information and parses the memory commands and custom commands. Then, the parsed memory commands and custom commands are executed. Specifically, memory commands are executed through StateFlow for memory state management; custom commands are executed according to preset logic for special event handling. Finally, based on the output target state and the command execution results, the operating state of the automotive air conditioning system is updated, completing the state transition. This working principle combines the state transition table with StateFlow to achieve efficient state management and flexible command processing. The state transition table provides clear state transition logic, while StateFlow is responsible for complex memory state management. The introduction of custom commands further enhances the system's scalability.

[0024] Compared to existing technologies, this method decouples rule definition from execution logic through a separate architecture of visualization tools and a fixed execution framework: the visualization tools focus on intuitive editing of migration rules, while the fixed execution framework is responsible for rule parsing and execution, avoiding the problem in traditional designs where rule modifications depend on adjustments to the execution logic. Simultaneously, the migration table integrates memorized commands and custom commands, reduces exhaustive enumeration of memorized states through StateFlow stack management, and extends special functions through preset logic, significantly reducing the complexity of state transition design and improving system maintainability.

[0025] Through the above technical solution, this application effectively solves the problems of chaotic state machine interface and complex state combination in the prior art, realizes clear expression and efficient management of state transition rules of automotive air conditioning system, and has the advantages of reducing the complexity of state transition design and improving the maintainability of state machine.

[0026] This application further proposes that in step S1, each state of the automotive air conditioning system is assigned a unique state index value as an identifier of the current state or target state in the migration table; and that migration conditions are independently numbered, and multiple migration conditions that trigger the same migration result information are associated with the same number to reduce the number of column dimensions in the migration table.

[0027] In this system, the status index value assigns a unique numerical identifier to each status, used to quickly locate the row data corresponding to the current status in the two-dimensional array. The migration condition number assigns an independent sequence number to each trigger condition; multiple trigger conditions corresponding to the same migration result share the same number, thus compressing the column dimension of the migration table. The combination of the status index value and the migration condition number forms the index key of the two-dimensional array, enabling rapid retrieval of migration result information through a key-value mapping relationship.

[0028] In practical implementation, the construction of the state transition table needs to be meticulously designed based on the actual button inputs and state transition requirements of the automotive air conditioning system. As shown in Table 1, each button input in the system is assigned a unique number as the basic identifier for the transition conditions. For example, button functions such as "invalid command," "air conditioning on command," "air conditioning off command," "face blowing command," and "foot blowing command" are numbered from 0 to 18, respectively. Accurate button identification is achieved through a unique Idx (e.g., Idx=0 corresponds to NONE, Idx=1 corresponds to Pwr_On), ensuring that each button input can be uniquely distinguished within the system.

[0029] Table 1 Key Number Table Furthermore, to reduce the complexity of the state transition table, as shown in Table 2, key inputs that trigger the same state transition result are grouped into categories based on the same transition condition. For example, keys that trigger mode switching (MODE) and dual-zone off (Dual OFF) are grouped into Switch_1; keys that trigger power on (Pwr_On), AC on (AC_On), and dual-zone on (Dual_On) are grouped into Switch_2; keys that only trigger power off (Pwr_Off) are grouped into Switch_3; keys that all trigger foot blow mode (Mode_F) are grouped into Switch_4 to Switch_6; keys that trigger face blow and foot blow mode (Mode_PF) are grouped into Switch_7; and keys that trigger foot blow and window blow mode (Mode_FW) are grouped into Switch_8. Through this classification method, the system can uniformly process similar key inputs, significantly reducing the dimensionality of the state transition table.

[0030] Table 2 Button Classification Table The specific structure of the state transition table is a two-dimensional array structure with the current state (State) as the row index and the transition condition categories (Switch_1 to Switch_8) as the column index. As shown in Table 3, each cell in the table stores the transition result information, including the target state, the stack control command (memory command), and the custom command. For example, when the current state is OFF_Max_F (StateId=1), if input from Switch_4 to Switch_6 (all corresponding to the blow-to-the-feet mode button) is received, the transition result is "OFF_Max_F [S:Max_F]", where "OFF_Max_F" is the target state and "[S:Max_F]" is the stack control command, indicating that the stack structure should be executed with a memorization operation related to the "Max_F" state; if input from Switch_7 (blow-to-the-noodles / blow-to-the-feet mode button) is received, the transition result is "OFF_Max_F [S:Max_PF]", that is, the target state remains OFF_Max_F, and the stack control command is updated to the operation related to the "Max_PF" state.

[0031] Table 3 State Transition Table Through this structured design, the state transition table clearly maps the correspondence between the current state and the key input categories: when the system is in a certain current state, after receiving key input of different categories, it can quickly query the target state and the corresponding stack control commands. For example, when the current state is Max_PF (StateId=7), after receiving the input of Switch_8, the transition result is "Max_PF [S:Max_FW]", and the system determines the target state as Max_PF accordingly, and executes stack operations related to "Max_FW" to manage the remembered state. This design enables the system to efficiently determine the state transition path, stack operation instructions, and custom logic based on the current state and key input, achieving precise control and efficient management of the automotive air conditioning system state.

[0032] Compared to existing technologies, traditional methods require establishing a separate transition path for each triggering event in the state transition table, causing the state machine size to grow linearly with the number of events. In contrast, this method uses a conditional numbering merging mechanism to aggregate triggering events with the same transition result, ensuring that the size of the state transition table is determined solely by the number of system states, decoupling it from the number of event triggering sources.

[0033] Through the above technical solution, this application effectively solves the problem of data redundancy in the state transition table under complex event-triggered scenarios, avoiding the expansion of the state machine size due to the increase in the number of external events. At the same time, the index value mechanism improves the efficiency of system state query, and the state transition matching process can be completed directly through numerical comparison without the need for string parsing or pattern recognition operations.

[0034] This application further proposes that the migration conditions include at least one of the following input signals: power control, mode switching, temperature adjustment, air volume adjustment, circulation mode, and special function buttons.

[0035] The power control buttons are used to control the air conditioning system's start and stop; the mode switching buttons are used to switch between cooling, heating, dehumidification, and ventilation modes; the temperature adjustment buttons are used to adjust the set temperature; the fan speed adjustment buttons are used to adjust the airflow intensity; the circulation mode buttons are used to switch between internal and external air circulation modes; and the special function buttons are used to activate preset derivative functions. These button input types cover the core interactive elements of the air conditioning system's user interface, ensuring that the state transition table can respond to all routine operation commands.

[0036] Specifically, during the state transition table construction process, each key input type is assigned a unique condition number. When a user triggers a key operation, the corresponding condition number is combined with the current state to form a two-dimensional index. The Simulink module then queries the state transition table to obtain the target state and associated command.

[0037] Through the above technical solution, this application can comprehensively cover various operational inputs of the automotive air conditioning system, and achieve precise control of the air conditioning system status.

[0038] This application further proposes that in step S1, the migration result information is defined as encoded data containing a target status identifier field, a memory command identifier field, a memory status identifier field, and a custom command identifier field; each identifier field has a predetermined length, and the Simulink module parses each identifier information according to the preset field order.

[0039] It is understood that the migration result is defined as data of a predetermined length. For example, in some embodiments, the migration result is defined as a 32-bit structured data, divided into four fields in a fixed order, each occupying 8 bits, corresponding to the target state, memory command, memory state, and custom command information, respectively. The first 8-bit field is the target state field, used to uniquely identify the target state that the system should switch to after the state migration. It encodes various operating states (such as OFF_Max_F, Max_PF, Auto, etc.) using 8-bit binary values. The second 8-bit field is the memory command field, used to define the operation type of the memory state. It enumerates stack operation instructions such as push, pop, and reset using 8-bit binary values. The third 8-bit field is the memory state field, used to specify the historical state that needs to be remembered. It has the same bit width as the target state field. It uses 8-bit binary values ​​to correspond to the index value of the historical state (such as Max_F, Manual, etc. stored in the stack) to ensure that the memory operation can accurately locate the historical data. The fourth 8-bit field is the custom command field, used to carry system extended function instructions. It defines special logic such as multi-executor joint judgment and derived control instructions using 8-bit binary values.

[0040] For example, in a specific implementation, in the 32-bit data of a migration result, the first 8 bits correspond to the target state Max_F, the middle 9-16 bits correspond to the memory command push operation, the 17-24 bits correspond to the memory state Manual, and the last 8 bits correspond to the custom command. After this 32-bit data is transmitted to the parsing module via the system bus, the Simulink built-in query parsing module splits and identifies it in 8-bit intervals: the target state field drives the state switching module to determine the new state, the memory command field and the memory state field are combined to form a stack operation instruction and transmitted to StateFlow, and the custom command field triggers the preset function module to execute extended logic.

[0041] Through the above technical solutions, this application achieves standardized encoding and efficient parsing of migration result information. The 32-bit data structure ensures the complete carrying of target state, memory commands, memory states, and custom commands, and achieves structured data management through fixed field division; the design of each field being 8 bits makes each piece of information independently identifiable, facilitating rapid splitting and processing by Simulink; the standardized encoding format ensures data compatibility between different system versions, supports the synchronous and efficient execution of state switching, stack operations, and custom commands, and meets the precise control requirements of automotive air conditioning systems for complex state migrations.

[0042] This application further proposes that in step S3, the memory command includes a stack control command, which includes a push command, a pop command, and a clear command; the memory state management is specifically as follows: when the stack control command is a push command, the specified state element is pushed onto the top of the stack, and the specified state element is the current state or the target state; when the stack control command is a pop command, the most recently stored state element is popped from the top of the stack; when the stack control command is a clear command, the stack structure is reset to clear all stored state elements; the stack structure supports at least three levels of historical state memory, without needing to exhaustively enumerate the combination relationship between the memory state and the current state in the state transition table.

[0043] Stack control commands are control instructions that perform data operations on the stack structure. They can be implemented using predefined binary encoding or string identifiers and indicate the type of operation to perform: push, pop, or clear the stack. The stack structure is a Last-In-First-Out (LIFO) data structure maintained in the StateFlow module, used to sequentially store historical state data generated during the operation of the automotive air conditioning system. The push command instructs to push the current system state onto the top of the stack, implemented by incrementing the pointer and writing data, used to save the operating state of the air conditioning system before switching. The pop command instructs to retrieve the most recently saved state data from the top of the stack, implemented by decrementing the pointer and reading data, used to restore the previous operating state of the air conditioning system. The clear command instructs to clear all stored data in the stack, implemented by resetting the stack pointer or overwriting the storage area, used to initialize the state memory function.

[0044] Specifically, during the operation of the automotive air conditioning system, when a mode switch or function trigger event is detected, the parsing module parses the corresponding stack control command based on the migration table lookup results. When the system triggers a push operation, the stack management unit selects to push either the current state or the target state as a state element onto the stack based on the stack control command in the migration results. If it is necessary to save the current running state, the push operation pushes the current state index value onto the top of the stack; if it is necessary to return to the previous mode, the pop operation pops the top state element from the stack and passes it to the state update unit; if a system reset or fault occurs, the clear operation clears all elements in the stack. The stack structure adopts a dynamic memory allocation method, and the depth can be configured to two or more levels. The system records the state of each level through continuous push operations and performs pop operations in reverse order to restore the original state upon exiting.

[0045] In the specific implementation process, as shown in Figure 3 and Figure 4As shown, in the specific implementation of memory state management through StateFlow execution of memory commands, the memory state management logic is built on the StateFlow state machine. Its core is to drive the initialization, push, and pop operations of the stack through memory commands (Mem_Cmd). This state machine contains two core logic parts: an initialization branch and a command execution branch. The initialization branch covers two scenarios: Reset and EEP_Init. Reset initialization is triggered when the system powers on or resets, setting the current state (CurState) to the initial state (State_Init), resetting the stack top pointer (topIndex=1), and clearing the memory state flags (such as State_M1=Mem_Init, State_M3=0) to ensure that the stack structure starts from zero. EEP_Init initialization reads historical memory data from EEPROM (EEP_Restore) and restores the multi-level memory states stored in the stack (such as the recently saved Max_F, Manual, etc.) to ensure that the memory is not lost after the system restarts.

[0046] The command execution branch uses the 8-bit encoded Mem_Cmd as the core driving signal to implement various stack operations. When Mem_Cmd == 0, the stack operation is skipped and the target state (State_Tgt) is directly assigned to the current state (CurState = State_Tgt); when Mem_Cmd == 1, a read memory operation is performed, which executes Stack_Pop() to pop the most recently saved memory state from the top of the stack and update the current state, while decrementing the stack top pointer (topIndex--); when Mem_Cmd == 2, a write memory operation is performed, which pushes the current state (CurState) onto the top of the stack (Stack [topIndex] = CurState) and increments the pointer through Stack_PushCurState(); when Mem_Cmd == 3, Stack_PushMem_Tgt() is triggered to store the target state (State_Tgt) into the stack in advance to meet the state saving requirements of the upcoming switch. In addition, extended commands such as Mem_Cmd==10 support recording the state offset (RmtOffset) when pushing onto the stack, adapting to complex scenarios such as remote control; Mem_Cmd==11 can first perform a pop operation to restore the historical state, and then push the new target state onto the stack, realizing a coherent operation of "restoring and saving the new state".

[0047] The stack's underlying layer uses an array or linked list to implement "last-in, first-out" (LIFO) management. When pushing data onto the stack, the stack pointer is incremented and data is written; when popping data from the stack, the pointer is decremented. A clear operation resets the pointer to its initial value and removes all valid data. This logic supports dynamically configurable stack depth (e.g., 2 levels or more), and, combined with state flags (e.g., State_M1), can accurately match the memory requirements of multi-level nested scenarios. The module design has no fixed paradigm and can be flexibly expanded by adding Mem_Cmd codes (e.g., clear stack commands), adjusting the stack storage medium, or adding validity checks, ensuring compatibility with different vehicle air conditioning systems.

[0048] Compared to existing technologies, traditional methods require explicitly defining the combination relationship between the current state and all possible historical states in the transition table when historical state backtracking is needed. This causes the size of the transition table to grow exponentially with the depth of the historical state. When managing historical states, the entire list needs to be traversed for state restoration, which is inefficient and difficult to handle multi-level nested scenarios. In contrast, this solution dynamically manages historical states using a last-in-first-out stack structure. The state transition table only needs to define the mapping relationship between the current state and the transition conditions, without adding additional columns to describe the combinations of historical states, significantly reducing the design complexity of the transition table.

[0049] Through the above technical solution, this application effectively solves the technical challenge of state memory management in automotive air conditioning systems under complex modes, achieving efficient storage and rapid recovery of historical states of the automotive air conditioning system, and supporting multi-level state memory functionality without increasing the complexity of the state transition table. Using a stack structure to manage state data effectively reduces the number of state queries and improves system response speed.

[0050] This application further proposes that in step S4, the operating state of the automotive air conditioning system is updated according to the parsed target state and the result of command execution, including: if the StateFlow module executes the pop command and successfully pops the memory state, then the popped memory state is taken as the new operating state; otherwise, the target state parsed in S2 is taken as the new operating state.

[0051] Specifically, during state transitions, if historical state elements exist in the stack, the top element is passed as a valid output to the state update unit; if the stack is empty or an operation exception occurs, an invalid flag is output. The state update unit judges based on the priority of input signals. When a valid popped memory state is received, it is prioritized as the new system state for updating; if no valid memory state is received, the target state provided by the parsing and transformation unit is used directly for updating. This achieves logical separation between historical state backtracking and target state switching, avoiding exhaustive enumeration of historical state combinations in the state transition table. Through the above technical solution, this application can avoid the problem of migration table expansion when processing multi-layered historical state memory, and improve the efficiency of state query. At the same time, by prioritizing the use of popped-up memory states as new states, it ensures that the system can accurately restore to the historical running scenario. For example, after switching temporary modes, it can quickly return to the user's preset common mode without having to re-traverse the complete state migration logic.

[0052] This application further proposes that in step S3, the custom command is used to realize the joint judgment of the concurrent state of multiple actuators in the automotive air conditioning system, the derived control command under specific operating conditions, or the trigger command of the user-defined scene mode; the preset logic is the logic implemented by an independent function call module or script execution unit in Simulink, which is decoupled from the rule definition of the state transition table. Custom commands refer to non-standardized operation instructions implemented through preset logic. Specifically, they can be encapsulated in Simulink using condition judgment modules or function call modules. They are used to handle special events and extend functions in automotive air conditioning systems that are difficult to describe directly through two-dimensional state transition tables.

[0053] Compared to existing technologies, traditional solutions require directly embedding executable code into the state transition table when implementing complex control logic, such as writing MATLAB code snippets in a StateFlow state machine. This necessitates synchronous adjustments to the embedded code structure when rules are modified, easily leading to logical conflicts. In contrast, this solution, through the independent encapsulation of pre-defined logic, allows adding new custom commands by simply extending the command identifier field of the transition table and adding the corresponding function module in Simulink, without needing to refactor existing state transition rules, significantly reducing the coupling of functional extensions.

[0054] Through the above technical solution, this application effectively solves the problem of system maintenance difficulties caused by the strong coupling between complex control logic and state transition rules, and realizes the flexible expansion of the functions of the air conditioning system.

[0055] As shown in Figure 5, this application further proposes a state transition design system for an automotive air conditioning system based on Simulink and StateFlow, including a visual rule definition module 200 and a fixed execution framework 100. The visual rule definition module 200 is configured to construct and store a state transition table using a visualization tool, and output rule data containing the target state, memory commands, memory states, and custom commands. The fixed execution framework 100 includes a parsing and transformation unit 20, a command execution unit 30, and a state update unit 40. The parsing and transformation unit 20 is implemented based on Simulink, and its input is connected to the visual rule definition module 200. It is configured to receive the current state and transition conditions, query the transition table and parse the target state, convert memory commands into stack operation signals, and convert custom commands into logical trigger signals. The command execution unit 30 includes a stack management subunit 31 and a custom logic subunit 32. The stack management subunit 31 is implemented based on StateFlow, and its input is connected to the stack operation signal output of the parsing and conversion unit 20. It is configured to maintain the stack structure and perform push, pop, or clear operations. The input of the custom logic subunit 32 is connected to the logic trigger signal output of the parsing and conversion unit 20. It is configured to execute special event handling logic through a preset function call. The state update unit 40 has its first input connected to the target state output of the parsing and conversion unit 20, and its second input connected to the stack operation result output of the stack management subunit 31. It is configured to use the state update system when the stack operation result is a valid pop state, and otherwise use the target state update system.

[0056] The visualization rule definition module 200 refers to the visualization configuration of state transition rules through a two-dimensional table editing tool. Specifically, it can be implemented using an Excel add-in or a MATLAB spreadsheet interface. State transition logic is defined through row and column intersections, allowing rule modifications to be made only by adjusting the table data without altering the execution framework structure. The parsing and conversion unit 20 is a conversion module that converts the transition results into execution signals. Specifically, it can be implemented using a combination of a lookup module and a signal decomposition module in Simulink. It parses the target state, stack operation instructions, and custom command trigger signals sequentially through predefined fields. The stack management subunit 31 is a historical state memory implemented based on a finite state machine model. Specifically, it can be constructed using a hierarchical state machine in StateFlow to create a three-layer stack structure. Push and pop operations are executed through an event-driven mechanism, avoiding exhaustive enumeration of historical state combinations in the transition table. The custom logic subunit 32 is an external execution module independent of the state transition rules. Specifically, it can be implemented using the Simulink function call subsystem. Decoupling from the state transition table is achieved through interface standardization, supporting flexible mounting of user-defined scripts.

[0057] Specifically, the system defines state transition rules through a visual table, using the current state and transition conditions as row and column indices, and storing the target state code and operation instruction set in the intersecting cells. When the system runs, the parsing and conversion unit 20 receives the current state signal from the sensor and the transition condition signal triggered by the user operation, and retrieves the corresponding encoded data packet through a table lookup operation. After signal decomposition, the target state is directly transmitted to the state update unit 40. Stack operation instructions are converted into event signals to drive the StateFlow stack structure management, and custom commands are converted into trigger signals to call preset logic modules. For example, when the transition rule requires saving the current state, the parsing and conversion unit 20 generates a push signal, triggering the stack management subunit to push the current state onto the top of the stack; when it is necessary to restore a historical state, a pop signal drives the stack management subunit 31 to output the most recently stored state element. The state update unit 40 prioritizes using the stack operation result as the new state, and only uses the target state when the stack operation is invalid, thus realizing the historical state backtracking function.

[0058] Compared to existing technologies, current state transition systems typically embed rule definitions within the execution model, requiring a reconstruction of the state machine model or recompilation of the code to modify rules. This system separates the visual rule definition module from the fixed execution framework, allowing rule adjustments to be made only by modifying table data, while maintaining structural stability in the execution module. Traditional solutions for handling historical state dependencies require defining all possible combinations of historical states in the transition table. This system decouples state storage from transition logic through an independent stack management subunit; the transition table only needs to define the mapping relationship between the current state and transition conditions, effectively reducing table dimensionality. Existing technologies require adding transition branches within the state machine to implement custom functions. This system connects independent logic modules through standardized interfaces, avoiding complex state machine structures.

[0059] Through the above technical solutions, this application realizes the visual and independent editing of state transition rules for automotive air conditioning systems, optimizing the destructive impact of rule modifications on the execution framework. By adopting a stack structure to manage historical states, the complexity of the state transition table is reduced from exponential to linear, improving system execution efficiency. Through standardized access to custom logic modules, special function extensions are supported without affecting the core state machine structure, significantly improving system maintainability and functional scalability.

[0060] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A state transition design method for automotive air conditioning systems based on Simulink and StateFlow, characterized in that, A visualization tool is responsible for defining state transition rules, while a fixed execution framework is responsible for executing these rules, enabling flexible configuration and stable operation of state transitions. Specifically: the state transition rules define the logical rules for state transitions in the automotive air conditioning system; the visualization tool is an interactive tool that allows users to intuitively edit and independently maintain state transition rules; the fixed execution framework parses the transition rules and executes the state transition logic, including a Simulink module, a StateFlow module, and a preset logic module; the method includes the following steps: S1. Construct a state transition table using the visualization tool. The state transition table is a two-dimensional data structure that stores state transition rules, including the current state, transition conditions, and transition result information. The transition result includes the target state, memory command, memory state, and custom command. The memory command is used to indicate a command to perform a read or write operation on the memory state. S2. Receive the current state and migration condition input through the Simulink module, query the state migration table to obtain the corresponding migration result information, output the target state in the migration result information, and parse the memory commands and custom commands in the migration result information; S3. Execute the memory commands and custom commands parsed in S2. Execute the memory commands through StateFlow to manage memory state; execute the custom commands according to preset logic to handle special events. S4. Based on the target state parsed in S2 and the result of command execution in S3, update the operating state of the car air conditioning system and complete the state transition.

2. The method according to claim 1, characterized in that, In step S1, the migration result information is defined as encoded data containing a target status identifier field, a memory command identifier field, a memory status identifier field, and a custom command identifier field; each identifier field has a predetermined length, and the Simulink module parses each identifier information in a preset field order.

3. The method according to claim 1, characterized in that, In step S3, the memory commands include stack control commands, which include push commands, pop commands, and clear commands; the memory state management specifically includes: When the stack control command is a push command, the specified state element is pushed onto the top of the stack. The specified state element is the current state or the target state. When the stack control command is a pop command, the most recently stored state element is popped from the top of the stack. When the stack control command is a clear command, the stack structure is reset to clear all stored state elements; The stack structure supports at least three levels of historical state memory, eliminating the need to exhaustively enumerate the combinations of remembered states and the current state in the state transition table.

4. The method according to claim 3, characterized in that, In step S4, updating the operating status of the vehicle air conditioning system based on the parsed target state and the result of command execution includes: If StateFlow executes the pop command and successfully pops the memory state, the popped memory state will be used as the new running state. Otherwise, the target state obtained from S2 is used as the new running state.

5. The method according to claim 1, characterized in that, In step S3, the custom command is used to jointly determine the concurrent states of multiple actuators in the automotive air conditioning system, generate control instructions under specific operating conditions, or trigger instructions for user-defined scene modes; the preset logic is logic implemented by an independent function call module or script execution unit in Simulink, and is decoupled from the rule definition of the state transition table.

6. The method according to claim 1, characterized in that, In step S1, the visualization tool is a two-dimensional table editing tool, which defines the current state through the table row dimension and the migration conditions through the column dimension, and stores the migration result information in the table cells; when modifying the table data, the module structure and connection relationship of the fixed execution framework remain unchanged.

7. The method according to claim 1, characterized in that, In step S1, a unique state index value is assigned to each state of the automotive air conditioning system as an identifier of the current state or target state in the state transition table. The migration conditions are assigned independent numbers, and multiple migration conditions that trigger the same migration result information are associated with the same number to reduce the number of column dimensions in the migration table.

8. The method according to claim 1, characterized in that, The migration conditions include at least one of the following input signals: power control, mode switching, temperature adjustment, airflow adjustment, circulation mode, and special function buttons.

9. A state transition design system for automotive air conditioning systems based on Simulink and StateFlow, characterized in that, include: The visualization rule definition module (200) is configured to build and store state transition tables through a visualization tool, and output rule data containing target state, memory command, memory state and custom command; the visualization tool is an interactive tool that supports users to intuitively edit and independently maintain state transition rules; Fixed execution framework (100), including: The parsing and conversion unit (20) is implemented based on Simulink. Its input end is connected to the visualization rule definition module (200). It is configured to receive the current state and migration condition input, query the migration table and parse the target state, convert the memory command into a stack operation signal and the custom command into a logic trigger signal. The command execution unit (30) includes: The stack management subunit (31) is implemented based on StateFlow. Its input is connected to the stack operation signal output of the parsing and conversion unit (20). It is configured to maintain the stack structure and perform push, pop or clear operations to realize historical state memory. A custom logic subunit (32) is configured to execute special event handling logic by calling a preset function. Its input is connected to the logic trigger signal output of the parsing and conversion unit (20). The state update unit (40) has its first input connected to the target state output of the parsing and conversion unit (20) and its second input connected to the stack operation result output of the stack management subunit (31). It is configured to use the state update system when the stack operation result is a valid pop state; otherwise, the target state update system is used.

Images