简介这份PPTX课件系统讲解建筑设备自动化系统BAS体系面向建筑电气、智能楼宇专业学生、设计人员及运维工程师帮助读者从整体架构层面掌握楼宇机电设备的集中监控、远程控制与节能管理方法。内容以中央控制站、区域控制器DDC分站、现场设备和通信网络为主线逐一拆解BAS各层级的硬件组成与软件功能包括实时监控、远程控制、数据分析、报表生成以及最佳启停、焓值控制等节能运行程序同时覆盖温度、湿度传感器风门执行器、电动阀门等现场装置并介绍RS-485、LonWorks、TCP/IP等通信协议的适用场景。课件还结合暖通空调、照明、安防、消防等应用场景简述BAS在节能减排、安全保障及维护简化方面的优势并展望物联网、云计算与大数据带来的智能化趋势。资源仅含1个pptx文件压缩包大小约599KB便于快速阅读与演示。已有70人学习适合作为课堂教学或技术入门的简明参考资料。1. 建筑设备自动化系统BAS到底管什么从“远程开关灯”到“能效闭环”你见过冷机群控投运三个月电费不降反升 2% 的 BAS 项目吗我见过。后来查下来每台冷机都处于“可远程监视”状态群控程序根本没跑起来所有启停依然是值班员手动操作。这是很多人对建筑设备自动化系统BAS最大的误解——以为设备进了网络、电脑上能远程开关就算自动化了。真正的 BAS 体系是把冷热源、空调机组、送排风、给排水、变配电、照明这些机电设备用一套控制逻辑闭环管起来让设备在设定工况下自己运行、自动轮换、按需加减机。这篇笔记讲 BAS 体系怎么拆、点位怎么落、控制逻辑怎么写、现场坑在哪最后落到怎么把整套方法论沉淀成可复用的工程资产。适合刚接手楼宇自控的工程师、机电运维负责人以及正在做 BAS 深化设计的机电设计师。2. 先把BAS体系拆成三层管理层、控制层、现场层各管什么2.1 三层架构是BAS体系的地基为什么必须分层而不是一台工控机管到底BAS 体系最常见的组织方式是三层架构这个结构不是写在规范里的教条而是被十几年现场项目反复验证过的工程经验。管理层是工作站、服务器、Web 网关和各类对外接口控制层是分散在现场的 DDC 控制器和现场总线现场层是温度传感器、压力变送器、水流开关、阀门执行器、变频器这些最末端的设备。管理层负责监视、报警、能效统计和策略下发控制层负责实时闭环控制现场层负责把物理量变成电信号、把控制信号变成阀门的开度。为什么要分成三层而不是一台工控机直接拖几百个点第一是可靠性。控制层某个 DDC 和管理层网络断开时它本地的闭环逻辑必须继续运行——冷机群控不能因为上位机重启就全线停摆。第二是扩展性。楼层增加、设备增加时只需加一台 DDC 挂到总线上管理层点位配置跟着扩展就行不必重新布线。第三是调试便利。每一层都能独立测试现场层单点对线、控制层单独下载程序、管理层单独核对图形画面哪一层出事不会牵连其他层。我在项目里见过不少“伪 BAS”就是把所有信号直接用线拉进机房里的一个集中控制柜。这样做看似省了 DDC 的钱实际上布线量翻倍、故障点翻倍、调试时查一根线要跑遍整栋楼。三层架构看起来设备多了但每个层级的职责边界清晰维护时能按层定位问题。理解这一层后面建点、写逻辑、排故障才有坐标系。2.2 一张机电点表把体系钉死BAS点位建点的字段与顺序BAS 体系的地基不是图纸而是一张机电点表。很多项目翻车不是控制逻辑写不好而是点表稀烂——点位命名随意、量程没写、设备编号对不上图纸。DDC 编程、图形画面、联动逻辑全部从点表出发点表错一个字段后面整条链路跟着错。我一般按这张字段结构建点表每个字段都有明确的工程用途字段作用填写示例点位编号全项目唯一标识程序和数据屏共用CH-01.RETURN_TEMP设备编号对应机电图纸上的设备位号CH-01所属系统冷源/热源/空调/送排风/给排水/变配电冷源点位类型AI/DI/AO/DO决定信号接线方式AI描述中文描述运维人员看得懂1号冷机冷冻水回水温度量程下限/上限对应传感器实际测量范围0~50单位物理量单位℃报警类型越限/故障/状态变化高报警所属DDC点位接入的控制器编号DDC-02联动逻辑该点参与哪些控制段冷机群控建点顺序也有讲究我习惯按“系统分块、设备固定顺序”来走。先按系统把点表分块冷源、空调、送排风、给排水、变配电、照明。然后每台设备固定按“运行状态→手自动状态→故障信号→控制输出→关键模拟量”的顺序建点。这样建的好处是每台设备的点序和日后写控制逻辑的读法一致写程序时不容易漏点。全部建完后再核一遍设备台账核对方式很简单——设备台账上一台一台过每台设备的点都能在点表里对上号对不上的就是漏了。点位命名是另一个容易埋雷的地方。项目里经常看到“温度1”“水温2”这种命名短期自己记得三个月后连写程序的人都未必分得清是供水还是回水。建议统一用“系统-设备-参数”三级命名比如CH-01.RETURN_TEMP一眼看出是 1 号冷机回水温度。命名规则最好在项目第一天就定下来中途改点表编号会牵连程序、画面、报表所有环节改一次伤筋动骨。3. 让BAS体系真正跑起来DDC编程与三组核心逻辑段3.1 从点表到逻辑段DDC程序的工程化写法与PID初值点位建完接下来是把点表变成能跑的程序。DDC 编程大多采用 IEC 61131-3 标准的结构化文本ST语言语法接近 Pascal和 PLC 编程是一个思路。一个完整的控制逻辑段不管多复杂都可以拆成“输入信号采集→中间处理→输出信号执行”三段。输入信号要做抗抖和量程转换中间处理要带手自动切换输出执行要加手动优先。现场最容易被忽略的是输入抗抖。浮球液位开关、压差开关这类干接点信号在设备启停瞬间会产生抖动程序直接读原始信号会导致风机频繁启停。我一般会在每个 DI 输入上加 3 到 5 秒的延时滤波。下面是一段典型的 DI 抗抖与手自动切换逻辑语言是 ST// DI输入抗抖液位开关等干接点信号用3秒滤波 TON_FILT.IN : RAW_DI_INPUT; // 原始干接点信号 TON_FILT.PT : T#3S; // 延时3秒避开启停瞬间的机械抖动 TON_FILT(); FILTERED_DI : TON_FILT.Q; // 手自动切换面板打到自动时程序输出才允许生效 IF PANEL_AUTO_SWITCH THEN DO_OUTPUT : PROGRAM_CMD; // 自动模式程序逻辑控制输出 ELSE DO_OUTPUT : FALSE; // 手动模式程序强制断开输出 END_IF;这段逻辑里TON_FILT是定时器功能块PT是延时时间。3 秒不是拍脑袋定的——现场液位波动和阀门动作引起的信号抖动实测一般在 1 到 2 秒内留 3 秒能滤掉绝大多数误动作又不会让真实信号延迟太久。手自动切换里那句DO_OUTPUT : FALSE很关键它保证面板切到手动时程序不会和现场操作人员“抢”控制权否则调试时容易出安全事故。模拟量控制PID是 BAS 里最需要花时间的部分。空调送风温度、冷机回水温度、压差调节都靠 PID 实现。初次投运时参数不会一次调准但有一个经验初值表可以少走很多弯路后续再根据曲线细调控制对象比例带初值积分时间初值调整方向空调送风温度5~10℃120~300 秒振荡缩短积分时间响应慢加大比例带冷机回水温度3~6℃180~600 秒超调大减小比例带空调机组压差100~300 Pa60~180 秒波动大加滤波调 PID 时记住一个原则先调比例带让系统不振荡再调积分时间消除余差微分尽量少用或不用现场噪声很容易让微分动作变得神经质。我的习惯是每改一次参数等两个完整调节周期观察趋势再动下一个参数一次只改一个。3.2 冷机群控、送排风联动、给排水轮换必须优先写对的逻辑冷机群控是 BAS 体系里最复杂、也最容易被业主拿来验收的逻辑。群控的目的不是远程启停而是根据负荷自动决定开几台冷机、配几台泵、什么时候加减机。加减机判断建议用回水温度加累计运行时间两个条件组合回水温度反映负荷变化累计运行时间保证各台冷机运行时长均衡。只按温度判断冷机在负荷临界点附近会频繁加减机出现“振荡”——行业里管这叫群控抽搐。冷机的启动顺序有硬性约束必须先建立冷却水循环再建立冷冻水循环最后启冷机本体。反转顺序会让冷机高压报警甚至损坏压缩机。下面是一段串行启动逻辑用计数器推进步骤// 冷机启动顺序冷却塔 - 冷却水泵 - 冷冻水泵 - 冷机 CASE STEP OF 0: TOWER_CMD : TRUE; // 第一步开冷却塔风机 TON_STEP.IN : TOWER_CMD; TON_STEP.PT : T#60S; // 等60秒让冷却塔建立通风 TON_STEP(); IF TON_STEP.Q THEN STEP : 1; END_IF; 1: COND_PUMP_CMD : TRUE; // 第二步开冷却水泵 TON_STEP.IN : COND_PUMP_CMD; TON_STEP.PT : T#60S; // 等60秒确认冷却水流量稳定 TON_STEP(); IF TON_STEP.Q THEN STEP : 2; END_IF; 2: CHW_PUMP_CMD : TRUE; // 第三步开冷冻水泵 TON_STEP.IN : CHW_PUMP_CMD; TON_STEP.PT : T#30S; // 30秒后启动冷机 TON_STEP(); IF TON_STEP.Q THEN STEP : 3; END_IF; 3: CHILLER_CMD : TRUE; // 第四步启冷机本体 IF CHILLER_RUN THEN STEP : 99; // 收到运行反馈进入稳态 END_IF; END_CASE;这段逻辑里每个步骤都带定时器目的是避免启动电流叠加。4 台冷机同时启动的瞬间电流冲击可以让变压器低压侧电压跌落触发其他设备欠压保护。串行启动虽然慢了几分钟但电气系统稳定得多。注意每步的延时不是固定值要根据现场设备从启动到建立稳定工况的实际时间调整冷却塔 60 秒通常够用冷机本身从启动到满负荷运行需要更长时间这里只做了启动指令冷机的加载由冷机自带控制器处理。送排风联动的核心不是“超了就开”而是“先排后送”。地下车库的 CO 浓度超标时先启动排风机把污染空气抽出去再启动送风机补充新风形成定向气流。如果先开送风机污染空气会被吹向人行通道。回差控制也要写进去比如 CO 高于 40ppm 启动、低于 25ppm 停止中间留 15ppm 的回差否则风机在 40ppm 附近频繁启停接触器和电机都受不了。给排水系统的轮换逻辑看着简单最容易栽在“频繁启停”上。水泵轮换一般带两个条件一是累计运行时间达到切换周期二是当前泵故障时备泵投入。备泵投入要加保护——如果主机刚停下备机不能立刻启动至少要等 5 到 10 分钟否则污水池液位在上限附近波动时两台泵会以几分钟一次的频率交替启停最终烧掉的是接触器和电机绕组。逻辑上要加“每小时启停次数限制”超过设定次数就只报警不动作让值班人员人工处理。4. BAS调试避坑点位漂移、执行器不动、通讯掉线这样排查调试阶段是 BAS 项目翻车最集中的环节。下面这四条是我在多个现场踩出来的血泪经验每条都按“现象→原因→解决”写清楚排查时可以直接对照操作。4.1 点位量程填错读数全翻倍但通讯一切正常的隐蔽坑现象所有风压传感器读数都是实际值的两倍风机明明在运行画面显示静压 800Pa而现场仪表实测只有 400Pa。通讯、接线、供电全部正常DDC 收到的原始数值也对就是工程单位不对。原因点表里量程填错了。变送器铭牌标注 0~2000Pa输出 4~20mA建点时在点表里把量程上限写成了 4000Pa换算公式直接翻倍。这类问题隐蔽在信号链路从头到尾都是通的程序逻辑也正常唯独“比例尺”错了。解决回到点表逐点核对每个 AI 点的量程和变送器铭牌一致。核对时别只看点表要到现场抄变送器铭牌因为设计图纸上的量程和实际采购设备的量程经常不一致。抄完在点表里更新然后给对应点位通入标准信号源验证 DDC 读数和显示值一致。这个坑最容易在设备分批到货的项目里出现——第一批和第二批变送器量程不同点表照着第一批建的第二批接上后全错。4.2 执行器不动作程序输出正确、万用表却量不出电压现象程序里阀门开度命令 80%执行器纹丝不动。万用表量 DO 模块输出端子有电压但量执行器接线端子没有电压中间隔了一个中间继电器。反复检查程序逻辑和模块配置都没问题换了一个模块口也一样。原因DO 模块的公共端 COM 没有接线。DO 模块输出本质上是开关管控制公共端和输出端的通断模块供电正常不代表 COM 端带电位。如果 COM 端没有接入控制电源回路负载侧永远得不到电压。还有一个常见情况是公共端接的是另一相电源和负载电源不同源控制回路和负载回路之间不闭合。解决先量 DO 模块公共端 COM 对电源 N 端的电压是否正常再看模块说明书确认 COM 端的接线方式。现场排查顺序调整为先公共端、后输出端、再负载端不要一上来就怀疑模块坏了。确认公共端后执行器不动再往下查执行器本身的电源和信号类型匹配问题。这类问题查起来快但很多人会先绕到程序上白费几个小时。4.3 通讯周期性掉线波特率匹配与终端电阻的“玄学”现象Modbus RTU 总线上挂了 12 台 DDC通讯状态总是间歇掉线有时几小时正常有时几分钟掉一次。上位机报“通讯超时”过几秒又自己恢复。现场查线没发现断点屏蔽层也接地了“玄学”得很。原因多数情况下是三个因素叠加——某个节点的波特率和总线其他节点不一致个别设备拨码或配置错了总线末端没接终端电阻以及总线拓扑是星形而不是手拉手。这三个因素在低负载时可能都不表现一旦有节点上报数据或者天气潮湿就开始随机掉包。其中波特率不匹配最隐蔽因为 DDC 之间通讯失败后会重试看起来像是偶发掉线。解决排查顺序固定为“拓扑→波特率→终端电阻”。先把星形分支改成手拉手串行接线一条总线从头到尾不要分支。然后把所有节点波特率统一核对一遍特别是后加的设备和旧设备混用的情况。最后在总线物理两端各接一个 120Ω 终端电阻。接完再看通讯诊断日志掉线记录不再增长基本就稳定了。如果还掉就采用排除法——把节点逐个摘掉每摘一个观察半小时找到那个“肇事”节点单独查。4.4 验收阶段最容易漏掉的三件事程序备份、趋势图、报警台账现象项目调试完成业主签字验收。三个月后业主提出要调整某台空调机组的启停时间翻开资料发现只有图纸和点表DDC 里跑的源程序没有导出当时调试修改了哪些逻辑全凭现场工程师的记忆。最后只能重新读程序反推成本翻了几倍。原因调试期只关注功能“能跑”没关注过程记录。程序文件没有版本管理逻辑改了一版又一版但最终版没有归档趋势图没保存无法证明控制效果稳定调试期间的报警和处置记录没整理后续运维没有参考依据。解决把这三件事当成和“功能调通”同等重要的验收项。程序备份要求每个 DDC 的最终源程序导出并命名带日期版本同时在项目文件夹里放一份带修改记录的清单谁改的、改了什么、为什么改逐条写清楚。趋势图在模拟量稳定运行后采集至少一周留作控制品质的佐证。报警台账从调试第一天就建每次报警的时间、点位、处置方式都记下来最后整理成册交给业主运维。5. 把BAS体系做成可复用的工程资产深化设计文件的组织顺序项目收尾时真正让 BAS 体系产生持续价值的是文件组织方式。我这些年养成一个习惯从跳调第一天就强制自己按固定顺序建文件夹、归档文档。顺序是系统拓扑图及干线平面图→机电点位清单→控制逻辑说明→程序源文件与版本记录→调试记录、趋势报告、报警台账。这个顺序也是后面回溯问题时的查找顺序——先看拓扑确定哪台 DDC 管哪个区域再查点表定位信号再翻逻辑说明看控制算法最后调源程序确认实际代码。这五层文件不是写给别人看的首先是写给自己看的。三个月后业主提出改动你能按这个目录十分钟内定位到需要修改的那个逻辑段半年后设备故障运维能靠这套文件判断是执行器坏了还是控制程序的问题。控制逻辑说明这层很多人不写觉得程序里全是注释了没必要另写文档。实际上程序注释表达的是“怎么写的”逻辑说明表达的是“为什么这么写”比如加减机判断为什么用回水温度加运行时间双条件这类设计意图只存在于人脑里不写出来就是流失。我调过的最顺的一个项目新来的同事靠这套文件第一周就能独立处理报警并定位故障点。而另一个资料混乱的项目调试工程师刚走整改时没人说得清某个阀门的控制逻辑当初是怎么写的最后只能现场重新读程序逐行反推。那一次之后我总结出一个说法BAS 体系能不能算交付完成不看功能演示多漂亮看文件夹结构能不能让一个没参与项目的人平稳接手。所以如果你现在刚开始一个 BAS 项目建议从第一天就按这个五层结构建目录功能调试和文件归档同步推进。项目可能延期设备可能换型但只要文件层级不乱这套体系就能持续长出新的经验。希望帮到你。本文还有配套的精品资源点击获取