簡介西門子杯六部十層電梯群控一等獎參考程序面向自動化、電氣工程及競賽選手展示如何基于西門子PLC平臺實(shí)現(xiàn)六臺電梯與十個樓層的智能調(diào)度。該例程融合預(yù)測性群控算法、精確電梯控制邏輯、傳感器通信及多重安全保護(hù)機(jī)制能夠有效降低乘客等待時間并優(yōu)化能耗可幫助學(xué)習(xí)者掌握高層建筑電梯群控系統(tǒng)的工程化設(shè)計方法。資源共70個文件涵蓋xml、del、cfs、tvx、tvd、tis等類型分別對應(yīng)項(xiàng)目配置文件、PLC程序模塊、HMI畫面組態(tài)及通信數(shù)據(jù)定義等目錄結(jié)構(gòu)清晰壓縮包僅8.52MB便于下載后快速檢索。目前已有10237人學(xué)習(xí)是備賽西門子杯或研究電梯群控的高價值案例。通過源碼與組態(tài)文件讀者可還原一等獎方案的完整框架理解從呼叫分配到梯群協(xié)調(diào)的調(diào)度流程并參考其中實(shí)時性保障與穩(wěn)定性處理思路。 提到“西門子杯”六部十層電梯群控這道題參加過的人都知道它不像單部電梯那樣把程序?qū)懲昃湍芘苷嬲碾y點(diǎn)全在那個“群”字上。六部電梯同時服務(wù)十層樓乘客隨機(jī)在任意樓層呼梯如果每臺電梯各干各的就會出現(xiàn)多臺電梯同時搶同一個召喚、空跑浪費(fèi)、樓層扎堆排隊(duì)等問題。這份一等獎例程的參考程序解決的就是怎樣用一套可復(fù)現(xiàn)的調(diào)度策略讓六部梯在動態(tài)客流下盡量做到“響應(yīng)快、能耗低、不沖突”。如果你正在備賽或者工作中接到多梯聯(lián)控、樓宇交通優(yōu)化的項(xiàng)目這份程序在算法選型和程序結(jié)構(gòu)上都有可以直接參考借鑒的東西。1. 賽題拆解六部十層群控到底在考什么1.1 控制對象與信號體系電梯單機(jī)控制大家比較熟悉每部梯有上/下行按鈕、樓層感應(yīng)、開關(guān)門、平層信號外加轎內(nèi)選層按鈕。但群控題會把信號量放大六倍而且六部梯之間不是獨(dú)立運(yùn)行的。賽題通常把六部電梯放在同一棟樓里每層有兩個方向召喚按鈕一樓只有上行十樓只有下行。乘客在廳外呼梯后系統(tǒng)要決定派哪部梯去響應(yīng)。這里有三個核心信號層次轎廂信號每部梯的當(dāng)前位置、運(yùn)行方向、開關(guān)門狀態(tài)、轎廂內(nèi)選層目標(biāo)。廳外召喚信號每層上下行呼梯按鈕六部梯共用同一套外呼信號。調(diào)度決策信號程序內(nèi)部計算的“派梯結(jié)果”決定哪部梯響應(yīng)哪個外呼。這個IO規(guī)模用S7-1200做真實(shí)硬件會非常龐大電氣接線也復(fù)雜。競賽場景下通常用仿真模型或者觸摸屏組態(tài)來模擬六部電梯PLC程序內(nèi)部通過數(shù)據(jù)塊維護(hù)每部梯的虛擬狀態(tài)。這反而對程序架構(gòu)提出了更高要求如果直接把信號堆在OB1里梯形圖會亂到?jīng)]法維護(hù)。1.2 評分維度和避坑重點(diǎn)比賽評分不外乎幾個維度能否正常完成基本運(yùn)載功能、能否正確響應(yīng)所有外呼、多梯之間是否存在沖突和空跑、長時間運(yùn)行是否穩(wěn)定不卡死。備賽時很多人會忽略一點(diǎn)不要一上來就追求復(fù)雜算法。評委先看的是“正確性”調(diào)度算法再漂亮如果出現(xiàn)了某層召喚無人響應(yīng)的死鎖直接扣大分。我之前見過一個隊(duì)伍用了很炫的動態(tài)規(guī)劃模型但基礎(chǔ)外呼掃描邏輯寫漏了某個角落的召喚信號在特殊時序下丟失決賽現(xiàn)場反復(fù)出問題非常可惜。一等獎例程的高明之處在于先保證信號采集和響應(yīng)完整性再在空閑梯分配、順向截梯這些環(huán)節(jié)上做優(yōu)化。2. 群控算法的核心思路2.1 常見調(diào)度策略橫向?qū)Ρ攘渴畬拥娜嚎爻Ｒ娝悸酚腥N策略實(shí)現(xiàn)方式優(yōu)點(diǎn)缺點(diǎn)就近派梯計算每部梯到召喚層的距離最近者響應(yīng)邏輯簡單容易實(shí)現(xiàn)不考慮運(yùn)行方向和順路情況高峰期容易忙閑不均固定分區(qū)把樓層分成若干區(qū)段每部梯負(fù)責(zé)一片調(diào)度清晰不混亂客流不均時部分梯閑置部分梯超載動態(tài)分配順向截車綜合距離、方向、順路停靠優(yōu)先派“順路”梯效率高能耗低邏輯復(fù)雜度高邊界情況多一等獎例程里通常用的是第三種作為主框架再疊加一些邊界條件處理。這里我想多說一句很多選手會糾結(jié)要不要上“模糊控制”“遺傳算法”這類高級方法我的建議是競賽階段做經(jīng)典調(diào)度策略就足夠了關(guān)鍵是穩(wěn)定性可復(fù)現(xiàn)答辯時能把邏輯講清楚。2.2 分區(qū)和優(yōu)先級的實(shí)現(xiàn)細(xì)節(jié)具體實(shí)現(xiàn)里六部梯不能一視同仁。我見過做得比較好的參考程序采用“動態(tài)分區(qū)高峰補(bǔ)償”常態(tài)下1、2號梯負(fù)責(zé)低區(qū)1-4層3、4號梯負(fù)責(zé)中區(qū)5-7層5、6號梯負(fù)責(zé)高區(qū)8-10層。當(dāng)某一區(qū)域召喚等待時間超過閾值時相鄰區(qū)域的空閑梯自動支援。這個閾值怎么定我在調(diào)試中一般取20到30秒稍微偏大一點(diǎn)避免支援梯剛出發(fā)目標(biāo)區(qū)又有新召喚造成“震蕩”。程序里要專門設(shè)計一個“支援標(biāo)志”和“回區(qū)標(biāo)志”的狀態(tài)機(jī)否則支援梯完成任務(wù)后會不知道該回自己的區(qū)域還是繼續(xù)停在當(dāng)前區(qū)域。還有一個細(xì)節(jié)是優(yōu)先級排序。外呼按鈕的響應(yīng)優(yōu)先級不是固定的要動態(tài)計算一個“評分”我常用的評分模型是召喚等待時間權(quán)重占40%等待越久權(quán)重越高。電梯到達(dá)召喚層的預(yù)計時間權(quán)重占30%。電梯當(dāng)前載客量和剩余目標(biāo)數(shù)權(quán)重占20%。電梯是否順路占10%。最后取綜合評分最低的電梯響應(yīng)。這種多因子評分模型最大的好處是參數(shù)可調(diào)主辦方如果臨時改客流模型調(diào)整權(quán)重就能應(yīng)對。2.3 為什么不能只做“最近派梯”很多初學(xué)者寫群控第一反應(yīng)是求每部梯到召喚層的距離。我剛開始也是這么干的后來發(fā)現(xiàn)實(shí)際運(yùn)行中會出現(xiàn)兩個典型問題第一某部梯剛好在附近但方向相反派它去會先跑到遠(yuǎn)端掉頭反而比遠(yuǎn)處順路的梯慢。比如1號梯在5樓上行2號梯在2樓下行這時8樓有人按上行1號梯雖然近但方向完全反了讓它去等于讓乘客白等。第二所有召喚都派給最近的梯會導(dǎo)致它忙死其余五部梯閑死整體效率極低。這在群控里叫“車隊(duì)效應(yīng)”現(xiàn)實(shí)中高峰期的電梯經(jīng)常出現(xiàn)好幾部同時到一樓就是這種邏輯造成的。所以要引入方向權(quán)重順路方向的距離權(quán)重要比逆路方向小很多甚至逆路方向在高峰期直接不參與分配。這里用一句話總結(jié)我的實(shí)操感悟群控調(diào)度不是選“最近”的梯而是選“最合適”的梯。3. 參考程序的結(jié)構(gòu)解析3.1 硬件組態(tài)與通信方式這份例程的硬件主體是西門子S7系列PLC開發(fā)環(huán)境用TIA Portal博途。如果是S7-1200建議選用固件版本4.0以上的CPU支持更完整的數(shù)據(jù)塊和數(shù)組操作做六部梯的數(shù)據(jù)管理更方便。六部電梯如果用真實(shí)設(shè)備IO量太大且現(xiàn)場布線成本高競賽通常會采用兩類替代方式觸摸屏模擬在西門子精智面板或WinCC上畫六部電梯的動畫模型通過內(nèi)部變量與PLC交互。PLCSIM仿真純粹在軟件層面仿真適合調(diào)試程序邏輯但對通信組態(tài)驗(yàn)證不足。通信方式上常見的是PROFINET組態(tài)六部電梯模型作為智能從站接入PLC主站。這里有個容易踩坑的地方S7-1200做PROFINET IO控制器時設(shè)備名稱必須和組態(tài)完全一致大小寫和字符都不能錯否則搜不到設(shè)備。我當(dāng)時第一次組態(tài)時就因?yàn)樵O(shè)備名多打了一個空格排查了半個多小時。3.2 程序塊的劃分方式一等獎程序的典型結(jié)構(gòu)是OB1主循環(huán)負(fù)責(zé)調(diào)用各功能塊類似人的大腦按周期掃描身體各器官。FC函數(shù)負(fù)責(zé)外呼信號采集、轎廂信號采集、派梯決策、電梯運(yùn)行控制、開關(guān)門控制、指示燈輸出等無數(shù)據(jù)記憶適合做純計算。FB函數(shù)塊六部電梯作為六組背景數(shù)據(jù)塊調(diào)用同一個FB這是最核心的復(fù)用思想。DB數(shù)據(jù)塊存放所有電梯的狀態(tài)數(shù)據(jù)、召喚隊(duì)列、派梯結(jié)果。我特別想強(qiáng)調(diào)FB復(fù)用這一點(diǎn)。六部梯不要再寫六套邏輯用同一個FB加六個背景DB程序量和調(diào)試工作量會大幅下降。修改邏輯時只改FB六個實(shí)例同時生效這在比賽時間緊張時是保命的設(shè)計。具體到FB內(nèi)部建議把每部電梯的狀態(tài)全部封裝在一個UDT用戶自定義數(shù)據(jù)類型里包含當(dāng)前位置、目標(biāo)樓層、方向、運(yùn)行狀態(tài)、開關(guān)門計時等字段。這樣派梯程序只需要遍歷六組結(jié)構(gòu)體代碼非常清爽。3.3 狀態(tài)機(jī)設(shè)計電梯控制本質(zhì)是狀態(tài)機(jī)空閑、上行、下行、開門、關(guān)門、故障、檢修。每部電梯在程序中維護(hù)一個狀態(tài)字調(diào)度程序根據(jù)狀態(tài)字決定是否派梯。狀態(tài)遷移有幾個關(guān)鍵點(diǎn)空閑-上行/下行收到派梯指令后。運(yùn)行-開門到達(dá)目標(biāo)樓層并平層后。開門-關(guān)門開門時間到且門區(qū)無阻擋部分程序會加“超時強(qiáng)制關(guān)門”邏輯。關(guān)門-運(yùn)行門鎖閉合后。這塊最容易出問題的是“門區(qū)信號”。真實(shí)電梯的門區(qū)信號來自井道傳感器仿真環(huán)境下我們要在程序里模擬。建議在FB里用一個專門的字節(jié)表示門區(qū)狀態(tài)0表示未到門區(qū)1表示在門區(qū)避免用BOOL散點(diǎn)導(dǎo)致邏輯混亂。4. 實(shí)操過程與調(diào)試方法4.1 先單梯后群控的分步調(diào)試我調(diào)試這套程序時踩過一個很大的坑一上來就把六部梯全部聯(lián)調(diào)結(jié)果出了問題根本不知道是算法錯還是某一部梯的邏輯錯。后來我改成兩步走第一步把群控調(diào)度暫時屏蔽手動給每部梯下發(fā)目標(biāo)樓層驗(yàn)證單梯的“運(yùn)行-平層-開門-關(guān)門”狀態(tài)機(jī)是否正常。這個過程可以用變量監(jiān)控表手動修改目標(biāo)樓層和當(dāng)前位置觀察狀態(tài)遷移是否符合預(yù)期。第二步單梯全部通過后再開放群控調(diào)度先用2部梯測然后是4部最后才是6部。每增加一部梯都會有新問題冒出來特別是多梯對同一召喚響應(yīng)的互斥邏輯只有梯數(shù)多了才暴露。注意比賽現(xiàn)場調(diào)試時間有限一定要把“單梯自檢”程序做成一個獨(dú)立測試模式。這樣評委在演示時如果單梯出問題也能快速定位是機(jī)械模擬問題還是程序問題。4.2 借助變量監(jiān)控表和交叉引用TIA Portal里有一個非常好用的功能是變量監(jiān)控表可以把所有關(guān)鍵變量的當(dāng)前值拉到同一張表里實(shí)時看。調(diào)試群控程序時我建議監(jiān)控以下幾組變量六部梯的當(dāng)前位置和方向確認(rèn)是否有多梯扎堆。所有外呼信號的狀態(tài)確認(rèn)沒有召喚被漏掉。派梯決策的評分結(jié)果理解為什么某部梯被選中。另外交叉引用功能也很實(shí)用可以查某個信號被哪些程序塊讀寫。我之前排查一個外呼燈不亮的問題就是用交叉引用發(fā)現(xiàn)信號在某兩個FC里重復(fù)寫后一個覆蓋了前一個的結(jié)果。如果你用的是S7-1500配合仿真還可以用PLCSIM的序列功能模擬外呼信號按時間出現(xiàn)把比賽場景提前跑一遍。這個功能很多人沒用過其實(shí)特別適合驗(yàn)證算法在長時間運(yùn)行下的穩(wěn)定性。4.3 提高魯棒性的邊界處理邊界條件是最能拉開差距的地方。十層樓里一樓只有上行召喚十樓只有下行召喚這是一眼能看出來的邊界。但還有幾個隱蔽的邊界所有電梯同時處于故障或檢修狀態(tài)時外呼按鈕必須保持閃爍提示系統(tǒng)不能假死。某部梯在某層反復(fù)開關(guān)門超時會觸發(fā)故障報警此時要把該梯從調(diào)度池里摘除剩余五部梯接管。高峰時多個外呼同時到達(dá)評分相同的情況下要有一個穩(wěn)定的優(yōu)先級仲裁規(guī)則我一般讓編號小的電梯優(yōu)先。這些邏輯不會占到很多代碼量但缺一個都可能在演示時翻車。一等獎例程和普通例程的差別往往就在這些細(xì)節(jié)上。5. 常見問題與排查技巧實(shí)錄5.1 多梯同時響應(yīng)同一召喚這個是最經(jīng)典的問題。現(xiàn)象是某個外呼亮起后顯示有兩部甚至三部電梯都開始往這個樓層跑造成浪費(fèi)。排查思路先看外呼信號是邊沿觸發(fā)還是電平觸發(fā)。正確的邏輯應(yīng)該是“派梯成功”后立即把該召喚標(biāo)記為“已被處理”其他電梯的掃描邏輯必須跳過該召喚。如果外呼信號用的是電平觸發(fā)一定要加上升沿檢測并且要設(shè)計一個“分配鎖定”位。我自己的經(jīng)驗(yàn)是派梯決策最好集中在一個FC里順序執(zhí)行不要分散到每個電梯的FB里各自判斷。集中式分配天然能避免多梯搶單分布式分配雖然看起來響應(yīng)快但互斥處理會很麻煩。5.2 電梯在門區(qū)反復(fù)開關(guān)門現(xiàn)象是電梯到站后開門沒等關(guān)門時間到又立刻開門或者門關(guān)不上。真實(shí)場景可能是有東西擋住光幕仿真場景下多半是門區(qū)信號和開關(guān)門計時邏輯沒配合好。排查路徑第一步看門區(qū)信號是否一直保持有效第二步看開門到位信號是否復(fù)位第三步看關(guān)門計時器是否被某個信號反復(fù)清零。我遇到過一次很隱晦的情況是檢修信號被錯誤地置位了導(dǎo)致電梯認(rèn)為門區(qū)一直有異常。處理方式建議在FB里增加一個“最小關(guān)門時間”邏輯即使開門條件再次滿足也必須等關(guān)門動作持續(xù)2-3秒后才能重新開門。這樣可以避免“沖門”現(xiàn)象也讓運(yùn)行更加平穩(wěn)。5.3 高層召喚長時間無響應(yīng)如果程序用了固定分區(qū)策略很容易出現(xiàn)頂層或底層的召喚無人響應(yīng)因?yàn)榉謪^(qū)后某些梯只在特定區(qū)域跑跨區(qū)召喚沒有歸屬。這個問題的根治方案是“分區(qū)但可越界”。每個區(qū)域的“責(zé)任梯”默認(rèn)響應(yīng)本區(qū)召喚但如果本區(qū)所有梯都在忙系統(tǒng)要允許相鄰區(qū)域的空閑梯接管。具體實(shí)現(xiàn)時在派梯FC里加一個“區(qū)域超時檢查”當(dāng)召喚等待超過設(shè)定時間就把該召喚的評分權(quán)重提高強(qiáng)制其他區(qū)域評分較低的電梯參與競爭。注意跨區(qū)派梯要考慮電梯完成任務(wù)后是否回原區(qū)域。如果不加“回區(qū)”邏輯時間長了所有電梯都會跑到客流密集的區(qū)域其他區(qū)域徹底癱瘓。這就是我前面提到的“支援標(biāo)志”和“回區(qū)標(biāo)志”狀態(tài)機(jī)的用途。5.4 通信偶發(fā)中斷和數(shù)據(jù)不同步使用PROFINET時偶發(fā)掉站會讓整個系統(tǒng)處于半癱瘓狀態(tài)。最常見的原因是網(wǎng)絡(luò)線纜質(zhì)量差或者終端電阻設(shè)置錯誤其次是交換機(jī)的端口配置了節(jié)能模式長時間低流量后會把端口休眠。調(diào)試技巧是在PLC程序里組態(tài)“看門狗”時間把設(shè)備名稱和IP固定下來不要在程序中動態(tài)修改IP。如果是PLCSIM純仿真環(huán)境遇到的“掉線”多半是仿真器的通信周期和程序掃描周期不匹配適當(dāng)拉長仿真器的更新周期就能解決。寫在最后做這份六部十層電梯群控參考程序我最深的體會是群控算法的上限很大程度上取決于代碼結(jié)構(gòu)的清晰度而不是哪一個技巧有多花哨。程序里每個信號都能被追蹤到每個狀態(tài)都有明確的遷移條件這樣的程序哪怕算法樸素調(diào)試起來也事半功倍。最后再分享一個實(shí)用小技巧比賽現(xiàn)場如果時間緊張優(yōu)先保證“首目的地正確”和“召喚無丟失”然后在答辯前把空閑梯分配策略講清楚這個邏輯完整流暢比把堆砌的優(yōu)化算法講得磕磕絆絆更能打動評委。調(diào)度系統(tǒng)的核心價值是“穩(wěn)定服務(wù)于人”不是炫技術(shù)這一點(diǎn)在調(diào)試中反復(fù)提醒自己很有用。本文還有配套的精品資源點(diǎn)擊獲取