System control method adopting hierarchical state machine

Abstract

The invention provides a system control method adopting a hierarchical state machine, belongs to the technical field of system control, and particularly adopts a design mode of the hierarchical state machine to realize service configurability, high efficiency and easy expansion by decoupling a complex radar control service and software logic. When the control service of the system is changed or a new project needs to develop the system control software, the core logic processing engine of the hierarchical state machine is kept unchanged by adding, deleting and changing the service function configuration table or adding, deleting and changing the state event routing table according to the actual system control service in combination with the method disclosed by the invention; and the change, maintenance and expansion of the radar control service can be quickly realized.

Description

Technical Field

[0001] This application relates to the field of system control, and in particular to a system control method employing a hierarchical state machine. Background Technology

[0002] With the increasingly widespread application of airborne radar, radar demands are increasing and their functions are becoming more complex, while the differences in demands and functions are also growing. The functional requirements of different radar projects vary, leading to different control requirements allocated to the software. Therefore, different radar projects generate multiple sets of different software activities, increasing the costs of software development, verification, and maintenance.

[0003] In actual scientific research and production projects, the same software often requires collaborative development and maintenance by multiple people in multiple locations. This places high demands on the development efficiency and communication costs among developers. Communication discrepancies among developers can lead to potential security and reliability risks. Summary of the Invention

[0004] In view of this, this application provides a system control method using a hierarchical state machine, which solves the problems in the prior art, reduces repetitive software development activities, lowers software development and maintenance costs, and improves software security and reliability.

[0005] This application provides a system control method using a hierarchical state machine, which employs the following technical solution: A system control method employing a hierarchical state machine includes the following steps: Based on the state classification method of hierarchical state machines, the system control business and control software logic are decoupled, resulting in several sub-states and parent states: Combining the concepts of state nesting and state inheritance in a hierarchical state machine, the parent state, its functions, child states, and their functions are organized according to the hierarchical relationship between the parent and child states to form a business function configuration table. Analyze the operational logic of the system control business, identify the events in the control business, and group events with the same trigger source into one category; Combining the event routing and event-driven mechanism of the hierarchical state machine, the events in the control business are organized and summarized into a state event routing table. The events in the control business include the current running sub-state of the system, the events to be triggered in the current running sub-state of the system, and the state transition path after the events to be triggered are triggered. The state event routing table is used to configure the state control of the system during dynamic operation. The hierarchical state machine core logic processing engine combines the business function configuration table and the state event routing table to construct the system control hierarchical state machine; After the system starts, the core logic processing engine builds an instance by reading the business function configuration table and the state event routing table; first, the business function configuration table defines the state hierarchy, the states contained in each level and the nesting relationship of states, and the functions to be executed by each state; then, the state event routing table sets the state transition order during dynamic runtime. The system uses internal synchronization signals as the event driver to load the initial state of the hierarchical state machine and then run system control.

[0006] Optionally, based on the state classification method of hierarchical state machines, the specific steps for decoupling system control business from control software logic include: Identify the working state in radar control operations, classify the behavior of different working states of the system, define several states with the same type as sub-states, merge them into a parent state, and obtain several parent states, each parent state containing several sub-states. Focus on a parent state, extract common behaviors from all its child states, and abstract these common behaviors onto the parent state; retain the unique behaviors of each child state within that child state.

[0007] Optionally, after the system starts, the core logic processing engine reads the parent and child states in the table, creates the nested relationships, reads the behaviors contained in each state in the table, and creates the execution behaviors of each state.

[0008] Optionally, after the system starts, the core logic processing engine monitors whether the event to be triggered in the current running sub-state inside the radar has been triggered. If it has been triggered, the state transition order during dynamic operation is reset according to the state transition path after the event to be triggered is triggered in the table.

[0009] Optionally, it also includes building an arbitration management module; After system startup, the arbitration management module registers the parent states from the business function configuration table read by the core logic processing engine, obtains the state event routing table read by the core logic processing engine, sets the initial state transition order according to system business requirements, sets a default state transition order according to system business requirements, and runs the set initial state transition order, so that the system runs in the initially set sub-states. When the system is running normally in a certain state, if the core logic processing engine detects that a new state transition order has been triggered by an event, it will transfer system control and the new state transition order to the arbitration management module. The arbitration management module will then transfer control to the corresponding parent state according to the state transition order, and designate one or more child states belonging to the parent state as the system running state in sequence. If an abnormal situation occurs during the transfer of control of the arbitration management module, causing the transfer of control to fail, the arbitration management module will run the default state migration path.

[0010] Optionally, a hierarchical state machine system control method can be used for the control of the radar system.

[0011] In summary, this application includes the following beneficial technical effects: The unified architecture and clear layering improve development efficiency. By using the Hierarchical State Machine (HSM) design pattern, it achieves "one set of logic adapting to multiple types of business," solving the problem of repetitive work in traditional radar software where "one model, one development" is required. Business functions can be effectively decomposed according to the hierarchy, and different developers or teams can develop the state hierarchy in parallel, thereby effectively shortening the project development cycle.

[0012] Dynamic configuration and rapid response. The business function configuration table statically configures the state hierarchy and inheritance relationship, realizing the basic framework of the hierarchical state machine that supports system business. It takes effect immediately upon system startup. The state event routing table dynamically binds events and migration paths. By adding, deleting, and modifying routing table entries, new state migration sequences can be defined, enabling rapid response to changes in system business, verification, and expansion.

[0013] Security and reliability. The arbitration management mechanism ensures that unprocessed events have a parent state as a fallback, state transition paths are traceable, and abnormal events are automatically isolated.

[0014] Reduce costs. Reusing the architecture reduces software development and verification costs, especially for civil aircraft airworthiness. A unified architecture lowers the learning curve for new employees and reduces talent development costs. Attached Figure Description

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

[0016] Figure 1 A schematic diagram of a hierarchical state machine for radar software; Figure 2 This is a schematic diagram of a hierarchical state machine and its state transitions. Figure 3 This is a flowchart of the state transition after power-on of a radar based on a hierarchical state machine. Figure 4 This is the structure of the status event routing table; Figure 5 Configure the table structure for business functions. Detailed Implementation

[0017] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0018] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0020] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The illustrations only show the components related to this application and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0021] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0022] This application provides a system control method using a hierarchical state machine.

[0023] Hierarchical State Machines (HSMs) follow an event-driven mechanism and simplify the design of complex systems through state nesting. Their core characteristics include: 1. Nested states: A parent state contains child states and they share common behaviors.

[0024] 2. State inheritance: Child states inherit the behavior of parent states and can override specific events.

[0025] 3. Event routing: Define the event propagation rules, prioritize the processing of events in sub-states, and automatically bubble up unprocessed events.

[0026] 4. Event-driven: State transitions and action execution are completed through event triggers and specific rules.

[0027] A system control method employing a hierarchical state machine includes the following steps: Based on the state classification method of hierarchical state machines, the system control business and control software logic are decoupled, resulting in several sub-states and parent states.

[0028] Combining the concepts of state nesting and state inheritance in hierarchical state machines, a business function configuration table is formed by organizing the parent state, its functions, child states, and their functions according to the hierarchical relationship between the parent and child states.

[0029] Analyze the operational logic of the system control business, identify the events in the control business, and group events with the same trigger source into one category.

[0030] By combining the event routing and event-driven mechanism of the hierarchical state machine, the events in the control business are organized and summarized into a state event routing table. The events in the control business include the current running sub-state of the system, the events to be triggered in the current running sub-state of the system, and the state transition path after the events to be triggered are triggered. The state event routing table is used to configure the state control of the system during dynamic runtime.

[0031] The hierarchical state machine core logic processing engine combines the business function configuration table and the state event routing table to construct the system control hierarchical state machine.

[0032] After the system starts, the core logic processing engine constructs an instance by reading the business function configuration table and the state event routing table; first, it uses the business function configuration table to define the state hierarchy, the states contained in each level and the nesting relationship of states, and the functions to be executed by each state; then, it uses the state event routing table to set the state transition order during dynamic runtime.

[0033] The system uses internal synchronization signals as the event driver to load the initial state of the hierarchical state machine and then run system control.

[0034] This application employs a hierarchical state machine design pattern, decoupling complex radar control operations from software logic to achieve configurable, efficient, and easily expandable operations. When system control operations change, or new projects require the development of system control software, it is only necessary to add, delete, or modify the service function configuration table or the state event routing table according to the actual system control operations and the method of this application, while keeping the core logic processing engine of the hierarchical state machine unchanged, to quickly realize the modification, maintenance, and expansion of radar control operations.

[0035] Based on the state classification method of hierarchical state machines, the specific steps for decoupling system control business from control software logic include: Identify the working state in radar control operations, classify the behavior of different working states of the system, define several states with the same type as sub-states, merge them into a parent state, and obtain several parent states, each parent state containing several sub-states. Focus on a parent state, extract common behaviors from all its child states, and abstract these common behaviors onto the parent state; retain the unique behaviors of each child state within that child state.

[0036] After the system starts, the core logic processing engine reads the parent and child states in the table, creates the nested relationships, reads the behaviors contained in each state in the table, and creates the execution behaviors of each state.

[0037] After the system starts, the core logic processing engine monitors whether the pending events in the current running sub-state of the radar have been triggered. If they are triggered, the dynamic running state transition order is reset according to the state transition path after the pending events are triggered in the table.

[0038] It also includes the construction of an arbitration management module; the functions of the arbitration management module are global state transition order, control scheduling center, and state anomaly handling, specifically: After system startup, the arbitration management module registers the parent states in the business function configuration table read by the core logic processing engine, obtains the state event routing table read by the core logic processing engine, sets the initial state transition order according to system business requirements, sets a default state transition order according to system business requirements, and runs the set initial state transition order, so that the system runs in the initially set sub-state. When the system is running normally in a certain state, if the core logic processing engine detects that a new state transition order is generated due to an event, it will transfer system control and the new state transition order to the arbitration management module. The arbitration management module transfers control to the corresponding parent state according to the state transition order, and designates one or more sub-states to which the parent state belongs as the system running state according to the order. If an abnormal situation occurs during the control transfer process of the arbitration management module, causing the control transfer to fail, the arbitration management module runs the default state transition path to ensure that the system runs in the default sub-state.

[0039] A hierarchical state machine-based system control method is used for the control of radar systems.

[0040] like Figures 1 to 5 As shown in the embodiments, the control method of this application is described in detail using a radar system.

[0041] Step 1: Decouple complex radar control operations from software logic based on the state classification method of hierarchical state machines.

[0042] Step 11: The design consists of three parent state modules and one arbitration management module. These correspond to the parent states required by the hierarchical state machine, the three parent state modules, and a root state, which is the arbitration management module.

[0043] Step 12: Decompose the working state of the weather radar into three parent state modules of the hierarchical state machine, namely the main working mode parent state S1, the self-test mode parent state S2, and the transition mode parent state S3.

[0044] Among them, the parent state S1 of the main working mode includes multiple sub-states: preparation S11, weather S12, terrain S13, and wind shear S14.

[0045] The self-test mode parent state S2 includes power-on self-test S21 and maintenance self-test S22, with two sub-states.

[0046] The transition mode parent state S3 includes two sub-states: screen clearing S31 and periodic self-check S32.

[0047] Step 13: Design the arbitration management module as a root state of a hierarchical state machine, and execute the following functions: Register the parent states S1, S2, and S3 of the hierarchical state machine described in step 12.

[0048] Retrieve the "Status Event Routing Table".

[0049] A default child state is set to ensure that the hierarchical state will operate in the default child state when an unknown event occurs.

[0050] During power-on initialization, the initial state event routing links of the hierarchical state machine are set.

[0051] Manage state event routing links to ensure that the links are executed in sequence.

[0052] Step 14, the functions and operations of each sub-state in step 12 above are as follows: Preparation S11: The radar enters the standby preparation state and waits for the avionics control event to be triggered by the switching operation mode ChangeWM(e11).

[0053] Meteorological S12: Enters the meteorological working state and generates the instructions and parameters required for the operation of each subsystem in this working state, driving the radar to perform meteorological detection functions.

[0054] Terrain S13: This involves entering the terrain working state and generating the commands and parameters required for the operation of each subsystem in this working state, driving the radar to perform the terrain detection function. Wind shear S14: The system enters the wind shear working state and generates the instructions and parameters required for the operation of each subsystem in this working state, driving the radar to perform the wind shear detection function.

[0055] Power-on self-test S21: The power-on self-test working state is entered. This working state will check the operating status of each subsystem, detect and calculate the inherent parameters of the hardware of each subsystem and the connection channels between each subsystem, as well as the overall functional operating status of the radar system.

[0056] Maintenance self-test S22: The maintenance self-test working state is entered. In this working state, the operating status of each subsystem is checked in accordance with the maintenance strategy, and the inherent parameters of the hardware of each subsystem and the connection channels between each subsystem are detected and calculated, as well as the overall functional operating status of the radar system.

[0057] Screen clearing S31: The screen clearing working state is entered, and the instructions and parameters required for the operation of each subsystem in this working state are generated to drive the radar to perform the screen clearing function.

[0058] Periodic self-test S32: The periodic self-test working state is entered. This working state will check the operating status of some subsystems with a custom strategy, and detect and calculate the inherent parameters of the hardware of some subsystems and the connection channels between each subsystem, as well as the operating status of some functions of the radar system.

[0059] Step 2, according to Figure 5 Configure the states and functions described in section 2 above as a "Business Function Configuration Table" to realize static association of radar control services.

[0060] Step 3: Based on the event-driven mechanism of the hierarchical state machine, sort out the complex radar control business operation logic.

[0061] The hierarchical state machine is event-driven, and the radar control service events are divided into: avionics control events and system-defined events.

[0062] Avionics control events (e1) include: Changing operating mode ChangeWM (e11), Changing scan range ChangeScanRange (e12), and entering maintenance self-test TrigBITMantain (e13).

[0063] The system's self-defined events (e2) include: FrameEnd (e21) for completing the previous frame execution, LineScanEnd (e22) for completing the line scan, EntryWS (e23) for entering the wind shear, ExitWS (e24) for exiting the wind shear, BITMantainEnd (e25) for completing the maintenance self-test, ClsEnd (e26) for completing the screen clearing, BITPeriodEnd (e27) for completing the periodic self-test, BITPowerEnd (e28) for completing the power-on self-test, and radar internal synchronization signal (e29).

[0064] The radar control operation logic is as follows: After the radar is powered on, upon receiving the internal synchronization signal (e29), it enters the power-on self-test S21, see... Figure 3 .

[0065] When the current state is Power-On Self-Test S21, upon receiving the system-defined event Power-On Self-Test Completed BITPowerEnd(e28), the system first executes Clear Screen S31, and then automatically enters Preparation S11. See Figure 3 .

[0066] When the current state is preparation S11, after receiving the system-defined event FrameEnd(e21) indicating completion of the previous frame execution, determine the following events: When the ChangeWM(e11) event is received in the avionics control event, the screen clearing S31 is executed first, followed by the periodic self-check S32, and then the weather S12 (or terrain S13).

[0067] When the system receives the EntryWS(e23) event from the self-defined event, first execute the screen clearing S31, then execute the periodic self-test S32, and then execute the wind shear S14.

[0068] When the TrigBITMantain(e13) event is received in the avionics control event, the screen clearing S31 is executed first, and then the maintenance self-test S22 is executed.

[0069] If none of the above events occur, this frame continues with preparation S11.

[0070] When the current state is weather S12, after receiving the system-defined event FrameEnd(e21) indicating completion of the previous frame execution, determine the following events: When the ChangeWM(e11) event is received in the avionics control event, the screen clearing S31 is executed first, followed by the periodic self-check S32, and then the terrain S13 or preparation S11 is executed.

[0071] When the system receives the EntryWS(e23) event from the self-defined event, first execute the screen clearing S31, then execute the periodic self-test S32, and then execute the wind shear S14.

[0072] When the TrigBITMantain(e13) event is received in the avionics control event, the screen clearing S31 is executed first, and then the maintenance self-test S22 is executed.

[0073] When the ChangeScanRange(e12) event is received in the avionics control event, the screen clearing S31 is executed first, followed by the meteorological S12.

[0074] When the LineScanEnd(e22) event is received from the system's self-defined events, the cycle self-check S32 is executed first, followed by the meteorological S12.

[0075] If none of the above events occur, this frame will continue to execute Weather S12. When the current state is terrain S13, after receiving the system-defined event FrameEnd(e21) indicating completion of the previous frame execution, determine the following events: When the ChangeWM(e11) event is received in the avionics control event, the screen clearing S31 is executed first, followed by the periodic self-check S32, and then the weather S12 (or preparation S11).

[0076] When the system receives the EntryWS(e23) event from the self-defined event, first execute the screen clearing S31, then execute the periodic self-test S32, and then execute the wind shear S14.

[0077] When the TrigBITMantain(e13) event is received in the avionics control event, the screen clearing S31 is executed first, and then the maintenance self-test S22 is executed.

[0078] When the ChangeScanRange(e12) event is received in the avionics control event, the screen clearing S31 is executed first, followed by the meteorological S13.

[0079] When the LineScanEnd(e22) event is received from the system's self-defined events, the cycle self-check S32 is executed first, followed by the meteorological S12.

[0080] If none of the above events occur, this frame will continue to execute terrain S13.

[0081] When the current state is wind shear S14, after receiving the system-defined event FrameEnd(e21) indicating completion of the previous frame execution, determine the following events: When the system receives the exit wind shear EntryWS(e24) event from the system's self-defined events, it first executes the screen clearing S31, then executes the periodic self-check S32, and then executes the preparation before entering the wind shear S11 (or meteorological S12 or terrain S13).

[0082] When the LineScanEnd(e22) event is received from the system's self-defined event, if the current weather state is in the wind shear state, the periodic self-check S32 is executed first, and then the wind shear state is executed.

[0083] When the LineScanEnd(e22) event is received from the system's self-defined event, if the current state is wind shear state, the periodic self-check S32 is executed first, and then the meteorological state in wind shear state is executed.

[0084] If none of the above events occur, this frame will continue to execute the meteorological or wind shear state under wind shear conditions.

[0085] When the current state is maintenance self-test S22, after receiving the system's self-set event maintenance self-test completion BITMantainEnd(e25), first execute screen clearing S31, and then execute preparation before entering maintenance self-test S11 or weather S12 or terrain S13.

[0086] When the current state is screen clearing S31, after receiving the system-defined screen clearing completion ClsEnd(e26) event, the system enters the state to be executed after screen clearing, as described above.

[0087] When the current state is periodic self-test S32, after receiving the system-defined event BITPeriodEnd(e27) for periodic self-test completion, the system enters the state required to be executed after the periodic self-test, as described in ①-⑥ above.

[0088] Step 4, according to Figure 4The aforementioned sub-states, events, and control business operation logic are configured as a "state event routing table" to dynamically configure radar control functions.

[0089] The design of the hierarchical state machine core logic processing engine is as follows: The arbitration management module is designed with the following attribute members: arbitration link queue, arbitration link queue lock flag, and status event routing table. Its operational logic is as follows: Initialization sets the arbitration link queue to power-on self-test (S21). Upon receiving a control request, it performs queue operations based on the arbitration link queue lock flag. Based on the arbitration link queue information, it transfers control to the corresponding parent status module.

[0090] The attribute members of the main working mode are the sub-state queue, which contains historical sub-states.

[0091] The main working mode is designed as the parent state as follows: entry: Read historical sub-states; Read the sub-state queue; execute: Transfers control to the corresponding sub-state; `exit`: Saves the historical sub-states. Transfers control to the arbitration module. The sub-state design of the main working mode is as follows: entry: Event judgment, generating path chain; execute: Performs the functions and operations of this sub-state; exit: Control is transferred to the parent state module.

[0092] In self-check mode, the attribute members are sub-state queues.

[0093] The self-checking mode is designed as the parent state as follows: entry: Read the sub-state queue; execute: Transfers control to the corresponding sub-state; exit: Control is transferred to the arbitration module.

[0094] The sub-state design of the self-check mode is as follows: entry: Event judgment, generating path chain; execute: Performs the functions and operations of this sub-state; exit: Control is transferred to the parent state module.

[0095] The attribute members of the transition mode are sub-state queues.

[0096] The transition mode, as the parent state, is designed as follows: entry: Read the sub-state queue; execute: Transfers control to the corresponding sub-state; exit: Control is transferred to the arbitration module.

[0097] The sub-state design of the transition mode is as follows: entry: empty; execute: Performs the functions and operations of this sub-state; exit: Control is transferred to the parent state module.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A system control method using a hierarchical state machine, characterized by, Comprising the following steps: According to the state classification method of hierarchical state machine, the system control business is decoupled from the control software logic to obtain a number of sub-states and parent states: Combined with the state nesting and state inheritance of hierarchical state machine, the parent state, the function of parent state, the sub-state and the function of sub-state are organized according to the hierarchical relationship of parent state and sub-state to form a business function configuration table; The running logic of system control business is sorted out, and the events in the control business are identified, and events with the same event trigger source are classified into a category; Combined with the event routing and event driving mechanism of hierarchical state machine, the events in the control business are organized and summarized to form a state event routing table, which contains the current running sub-state of the system, the triggered event in the current running sub-state of the system, and the state migration path after the triggered event is triggered. The state event routing table is used to configure the state control of the dynamic running system. The hierarchical state machine core logic processing engine combines the business function configuration table and the state event routing table to build the system control hierarchical state machine. After the system is started, the core logic processing engine builds an instance by reading the business function configuration table and the state event routing table. First, the state hierarchy is defined by the business function configuration table, including the states contained in each level and the state nesting relationship, and the functions to be executed by each state. Then, the state migration sequence in dynamic running is set by the state event routing table. And through the internal synchronization signal of the system as the original event driving, the initial state of the running hierarchical state machine is loaded, and then the system control is run.

2. The system control method employing a hierarchical state machine according to claim 1, wherein, The specific steps of decoupling the system control business from the control software logic according to the state classification method of hierarchical state machine include: Identify the working state of radar control business, classify the behavior of different working states of the system, define several states with the same type as sub-states, merge them into a parent state, and obtain a number of parent states, each of which contains a number of sub-states; Focus on a parent state, extract the common behavior from the behaviors of all its sub-states, and abstract the common behavior to the parent state. Keep the behaviors of each sub-state in each sub-state.

3. The system control method employing a hierarchical state machine according to claim 1, wherein, After the system is started, the core logic processing engine reads the parent states and sub-states in the table, creates the nesting relationship, reads the behaviors contained in each state, and creates the execution behaviors of each state.

4. The system control method employing a hierarchical state machine according to claim 1, wherein, After the system is started, the core logic processing engine monitors whether the triggered event in the current running sub-state of the radar is triggered. If triggered, the state migration sequence in dynamic running is reset according to the state migration path after the triggered event is triggered.

5. The system control method employing a hierarchical state machine according to claim 1, wherein, It also includes building an arbitration management module; After the system is started, the arbitration management module registers the parent states in the business function configuration table read by the core logic processing engine, obtains the state event routing table read by the core logic processing engine, sets the initial state migration sequence according to the system business requirements, sets a default state migration sequence according to the system business requirements, and runs the initial state migration sequence set, so that the system runs in the initial set sub-state, When the system is in a normal state, if the core logic processing engine monitors that a new state transition sequence is generated due to an event being triggered, the system control right and the new state transition sequence are transferred to the arbitration management module, the arbitration management module transfers the control right to a corresponding parent state according to the state transition sequence, and specifies a sub-state or a plurality of sub-states belonging to the parent state as a system running state according to the sequence: If an abnormal situation occurs in the control right transfer process of the arbitration management module, resulting in a failure of the control right transfer, the arbitration management module runs a default state transition path.

6. The system control method employing a hierarchical state machine according to claim 1, wherein, The system control method using the hierarchical state machine is used for the control of a radar system.

Images