Abstract: By analyzing the characteristics of industrial control systems, this paper proposes to use the state machine concept for industrial control software design. The paper discusses in detail the step-out problem of high-speed state machines and the state partitioning problem of state machines in the control layer. Combined with specific application examples, a state machine-based implementation method is given. Experiments show that the state machine design method helps to accurately describe the behavior of the controlled object, and the robustness and reliability of the software are significantly improved. Keywords: Finite state machine, industrial control software, control loop, state partitioning 1. Introduction 1.1 General Problems of Industrial Control Software Industrial control software design can be divided into two main categories: control loop-based and real-time operating system-based. A control loop connects various functional modules into a ring structure. Its characteristic is that no functional module can have an infinite loop, and even loop statements with too many iterations should be avoided. This ensures that the functional modules can be traversed as quickly as possible in a real-time sense, thereby meeting the needs of real-time multitasking. In each functional module, a state machine is generally used to describe the state of the module. A real-time operating system can schedule functional modules according to priority and task status through a low-level mechanism. In this case, each functional module is represented as a "task". However, each task still constitutes an independent control loop structure and still requires a state machine for description. This paper will discuss the application of state machines in industrial control in conjunction with engineering practice, providing a general model and key points to note. 1.2 Finite State Machines Finite state machines are an important conceptual approach. From a mathematical perspective, it is actually a quintuple M = (I, O, S, δ, λ), where I and O represent input and output respectively, S is the state vector, δ is the next-state equation (δ: S×I -> S), and λ represents the output equation (λ: S×I -> O). Finite state machines can be categorized into hierarchical state machines and concurrent state machines. Hierarchical state machines are similar to subroutine scheduling in software: a higher-level state corresponds to a lower-level state machine. This higher-level state resides in a state of the lower-level state machine. This lower-level state is called a substate. Unlike subroutine calls, which are constrained by the system stack depth, hierarchical state machines allow developers to arbitrarily specify the depth based on the hierarchical movement patterns of the controlled object. Similar to the purpose of subroutines, hierarchical state machines aim to improve the modularity of control software and reduce the complexity of state analysis. Concurrent state machines focus on describing the scheduling of state machines. The state machine itself cannot implement concurrent functionality; concurrency is achieved through software scheduling. If we understand a state machine as a task, then the implementation of concurrency becomes clear. In a control loop, a "task" is a functional module. We only need to connect multiple state machines in series in the loop to achieve concurrent control with multiple inputs and multiple outputs. At this point, multiple state machines coexist spatially, but are called in a time-sharing manner, with the calling cycle equivalent to one complete scan of the control loop. However, if the CPU's processing speed is fast enough, this cycle will be fast enough to achieve "real-time" operation, thus enabling these multiple state machines to run "concurrently." Similarly, in a multi-tasking operating system, the implementation of "concurrency" is easier to understand. Besides concurrent control within a single task, concurrent operation of multiple state machines also exists between tasks. Of course, from the CPU's perspective, as long as it is a single-core CPU, there is never true "concurrency"; it can only process one specific state machine at any given time. However, multitasking operating systems provide a low-level mechanism to schedule tasks that were originally scheduled solely by the control loop. 2. The Role of Finite State Machines in Foreground-Background Information Interaction Industrial control systems generally have a human-machine interface. The typical operation mode is for the user to enter a page, select an operation, and execute it. The human-machine interface is usually set as an independent module. The software structure of this module is a message control loop. User operations at the hardware interface are encapsulated into messages by the interface driver and added to the message queue of the dedicated interface module. The message control loop cyclically scans this queue; if a new message is found, it is extracted, interpreted, and then encapsulated into a new message and sent to the background for execution. The interface modules of the foreground and background software are responsible for distributing interface messages to various execution modules. The message should include the target module's encoding, command encoding, and command parameters. The software structure of the foreground and background interface modules often adopts the following two modes. [align=center] Figure 1 Two Message Distribution Structures[/align] Mode 1's output structure directly distributes messages to each module based on the target module encoding of the message data. Mode 2, on the other hand, distributes messages to each module based on the current system state. In other words, Mode 2 adds a system-level state machine to Mode 1. Let's examine the impact of these two different output structures. Industrial control software designers typically encounter two situations. First, during the development phase, both the interface task and the control task may malfunction during joint debugging. For the interface task, there might be a mis-sent message due to its own reasons; for the control task, there might be an error in the output timing. In this case, it's necessary to quickly locate the fault during joint debugging to shorten the development cycle. Second, during product operation, harsh operating conditions can cause abnormalities in the buffer data. For example, a bit flip in the module encoding of the message header will directly cause the control task to receive an incorrect interface message. With Mode 1, if the interface message is incorrect, global chaos will occur. For example, after module 1 receives a message, it starts outputting a control timing sequence. During this time, the interface layer sends an incorrect message, which is then distributed to module 2, causing module 2 to immediately start outputting the timing sequence. This unwanted timing output could be disastrous in industrial control. When this phenomenon occurs during joint debugging, it's impossible to immediately determine whether the problem lies with module 1 or the interface layer. However, using Mode 2 can shield against this chaos. As shown in Figure 2, which illustrates the handling of error messages by different dispatch structures, we can see that because Mode 2 uses a global state machine to mark the current state of the software, messages first reach the corresponding state handler before being dispatched. At this time, the dispatch statement can filter out modules that should not be called based on the current state. Even if an error occurs, it will be filtered out, waiting for the correct message to arrive. Furthermore, it can be further optimized to notify the interface layer when an error message is received. It is evident that adding a global state machine that marks the background state to the interface layer of the control software's foreground and background helps enhance the robustness of the software. 3. State Machine Step-by-Step Problem Industrial control software essentially provides ordered outputs based on certain logical conditions. Different states can be divided according to the order of the outputs. In the embedded field, logical conditions are the user input and the sensor states. These conditions determine the state transitions. Here, we discuss state machines built based on sensor inputs. Clearly, its operating speed is much higher than the aforementioned system-level state machines. These state machines are distributed in the software's control layer, and it is they that enable the controlled object to operate in an orderly, precise, and high-speed manner. For such a high-speed state machine, insufficient consideration can lead to step loss or skipping, i.e., misstepping in high-speed state machines. Since the transition conditions of the control layer state machine originate from sensor signals, if changes in the sensor signals cannot be fully tracked, the transition conditions will be missed, preventing the state machine from transitioning to a new state. This results in step loss. There are two situations that can cause missed sensor signal detection: First, the sampling frequency is not high enough, missing some signals with short holding times. This can be solved by increasing the sampling frequency in hardware. Second, there are design flaws in the state machine, as detailed in the following example. [align=center] Figure 3: State machine experiencing step loss[/align] As shown in Figure 3, state 1 transitions to state 2 based on sensor signal a, and state 2 transitions to state 3 based on sensor signal b. If signal b emits a complete pulse before signal a, since signal b is not needed in state 1 according to the state diagram, the state machine will lose step after transitioning to state 2. Solving this problem requires pre-analyzing the relationship between signals a and b. If signal b always appears before signal a, then we can swap the condition judgments of states 1 and 2. If the two signals are concurrent, then we need to merge state machines 1 and 2, and use signals a and b as the combined condition for transitioning to state 3. Therefore, the key to solving the out-of-step problem is to carefully examine the possible changes in sensor signals and their relationships when the controlled object is in this state. When dealing with "input-output pairs", we must be careful to prevent the state machine from skipping steps. "Input-output pairs" are a control mode frequently encountered in the embedded field, similar to a response mechanism. The control layer gives an output, causing the sensor signal to change and provide feedback. After a period of time, the controlled object completes its movement, the sensor signal returns to its initial state, and the control layer can then cancel the original output and provide relevant processing. Designers may intentionally or unintentionally focus on "when to cancel the output", thus designing a state machine with potential problems as shown in Figure 4(a). [align=center] Figure 4 State diagram with skipping steps[/align] However, it takes time for the controlled object to move after receiving the output from the control layer, and for the sensor to sense the movement and provide a signal change. According to the state machine in Figure 4(a), it is possible to skip the state of sensor signal change and directly reach the "cancel output" state. As a result, the output of the control layer is only momentary or even non-existent, which is called skipping. To solve the skipping problem, designers need to carefully analyze all "input-output pairs" and subdivide the states. As shown in Figure 4(b), a new state waiting for the object to move is added to ensure that the object's movement is only judged to stop after the output of the previous state drives the object to actually move. However, while subdividing the states, attention should be paid to preventing step loss. The finer the state is divided, the more attention should be paid to analyzing all possible signal changes in this state. 4. State division problem of state machine in industrial control software Considering a state machine as an action module and connecting these modules in series, the concurrent output of these actions can be achieved. If it is based on an operating system, the state machine can also be placed in different tasks to achieve concurrent output. Each state machine is set to an idle state, which is entered when it is not needed. Communication between state machines in the same control loop can be achieved using flag bits or state variables, and state machines in different tasks can exchange information through a global structure to achieve synchronization. Scheduling a state machine is not difficult; the key lies in how to divide the state machine action modules according to the motion pattern of the controlled object. In practical applications, "periodicity" is crucial for solving the problem. Outputs with "reciprocating motion" characteristics are extracted from complex motion sequences and grouped into a single state machine along with other synchronous inputs and outputs. Thus, a state machine is established for each motion mode with "reciprocating motion" characteristics. Simultaneously, the methods described above can be used to achieve concurrent and synchronous control of these motion modes. The following example, a certain type of fuel injection system, illustrates how to divide the state machine. This fuel injection system consists of two paths, left and right. Each path comprises a fuel chain, a swing arm, and a sliding plate. Multiple fuel loading modules are loaded onto the fuel chain. The swing arm lifts the modules to the sliding plate, which then propels them into the combustion chamber, and the fuel chain advances once. The entire process involves alternating fuel supply from both paths. Fuel supply is divided into low-speed and high-speed supply. The timing diagram is shown below, with the black horizontal line representing the duration of the action. [align=center]Figure 5 Low-speed fuel supply timing diagram[/align] [align=center]Figure 6 High-speed fuel supply timing diagram[/align] Let's first analyze the low-speed fuel supply situation. It can be seen that the actions of oil tank descent - throttle closing - oil tank rising - throttle opening - slide bar (left or right) occur alternately. After the slide bar completes its action, the oil tank begins a new round of action. Due to this periodicity, these actions can be categorized into state machine A. The oil chain action is triggered by the slide bar action. When the slide bar reaches a certain position, the oil chain starts, and its movement continues until the next movement on the same side begins. If the oil chain movement is also categorized into state machine A, it breaks the periodicity of A, thus increasing the complexity of A's state determination. Furthermore, from the perspective of the nature of the motion, the oil chain movement is triggered by the slide bar movement in state machine A. Therefore, defining the oil chain movement in another state machine B is more reasonable. B is triggered when A reaches a certain state. After triggering, B and A are concurrently running state machines. The difference between high-speed and low-speed timing is that the right-side state machine A has already started before the cycle of the left-side state machine A has been completed. However, despite this, for a single path, the oil tank descent - throttle closing - oil tank rising - throttle opening - slide plate (left or right) still exhibits a periodicity. Therefore, a state machine A should be established for each of the left and right paths, namely A1 and A2. The state machine codes for A1 and A2 are the same, and the state machine on the opposite side is triggered immediately after it is determined that the oil tank has risen again. Similarly, for the oil chain movement, state machines B1 and B2 should also be established. In a multi-tasking system, a task can be established for each of the left and right paths. Ax and Bx are assigned to one of the tasks. In summary, by dividing the motion of the controlled object according to the period and establishing the corresponding state machine, various complex parallel timing outputs can be described. 5. Conclusion This paper analyzes the application of the state machine concept in software design based on the engineering practice of embedded industrial control software design. A general model for the interaction of front-end and back-end information in embedded software is given; the step-off problem that is easy to occur in high-speed state machines is analyzed; finally, combined with a certain type of oil supply system, the periodicity criterion for dividing the state machine is given, which has certain reference value for analyzing the motion of the controlled object. References [1]. Zhou Huaide, Xiao Chuan, Wei Haozhihang. Design and development of intelligent camera system based on DSP and CPLD [J]. Microcomputer Information, 2006, Vol.22, No.17 [2]. Wang Jian, Zhao Haiyan. Redundancy design of controller based on CPLD [J]. Microcomputer Information, 2005 Vol.12, No.23 [3]. James R. Armstrong F. Gail Gray: VHDL Design Representation and Synthesis. China Machine Press. [4]. Zhao Shixia, Yang Feng, Liu Jiesheng. VHDL and microcomputer interface design. Beijing, Tsinghua University Press, 2004. [5]. Wang Cheng, Xue Xiaogang, Zhong Xinchao. Detailed explanation of Xilinx ISE. Beijing: People's Posts and Telecommunications Press, 2004. [6]. Yang Qing. Design and optimization of finite state machines. Journal of Hubei University for Nationalities (Natural Science Edition), Vol.24, No.1, Mar 2006. [7]. Wu Yangbo, Wang Shuguang, Hu Jianping. VHDL design and optimization of finite state machines. Information Technology. Vol.28, No.1, Jan.2004. [8]. Li Xia, Wang Yongzhang, Liang Hongbin, Zhong Li. Application of finite state machines in open numerical control systems [J]. Computer Integrated Manufacturing Systems, 2005, 03: 429-432. [9]. Alain Girault, Bilung Lee, and Edward A. Lee, “Hierarchical Finite State Machines with Multiple Concurrency Models”, IEEE Trans. Computer-Aided Design Of Integrated Circuits And Systems, Vol 18, No.6, pp. 742-760, June, 1999.