电梯控制流程图全解读：状态机模型、调度算法与PLC实现

简介：这是一份面向电气自动化、楼宇智能化及电梯控制教学场景的PDF文档，系统讲解电梯控制流程图的核心知识点。内容涵盖电梯上下行流程、外呼响应流程、开关门控制流程三大模块，并给出最远反向呼梯响应、平层开关门延时等关键逻辑说明，可直接用于课程设计、毕业设计或电梯控制原理自学。文档共1个PDF文件，压缩包整体仅363KB，清晰完整、支持编辑与打印。目前已有489人学习下载，适合控制类专业学生、电梯维保人员及嵌入式开发者用作方案参考。文档以流程图加文字说明的形式呈现，可帮助读者快速理解电梯调度与楼层选择机制，并掌握PLC/单片机实现电梯控制时的逻辑分支设计思路。 收到一份《电梯控制流程图.pdf》是什么体验？我在自动化项目里接过不少这样的文件，第一眼觉得图挺规整：矩形框、菱形判断、几个箭头，层级也清楚。可真正到了写控制程序的时候，问题全冒出来了——门明明关着，为什么流程图上没画“关门途中有人挡门”这条线？电梯在3楼往上跑，5楼有人按了向下，7楼也有人按了向下，到底该听谁的？流程图里一个“判断是否有召唤”的菱形，背后其实是整整一套调度算法。这篇文章想跟你聊透电梯控制流程图：它到底画什么、核心逻辑怎么组织、从图到代码怎么落地，以及在真实项目里最容易画错、想漏的地方。内容偏向控制逻辑设计，适合做PLC、嵌入式控制的工程师，正在做毕业设计或竞赛的学生，以及需要跟研发对齐需求的产品经理。

1. 先搞明白：电梯控制流程图到底在画什么

1.1 一份流程图背后牵着的四大子系统

电梯控制流程图不是凭空画的，它是对一套实时控制系统的抽象描述。很多初学者一上来就找“电梯控制流程图模板”，结果套了一个不完整的图，越改越乱。要画对图，你得先知道电梯控制到底分哪几块：

• 召唤与输入系统：轿厢内选层按钮（也就是内呼）、每层上下行按钮（外呼）、轿厢内开关门按钮、超载开关、消防钥匙开关等。这是流程图的“事件来源”。
• 位置与测速系统：各楼层的平层感应器、门区开关、减速点限位、曳引机编码器、上下端站限位。流程图里的“是否到达目标楼层”“是否开始减速”全靠这些信号做判断依据。
• 驱动与执行系统：曳引机（正转向上、反转向下、变频调速）、抱闸、开门机、门锁回路。这是流程图的“动作出口”。
• 安全与保护系统：急停回路、安全钳信号、限速器信号、超载、断电平层、消防联动等。它们的特点是“随时可能触发”，而且一旦触发必须接管控制权。

在画流程图的时候，不需要把四套系统的每个信号都变成图上的一个节点。图要表达的是逻辑关系：哪些输入条件组合起来，触发什么状态变化，最终输出什么动作。信号采集和硬件细节可以放到另一个层面的“接线图”或“变量表”里去管。我见过最典型的错误，就是把传感器信号、按钮扫描、电机动作全都画到一张图里，结果一张A3纸不够用，缩印之后字都看不清，审图的人根本没法给出有效意见。

1.2 电梯控制为什么天生适合用“状态机”来组织

电梯控制和普通顺序控制最大的不同在于：召唤事件是异步到达的。你没法预知下一秒有人按几楼，也没法让乘客“排队等待”到一个合适的时机再按按钮。电梯必须随时响应、随时决策，而且决策还要连贯——不能因为中途来了个新召唤就把当前运行方向改掉，那样电梯会在楼里来回抖。

这就是典型的离散事件系统。对付这种系统，最合适的就是状态机模型：任意时刻，电梯必然处于且只处于一个状态；某个事件发生之后，根据当前状态和事件类型，迁移到下一个状态。流程图本质上就是状态机的可视化表达，菱形判断是事件条件，箭头是迁移方向，矩形是迁移过程中执行的动作。

用个生活类比：电梯像一个银行柜台，多个队伍（各楼层召唤）同时排着，柜员（轿厢）一次只能服务一个方向，处理完当前方向的任务之后才换队列。流程图就是把这个“服务规则”写下来，让程序员和调试人员看着同一份规则干活。理解了这一层，你再看任何一张电梯控制流程图，都会觉得它不过是在回答三个问题：现在在哪个状态？发生了什么事件？下一步去哪个状态？

2. 拆开电梯的决策脑：状态、召唤与方向算法

2.1 六个基础状态与它们之间的切换条件

状态是电梯控制流程图的骨架。无论图多复杂，基本都能归纳为六个基础状态，我用表格列出来，方便对照：

这里有个设计取舍要讲清楚：运行状态要不要拆成“上行运行”和“下行运行”两个状态？拆的好处是流程图里能少一个方向变量，看起来直白；坏处是几乎所有涉及运行的判断都要写两份，图会膨胀一倍。我自己的做法是保留一个运行状态，另外单独维护一个方向变量（向上/向下/无），这样主流程只需要一套运行逻辑，方向只参与“到站判断”和“方向决策”这两个环节。实际项目里这两种画法都有人用，但如果你画的是单台电梯的完整控制图，我建议用后者，扩展性明显更好。

2.2 内呼、外呼怎么合并成一张召唤表

召唤是电梯的“任务来源”，但内呼和外呼的逻辑含义不一样，处理方式也因此不同。内呼是乘客在轿厢里选的目标楼层，意味着“无论电梯现在往哪个方向走，只要这个楼层出现在前方路径上，就必须停靠”。外呼是乘客在楼层上按的，分成上行和下行两种，它表达的是“我希望电梯往这个方向来”。

实际工程里，一般不会为内呼、外呼分别维护两套复杂的决策逻辑，而是统一登记到一张按楼层索引的召唤表里，每条记录带方向属性。比如：

内呼置位时，方向栏可以不区分，因为它不参与方向决策，只参与“是否停靠”的判断；外呼则必须区分上下行，因为它是方向决策的直接输入。这里的核心规则是：内呼可以拦停任何方向经过的电梯，而外呼只能拦停沿对应方向经过的电梯。比如电梯正在下行，经过5楼时，5楼的内呼可以把它拦停；但5楼的上行外呼不能把它拦停，因为电梯下行时停靠5楼，乘客是要上楼的，方向和客流不一致，停开门不仅低效，还会让乘客产生困惑。

2.3 顺向优先与最远端反向：调度算法的核心

单台电梯的调度核心就一句话：顺向截梯，反向到最远端再换向。听起来简单，实际画起来很多人就乱了。

举个例子：电梯当前在3楼，正在向上运行。此时5楼有人按了上行外呼，7楼有人按了下行外呼，2楼有人按了下行外呼。

电梯的决策过程是这样的：

1. 当前方向是上行，优先响应上行路径上的顺向召唤。5楼的上行外呼是顺向的，所以电梯继续上行到5楼停靠、开门。
2. 停靠5楼并重新检查：当前方向（上行）上已经没有其他顺向召唤了，但7楼还有一个下行外呼。这个召唤虽然在反方向，但它位于电梯当前所在位置的上方。
3. 按“最远端反向”规则，电梯继续上行到7楼，随后换向为下行，在7楼停靠并开门，响应这个下行召唤。
4. 换向后，下行方向有2楼的下行外呼，于是电梯一路下行，到2楼停靠、开门。
5. 至此召唤表清空，电梯在2楼进入待机，关门。

很多新手在这里犯的错是：以为电梯到5楼后，应该立刻掉头向下，结果7楼的下行召唤永远等不到电梯。记住了，反向召唤只有在“当前方向无顺向任务，且该反向召唤位于电梯继续前行的路径上”时，才通过“继续前行到最远端再换向”的方式响应。这个规则保证了电梯不会在运行方向上反复横跳，乘客等待时间也不会因为换向而无限拉长。流程图里，方向决策必须画成一个专门的判断环节，把它放在“每次停靠开门之后”和“从待机启动之前”这两个位置，其他位置不应出现方向重算。

3. 动手画图：从顶层主流程到子流程的拆分规范

3.1 顶层主流程的骨架与循环方式

电梯控制流程图最忌讳“一张图画到底”。正确做法是分两层：顶层主流程只画状态骨架，具体动作全部用“预定义处理”节点指向子流程。你可以把顶层主流程想象成电视剧的目录页，每个章节对应一集，具体剧情在那一集里演。

顶层主流程的骨架一般长这样：

LOOP: 扫描内呼、外呼按钮，更新召唤表 检查安全回路（急停、超载、消防等） 若安全异常 → 进入故障子流程，跳过本轮 CASE 当前状态: 待机: 召唤表为空 → 保持待机 召唤表非空 → 确定方向，进入关门，随后运行 运行: 到达当前方向的顺向目标楼层 → 减速、平层、停车，进入开门 未到目标楼层 → 继续运行，同时接收新召唤 开门保持: 延时未到 → 保持 延时到或收到关门指令 → 进入关门 关门: 门锁未接通 → 继续关门，检测防夹 门锁接通 → 进入运行 故障: 执行故障子流程，等待复位 END CASE END LOOP

顶层主流程只回答“现在处于什么状态、下一步去哪个状态”，不回答“门怎么开、力矩怎么设”这类细节。这样做的好处是，哪怕电梯有几十个输入信号，主流程的核心循环也能控制在二十行以内。审图的人拿到PDF，先看主流程，五分钟就能理解整个电梯的行为框架，然后再按编号去翻子流程，效率高得多。

3.2 必拆的三个子流程：门、平层、安全

主流程里最典型的预定义处理节点有三个：门控子流程、平层子流程、安全与故障子流程。这三个子流程几乎每台电梯都要画，而且它们各自都有“一个环节内多个分支子流程”的情况，正好借此说清楚子流程怎么展示。

门控子流程里，从“关门”状态出发，至少要分出三个分支：一是正常关门到位，进入运行；二是关门途中检测到光幕或安全触板信号，重新打开门；三是关门过程超过规定时间仍未到位，输出关门超时报警。这个子流程单独画一页，编号SP-01，主流程里只需要一个“门控”节点，旁边标注“见SP-01”。子流程页内部如果有多个分支，建议用编号B1、B2、B3标在分支线上，并在页脚配一个分支说明表，审图的人不用反复比对就能看懂每个分支触发的条件和动作。

平层子流程解决的是“电梯怎么准停”的问题：运行过程中先经过减速点，从高速切换成低速爬行；平层感应器产生触发信号后，控制抱闸动作，完成停车；最后还要用门区信号确认轿厢确实停在了可开门的安全区域内。有的系统把平层和开门之间的逻辑做成联锁，平层信号没到位，即便门区信号到位也不允许开门，这个联锁条件建议在平层子流程末尾明确画出来。

安全与故障子流程是把急停、超载、消防、断电平层等所有异常情况集中到一张“优先级表”里处理。为什么要把它们集中画？因为如果每一种异常都画进主流程，主流程里的判断线会多到没法看。集中处理之后，主流程只需要保留一个“安全回路是否正常”的判断入口，具体异常类型和处置动作全部下沉到子流程。

3.3 图元、泳道与绘图工具的选择

画电梯控制流程图，图元规范很重要。流程图形状代表的意思虽然各工具大同小异，但团队内部最好统一，不然换个人读图就容易产生歧义。我常用的约定是这样：

还有一个容易被忽视的技巧：用泳道。电梯控制涉及“轿厢侧信号”“控制板逻辑”“曳引机与门机执行”三个不同角色，用三条泳道把它们分开，每个图元放进对应的泳道，读者一眼就能看出信号从哪来、动作由谁执行。比如“召唤按钮扫描”放在轿厢侧泳道，“方向决策”放在控制板泳道，“变频器启动”放在执行泳道，整个系统的信号流向非常清晰。

工具方面，我试过Visio、ProcessOn、draw.io、PlantUML。Visio适合企业环境，模板多但收费；ProcessOn在线协作方便，适合多人评审；draw.io免费且支持离线，最推荐日常用；PlantUML适合习惯用文本描述流程图的工程师，改起来快，但画复杂分支时不如鼠标工具直观。无论选哪款，最后输出PDF交付时，记得把“图例”放在第一页或末页，PDF是给人审的，没有图例的流程图在会议桌上会被反复问同一个问题：“这个双竖线框是什么？”

4. 流程图里最容易被画错的三类边界场景

4.1 关门中途重新开门：防夹时序怎么表达

这是我在评审图纸时见过最多的问题。很多入门版本的流程图把关门画成一条直线：关门 → 门锁接通 → 运行。但真实电梯在关门过程中随时可能有人伸手挡门，光幕和门缘安全触板会给出防夹信号。正确的画法是从“关门”状态拉出一条分支，条件是“收到防夹信号”，目标状态是“重新开门”。

光是加这条分支还不够，这里有个实测中踩过坑的细节：防夹触发后，不能直接让流程跳回“开门到位”，而是要回到“开门”状态的起点，重新执行一次完整的开门动作。有工程师图省事，把防夹分支直接指向“开门保持”，结果门还没开到一半，防夹信号消失，流程又跑到关门，门就在中间来回抖动，乘客看了都害怕。门机是带速度曲线控制的，开门动作没走完就反向关门，还容易造成门机过流报警。

另外，光幕连续触发多次（比如一直有人进出），电梯要有“关门超时报警”和“强制关门”机制。这部分逻辑建议放在门控子流程里，用计数变量实现：连续触发N次后，降低关门速度并鸣响提示音，而不是无限期地重新开门，否则高峰期轿厢门永远关不上，整个电梯就瘫痪了。

4.2 消防与急停：为什么必须做成“打断”而不是“分支”

电梯运行中，急停和消防这类信号与正常流程的关系，不是普通的“分支”关系，而是“打断”关系。打个比方：正常流程是一篇正在播放的电影，消防信号不是电影里的一个新剧情，而是断电——整个播放活动都要暂停，换到备用频道。

反映到流程图里，安全事件检查必须放在主循环的最开头，而且状态优先级最高。任何状态下收到急停信号，都要立刻停止运行、保持抱闸，进入故障处理；收到消防联动信号，则要取消全部召唤登记，把电梯直接开到指定层（通常是首层或避难层），开门并停用正常运行功能。如果把消防逻辑画成运行状态下的一个普通分支，那就意味着你必须在待机、开门、关门、运行所有状态里各画一条消防判断线，不仅图面冗余，还容易漏掉某个状态，造成“电梯在关门时收到消防信号却不响应”的致命漏洞。

所以我的建议是：在顶层主流程的LOOP开头，专门放一个“安全事件检查”的预定义处理节点，所有异常统一在这里拦截。图面上看是一个简单的节点，实际上它承担了中断控制器的作用。这样画，图面干净，逻辑上也安全。

4.3 运行途中新来的召唤：同向插入与反向挂起

电梯运行过程中，召唤表不是静止的。3楼往上走，5楼刚有人按了上行，这个新召唤要不要在这次行程里响应？当然要，而且要在5楼停。这就是“同向插入”：新召唤与当前运行方向一致，且位于当前楼层前方，应该立刻把该楼层加入当前行程的停靠列表。

但如果是反向召唤就要挂起。比如电梯刚过3楼，正在上行，此时2楼有人按了上行外呼——这个召唤虽然方向是上行，但楼层在电梯身后。电梯不能回头，只能把这个召唤登记进召唤表，等当前上行方向的全部任务完成后，换向下行时再顺路处理它。

很多流程图只画了“启动前扫描召唤”和“停靠后清召唤”，漏掉了“运行中实时接收新召唤”这条路径。结果就是程序按图写好之后，实测发现电梯经过5楼时明明5楼有人按了上行，电梯却视而不见，因为扫描召唤的代码只在停车后才执行。正确做法是：在主循环的运行状态里，每个扫描周期都刷新召唤表，并持续判断“前方是否有新增的同向召唤”。流程图里的表现，就是在“运行”状态框旁边多画一个实时判断分支，指向“有顺向新召唤则更新停靠列表”。

5. 把流程图翻译成控制代码：一次完整映射

5.1 状态变量、召唤表和流程节点的对应关系

流程图不是交完就完的文档，它最终要变成PLC程序或者嵌入式代码。翻译的第一步，是把图上的概念映射到代码的数据结构上。“状态”对应一个枚举变量，“方向”对应一个方向变量，召唤表用标志数组或位图表示，每个判断菱形对应代码里的if或switch分支。

我习惯用C风格伪代码来做这个映射，结构大致如下：

typedef enum { IDLE, OPENING, DOOR_HOLD, CLOSING, RUNNING, FAULT } ElvState; typedef enum { DIR_NONE = 0, DIR_UP = 1, DIR_DOWN = 2 } ElvDir; uint8_t callCar[16]; // 轿厢内呼 uint8_t callUp[16]; // 各层上行外呼 uint8_t callDown[16]; // 各层下行外呼 ElvState state = IDLE; ElvDir dir = DIR_NONE; int curFloor = 1;

这样一张表的映射图就可以严格对应到流程图的每一个节点：流程图里的“待机”就是枚举值IDLE，“是否有本层召唤”就是callCar[curFloor] || callUp[curFloor] || callDown[curFloor]的判断，“顺向扫描”就是遍历数组找下一个非零位。图和代码一一对应之后，调试时拿着PDF就能定位到具体代码行，沟通成本降一大截。

5.2 主状态机的代码实现

把流程图里的主循环写成代码，核心是switch-case结构。每个case对应一个状态，每个case内部用条件判断完成状态迁移，结构如下：

void main_loop(void) { scan_calls(); // 扫描按钮，更新召唤表 if (safety_fault()) { // 安全事件检查，对应主循环开头节点 state = FAULT; return; } switch (state) { case IDLE: if (has_any_call()) { dir = decide_direction(); // 方向决策菱形 state = CLOSING; // 进入关门 } break; case RUNNING: if (is_next_target(curFloor, dir)) { level_and_stop(); // 平层子流程 clear_current_call(curFloor, dir); // 清除已服务召唤 state = OPENING; } // 实时处理同向新召唤：单周期内刷新停靠列表 refresh_stop_list(dir); break; case DOOR_HOLD: if (hold_timer_expired() || close_btn_pressed()) state = CLOSING; break; case CLOSING: if (door_locked()) state = RUNNING; else if (obstacle_detected()) state = OPENING; // 防夹重新开门 break; default: break; } }

这里有两个在代码里容易出错、但流程图里看得清清楚楚的点。第一，is_next_target必须同时考虑“楼层是否有召唤”和“方向是否顺向”，不能光判断楼层。第二，clear_current_call清除召唤时，如果该楼层既有内呼又有外呼，不能全部清掉，外呼要区分方向清除，否则会出现“电梯已经停过5楼了，5楼的下行外呼还在”这种残留。写代码前先把这些细节在流程图和召唤表设计里定清楚，写的时候就不会犹豫。

5.3 从仿真到实测的验证清单

流程图和代码都完成之后，真正的考验才开始。我建议按下面这份清单逐项验证，每项都能对应到流程图里的某条路径：

• 单层直驶：1楼到3楼，直接响应3楼内呼，中途不停。
• 多层连续同向：3楼内呼、5楼内呼、7楼内呼依次置位，电梯逐层停靠。
• 同向插入：上行途中新增前方同向外呼，必须立刻加入停靠列表。
• 反向挂起：上行途中新增后方外呼，本次不响应，换向后响应。
• 关门防夹：关门过程中触发光幕，门重新完全打开，且没有抖动。
• 超载保护：超载信号有效时，电梯不能关门启动，蜂鸣器报警。
• 急停/消防任意状态触发：在待机、运行、开门、关门各状态下分别测试，电梯行为符合故障子流程定义。
• 断电恢复：运行中断电恢复后，电梯不丢层，自动低速找平层并复位。

这些测试项不是我想出来的，而是每张流程图评审时大家反复问的问题积累下来的。仿真阶段可以用PLC编程软件或嵌入式模拟器跑逻辑，重点看状态迁移是否符合流程图；现场测试阶段则要拿着流程图逐条打勾，任何一条对不上，都要先改图再改代码，而不是直接改代码绕过图中逻辑。图和程序不一致，是后期维护最大的坑。

6. 最后分享几条我在现场攒下的经验

电梯控制流程图这个事，画到后面拼的不是工具熟练度，而是对边界场景的理解。我自己走过不少弯路，印象最深的一条是：画图时千万别一上来就想穷举所有情况，那样只会把自己困在分支的海洋里。正确顺序是先画通一条“一切正常”的主线，从待机到运行到开门再回到待机，确保主线能闭环跑通；然后把异常分支一条一条“挂”上去，每挂一条就问自己一个问题：这个分支在哪个状态可能发生？发生后要去哪个状态？有没有和已有分支冲突？

另一条经验是，流程图是团队沟通的公约数，控制在三级以内就够了。超过三层，说明你把硬件细节或管理流程混进了控制逻辑，该拆出去就拆出去。PDF交付的时候，记得标注版本号和日期，后期程序迭代一次，图就要同步更新一次，否则半年后你看着旧图调试新程序，那种痛苦谁经历谁知道。

还有一个小技巧特别想分享：在子流程分支比较多的页面上，用“分支编号+分支说明表”的方式组织，比每根线上写一长串文字清晰得多。分支说明表里写清楚触发条件、执行动作、下一节点，审图的人不用眯着眼看线条交叉，会议室里少吵一半的架。这些习惯看起来不起眼，但一套成熟的控制系统流程图，靠的就是这些细节才能在交付之后继续被维护、被复用。

本文还有配套的精品资源，点击获取