A simple elevator Status Model

Question :"Simple Elevator Control System"

Elevators that we see in daily life. Have you ever thought about its internal running mechanism and implementation methods. Now let's discuss how the elevator runs.

1. Try to figure out the architecture of the elevator system in your mind. Show your thoughts boldly.

2. Draw the status conversion chart (STOP, rise, fall, open the door, alarm, etc.) during the elevator operation and the flowchart of the elevator operation.

========================================================== ========================================================== ================================

This article mainly discusses several implementation methods of the state machine. It does not matter whether the State Division of the elevator is appropriate.

1 Preface

This article describes the state machine model of an elevator based on the change of the elevator running status, and provides an efficient implementation method of the state machine mode.

 

2. Elevator status 2.1 Status transition diagram

 

2.2 Status List

The status chart lists the statuses as follows:

Stopped: Statestopping. The door is closed.

Elevator rising: Stategoingup

Elevator falling: Stategoingdown

Elevator Door Opening: Stateopened

Overload alarm status: Statewarning. The door is open.

 

Description: The status of statestopping is started. The elevator stop status includes the closing status, and the opening status is a separate status.

 

2.3 event

Events that an elevator can receive are as follows:

Upper-- Event_up

Lower-- Event_down

Arrival floor --Event_stop

Open door-- Event_open

Close-- Event_close

Alert-- Event_warn

Alarm Elimination-- Event_delwarn

 

These events are generated by hardware based on the current mechanical condition. For example, if someone presses a button on a layer, the hardware or control system sends an alarm to the elevator according to the actual situation.Upper/lowerEvent. The elevator state machine is responsible for handling corresponding events in the current state, so as to jump to the next new state and generate new running results. This article only focuses on the Status Switching Model of the elevator itself.

 

2.4 status migration table

 

Current Status	Event Type	Conversion status
Statestopping	Event_open	Stateopened
Statestopping	Event_up	Stategoingup
Statestopping	Event_down	Stategoingdown
Stateopened	Event_close	Statestopping
Stateopened	Event_warn	Statewarning
Stategoingup	Event_stop	Statestopping
Stategoingdown	Event_stop	Statestopping
Statewarning	Event_delwarn	Stateopened

 

3. Implement the 3.1 table driving mode for the state machine

Description: Omitted

Advantages: The code is simple and applicable to standard state machines such as PPP protocols. You only need to care about the status table.

Disadvantages: The Status jump logic is determined by the status table, which is not intuitive and cannot be converted from the Code to reflect the status.

Implementation: Omitted

3.2 state mode

Description: State mode puts every branch of the event processing into an independent class, and each event corresponds to a virtual function of the derived class.

Advantages: Each State corresponds to a separate class that separates the behavior of different States. By defining a new derived class, you can add new States and transformations.

Disadvantages: A State corresponds to a derived class and adds the number of subclasses. The state base class must define virtual functions for each subclass, that is, all messages to be processed by State objects must be declared in the abstract state class, increasing redundancy. Because all message processing functions are virtual functions, on the one hand, the virtual function table occupies memory, on the other hand, it increases the indirect nature of calls.

Implementation: Omitted.

 

3.3 member function pointer implementation

Description:The current status of the elevator is saved by a member function pointer. Each status corresponds to a member function pointer. The transition form of the status is the assignment of the member function pointer. When an event needs to be handled, it is delegated to the current State for processing.

Advantages: The list of events processed by each State is clear, and the state conversion is implemented by assigning values to the member function pointer, reducing the cost.

Disadvantages: The amount of code is related to the number of States and the number of events, which increases or decreases accordingly.

Implementation:

 

/*** Event. */typedef Enum tagt_eventtype {event_open = 0, event_up, event_down, event_close, event_warn, event_stop, event_delwarn} t_eventtype;

/*** Elevator entity. */class elevator {public: typedef void (elevator: * t_elevatorstate) (t_eventtype tevent); // declare the member function pointer elevator (): m_tnowstate (& elevator: statestopping) // The initial status stops the {}/*** external interface and receives the event */void processevent (t_eventtype tevent) {(this-> * (m_tnowstate) (tevent ); // submit it to the current State for processing, member function call} PRIVATE: void statestopping (t_eventtype tevent); // stop the status void stateopened (t_eventtype tevent ); // void stategoingup (t_eventtype tevent); // void stategoingdown (t_eventtype tevent); // void statewarning (t_eventtype tevent ); // overload status void setnextstate (t_elevatorstate state) {m_tnowstate = State; // member function pointer value assignment} t_elevatorstate m_tnowstate;/*** <current state. */}; void elevator: statestopping (t_eventtype tevent) {Switch (tevent) {Case event_open ://... // notification hardware: setnextstate (& elevator: stateopened); break; Case event_up ://... // notify the hardware to rise setnextstate (& elevator: stategoingup); break; Case event_down ://... // notification hardware: setnextstate (& elevator: stategoingdown); break; default: Break ;}} void elevator: stateopened (t_eventtype tevent) {Switch (tevent) {Case event_close ://... // notification hardware: Close setnextstate (& elevator: statestopping); break; Case event_warn ://... // notification of hardware overload, alarm setnextstate (& elevator: statewarning); break; default: Break ;}} void elevator: stategoingup (t_eventtype tevent) {Switch (tevent) {Case event_stop ://... // notification hardware: setnextstate (& elevator: statestopping); break; default: Break ;}} void elevator: stategoingdown (t_eventtype tevent) {Switch (tevent) {Case event_stop ://... // notify the hardware to reach setnextstate (& elevator: statestopping); break; default: Break ;}} void elevator: statewarning (t_eventtype tevent) {Switch (tevent) {Case event_delwarn: //... // notify the hardware to delete the alarm setnextstate (& elevator: stateopened); break; default: break ;}}

/*** The Controller provides the interface between the elevator entity and the external system. */class controller {public: void processevent (t_eventtype tevent) {m_televator.processevent (tevent);} PRIVATE: Elevator m_televator;/** <elevator entity. */};

In this implementation method, the member function pointer lists events in each State. In the state mode, you need to enumerate events before calling the corresponding Event Response Function of the state machine. Each has its own characteristics.