電梯系統(tǒng)實時控制軟件建模及PLC實現(xiàn)

本文由南瓜烏梅條貢獻(xiàn) pdf文檔可能在WAP端瀏覽體驗不佳。建議您優(yōu)先選擇TXT，或下載源文件到本機查看。 年 月 控 制 工 程 第卷期 文章編號：【） 電梯系統(tǒng)實時控制軟件建模及實現(xiàn) 馬殷元。姚闖 （蘭州交通大學(xué)機電技術(shù)研究所，甘肅蘭州；蘭州鐵路局蘭州車輛段甘肅蘭州） 摘 要：為降低開發(fā)難度、提高開發(fā)效率，提出把基于層次化狀態(tài)圖的建模技術(shù)和框架技 術(shù)應(yīng)用于實時控制軟件的開發(fā)。以電梯控制為例說明了把此技術(shù)應(yīng)用于實時控制軟 件開發(fā)的過程。首先根據(jù)電梯控制要求和電梯算法建立了系統(tǒng)頂層狀態(tài)圖模型。然后分析了 系統(tǒng)任務(wù)特性，根據(jù)任務(wù)特性提出了把控制任務(wù)分成局部順序任務(wù)、全局實時任務(wù)和異步并 發(fā)任務(wù)的系統(tǒng)分析方法，給出了任務(wù)間通信的方法。提出了用函數(shù)封裝任務(wù)實現(xiàn)狀態(tài)嵌套、用 置位或復(fù)位函數(shù)的“使能輸八端”進(jìn)行任務(wù)調(diào)度的軟件實現(xiàn)方法。最后給出了在西門子 上實現(xiàn)的電梯控制的主要程序和解決定時器失效問題的方法。實現(xiàn)的軟件具有較高的實時】生， 設(shè)計的程序可作為類似控制軟件的框架。 關(guān)鍵詞：實時控制；建模；框架；電梯 中圖分類號： 文獻(xiàn)標(biāo)識碼： ， （ ， ， ，； ， ， ，） ： ， ￥ “ ” 蒯 ? 比 ， ： ； 引 言 的應(yīng)用。軟件框架是已經(jīng)實現(xiàn)過和驗證過的完善與 詳實的一類軟件的模板，可在類似的軟件開發(fā)中重 用，從而提高開發(fā)效率。 本文以電梯控制為研究對象，采用狀態(tài) 機圖建立了控制軟件模型，并且介紹了可以作為 類似系統(tǒng)控制軟件框架的一個實例一電梯控制系統(tǒng) 的實現(xiàn)方法。 開發(fā)實時系統(tǒng)控制軟件是一項困難的任務(wù)。 文獻(xiàn)提到，實時系統(tǒng)設(shè)計的許多形式化方法只能 解決“小玩具”問題，這種說法在今天看來仍然是 基本正確的。很多文獻(xiàn)中介紹了采用不同方法建立 的電梯控制系統(tǒng)模型，如：改進(jìn)的 模型、 改進(jìn)的模型、面向?qū)ο蟮哪Ｐ?。建模的本意?簡化系統(tǒng)，降低系統(tǒng)開發(fā)難度，而不少模型較復(fù)雜 或脫離實際，對系統(tǒng)實現(xiàn)并無幫助。一些模型只是 對系統(tǒng)的行為進(jìn)行了直觀的描述性建模，距離對系 統(tǒng)的控制還有一段距離。文獻(xiàn)中提出了模型驅(qū)動 的軟件開發(fā)方法，但缺乏應(yīng)用實例。 很少有文獻(xiàn)提及框架技術(shù)在軟件開發(fā)中 電梯控制需求描述與電梯算法 簡化的電梯系統(tǒng)（忽略超重、報警、到達(dá)響鈴、 關(guān)門阻擋檢測等信號，不考慮轎廂啟停的速度控 制，每層平層停車位置使用安裝在每個樓層的行程 開關(guān)檢測）的輸入信號包括：轎廂內(nèi)目的樓層請求 按鈕、每層的上升招喚按鈕、每層的下降招喚按 收稿期：）； 收修定稿日期： 作者簡介：馬殷元（），男，甘肅勤人，副教授，博士，主要從事復(fù)雜工業(yè)過程建模、計算機控制系統(tǒng)開發(fā)等方面的教學(xué)與科研工作。 萬方數(shù)據(jù) ? 控制 工程 第卷 鈕、每層的樓層行程開關(guān)、開門按鈕、關(guān)門按鈕、 開門限位開關(guān)、關(guān)門限位開關(guān)；輸出包括：目的按 鈕指示燈、上行招喚按鈕指示燈、下降招喚按鈕指 示燈、轎廂上升（曳引電機啟動正轉(zhuǎn)控制）、轎廂下 降（曳引電機反轉(zhuǎn)控制）、到達(dá)樓層顯示燈、開（門 控電機正轉(zhuǎn)）、關(guān)門（控電機反轉(zhuǎn)）、當(dāng)前電梯狀態(tài) 顯示燈（下行態(tài)、上行態(tài)或空閑態(tài)）。 電梯完成初始化后開始響應(yīng)用戶招喚按鈕和目 的按鈕的輸入，為用戶提供運送服務(wù)。這時，用戶 和電梯的構(gòu)成如下： 如圖，圖所示。 開門按鈕壓下且門控未使能 罡 無呼叩請求 小干當(dāng)前屢請求 復(fù)位空閑使眈 置位下態(tài)使能 置位門控使訂 有大干當(dāng)前屢請求 復(fù)位空閑使能 用戶請求一電梯服務(wù)關(guān)系模式。一個轎廂對多 個用戶的服務(wù)是共享的。為了提高服務(wù)效率，需要 按照一定的策略來調(diào)度轎廂的移動為多個用戶服 務(wù)。常用的調(diào)度算法是電梯調(diào)度算法，簡稱為“電 梯算法”，它的描述如下： 電梯在運行中服務(wù)于同方向上的請求，中途不 改變其運動方向，除非它完成所有同方向上的請 求任務(wù)。 競爭仲裁 量位上態(tài)使能 圖 “空閑態(tài)”狀態(tài)圖 ” ” 電梯控制頂層建模 狀態(tài)圖較之經(jīng)典狀態(tài)機最主要的改進(jìn)之處是組 合狀態(tài)（層次化可嵌套狀態(tài)）的引入，它在的 模型中加入了對層次和并發(fā)的支持，消除了用 模型來描述一些復(fù)雜系統(tǒng)時所發(fā)生的狀態(tài)和轉(zhuǎn)換的 爆炸的町能性。同時，組合狀態(tài)是隱藏內(nèi)部細(xì)節(jié)的 理想機制，把復(fù)雜性隱藏在組合狀態(tài)的內(nèi)部，就可 以在高抽象層次上更加容易的理解和把握系統(tǒng)“。 電梯控制系統(tǒng)模型有多種，系統(tǒng)狀態(tài)的劃分也 有多種。還算合理的一種把系統(tǒng)狀態(tài)劃分為：空閑 態(tài)、上升態(tài)、下降態(tài)。個狀態(tài)問均有狀態(tài)轉(zhuǎn)換， 還有狀態(tài)自身的轉(zhuǎn)換。該模型未考慮電梯調(diào)度算 法。 考慮到電梯算法和簡化狀態(tài)圖，改進(jìn)后的電梯 控制狀態(tài)圖模型，如圖所示。 圖“上升態(tài)”狀態(tài)圖 ” ” 上 電梯控制任務(wù)分析 圖改進(jìn)的電梯控制狀態(tài)圖模型 由圖可見，模型到系統(tǒng)實現(xiàn)還有很大距離。 在此類反應(yīng)式實時多任務(wù)控制系統(tǒng)的開發(fā)中，控制 任務(wù)的分析與設(shè)計對于系統(tǒng)實現(xiàn)至關(guān)重要。本文 把控制任務(wù)歸納分類成全局實時任務(wù)、局部順序任 務(wù)、異步并發(fā)任務(wù)和周期任務(wù)種。本文系統(tǒng)無周 期任務(wù)。下面根據(jù)任務(wù)的特性對其分類。 ）局部順序任務(wù)圖中所示的個狀態(tài)對 應(yīng)于系統(tǒng)的個任務(wù)。本文把這些任務(wù)定義為局部 順序任務(wù)。原因是，控制器只需要按照順序執(zhí)行其 中的一個任務(wù)。 該模型每個狀態(tài)只有一個轉(zhuǎn)換進(jìn)入點和轉(zhuǎn)換退 出點，結(jié)構(gòu)比較清晰。空閑態(tài)向上升態(tài)轉(zhuǎn)換的條件 是：有大于當(dāng)前層的樓層的上升招喚按鈕、下降 招喚按鈕或轎廂內(nèi)目的樓層請求按鈕被按下。上升 態(tài)向空閑態(tài)轉(zhuǎn)換的條件為：完成所有上升任務(wù)一無 大于當(dāng)前層的上升招喚按鈕、下降招喚按鈕或轎廂 內(nèi)目的樓層請求按鈕被按下。 空閑態(tài)和上升態(tài)控制任務(wù)的狀態(tài)圖模型，分別 萬方數(shù)據(jù) 第期 馬殷元等：電梯系統(tǒng)實時控制軟件建模及實現(xiàn) ? ）全局實時任務(wù) 電梯需要對多個用戶提供 后，全局實時任務(wù)一直被執(zhí)行，保證了系統(tǒng)對用戶 請求響應(yīng)的實時性。其他類型的任務(wù)也有實時性要 求。如：轎廂停靠在一層，此時三層的下降招喚按 鈕被壓下，導(dǎo)致電梯進(jìn)入上升態(tài)，轎廂在上升運動 途中位于一層與二層中間時又有人按下了二層的上 行招喚按鈕，電梯應(yīng)該在上升到二層時停止并開 門。上升態(tài)任務(wù)中實時性的關(guān)鍵是轎廂運動過程中 停止的判斷和停止動作的執(zhí)行。圖中上升中狀態(tài) 的任務(wù)就是判斷是否需要停止，一旦滿足條件就執(zhí) 行停止操作。轎廂停止并開門有種情況。第一種 情況是，將在大于當(dāng)前層，并且上升招喚按鈕被按 下的樓層停止并開門；第種是，將在大于當(dāng)前層 并且轎廂內(nèi)目的樓層請求按鈕，被按下的層停止并 開門；第種是，將在大于當(dāng)前層，并且下降招喚 按鈕被按下并且“下降招喚按鈕”被按下的樓層 是所有召喚中最高的樓層停止并開門。在基于 的控制器實現(xiàn)中，一般來說最大延遲時間為 程序循環(huán)掃描時間的倍。這與的速度和程序 的規(guī)模有關(guān)，同時如果合理調(diào)度任務(wù)，可以減少程 序掃描時間。 運送服務(wù)，用戶通過各層或轎廂內(nèi)的按鈕輸入服務(wù) 請求，電梯控制根據(jù)電梯算法，順序服務(wù)用戶。盡 管運送服務(wù)不是實時的，但要求對用戶輸入的確認(rèn) 響應(yīng)是實時的。當(dāng)用戶按下按鈕時，控制系統(tǒng)立即 點亮與上行招喚、下行招喚、目的按鈕對應(yīng)的指示 燈，實時響應(yīng)確認(rèn)用戶請求，并注冊這個請求。此 后，控制系統(tǒng)按照用戶請求移動轎廂，到達(dá)有請求 的樓層時停止移動轎廂，自動開門，完成對用戶的 服務(wù)，并熄滅相應(yīng)的指示燈，注銷請求。這種呼叫 顯示及用戶請求注冊功能構(gòu)成一個全局實時任務(wù)， 在電梯正常工作狀態(tài)中該任務(wù)都需要實時執(zhí)行。 電梯轎廂在運動時需實時監(jiān)測、顯示當(dāng)前到達(dá) 樓層，判斷是否有注冊的請求，以便在有請求的樓 層停止。到達(dá)樓層是通過安裝在各層的行程開關(guān)檢 測的，為了顯示樓層數(shù)碼和判斷是否到達(dá)目標(biāo)樓 層，當(dāng)前樓層用數(shù)字量表示。程序中通過編程把行 程開關(guān)輸出了量變換成相應(yīng)的樓層的數(shù)字并顯示。 這個功能構(gòu)成“當(dāng)前層更新”全局實時任務(wù)。 ）異步并發(fā)任務(wù) 電梯在上升態(tài)、下降態(tài)、 空閑態(tài)控制任務(wù)的執(zhí)行中均允許有門的操作，門的 操作也可與呼叫顯示及用戶請求注冊任務(wù)同時發(fā) 生?？梢园验T的操作分析出來在門控制中實現(xiàn)。門 控制任務(wù)的狀態(tài)圖，如圖所示。 控制任務(wù)間的通信與任務(wù)調(diào)度 任務(wù)：呼叫顯示及用戶請求注冊完成請求的響 應(yīng)和請求信息的注冊，對用戶的服務(wù)在任務(wù)上升態(tài)、 下降態(tài)中完成。任務(wù)：呼叫顯示及用戶請求注冊模 塊與上升態(tài)下降態(tài)模塊構(gòu)成請求信息的生產(chǎn)者一消 費者模式。任務(wù)之間的通信可使用共享內(nèi)存的方法 實現(xiàn)。呼叫顯示及用戶請求注冊任務(wù)置位相應(yīng)變量， 上升態(tài)、下降態(tài)查詢相應(yīng)變量，完成服務(wù)后復(fù)位變 關(guān) 下 量。 由于已經(jīng)根據(jù)其特性對任務(wù)進(jìn)行了分類，任務(wù) 的調(diào)度就比較簡單了。本文采用最自然的順 序調(diào)度的任務(wù)調(diào)度策略。局部順序控制任務(wù)相互沒 有重疊，同時只有一個在運行。全局實時任務(wù)一直 運行。上升態(tài)、下降態(tài)、空閑態(tài)任務(wù)中通過置位： 門控制使能變量來啟動門控制任務(wù)。門控制完成后 復(fù)位門控制使能變量，以便于需要任務(wù)同步的任務(wù) 得到門當(dāng)前的狀態(tài)。要注意的是異步并發(fā)任務(wù)：門 控制的使能（置位控制變量，使得該任務(wù)被執(zhí)行） 圖 “門控制”狀態(tài)圖 控制可能導(dǎo)致任務(wù)重入（任務(wù)執(zhí)行完成前有被從頭 重復(fù)執(zhí)行）問題，在本系統(tǒng)中不允許該任務(wù)重入， 所以在任務(wù)使能前要滿足的條件是該任務(wù)沒有被使 能，參見圖。 ” ” 門控制任務(wù)執(zhí)行時間可能跨躍個局部順序任 務(wù)。如：用戶在電梯處于空閑態(tài)時按下開門按鈕， 又按下一個轎廂內(nèi)目的樓層請求按鈕使電梯進(jìn)入上 升態(tài)，而門的操作任務(wù)還沒有完成。由以上點， 把任務(wù)執(zhí)行可能與多個任務(wù)重疊和并發(fā)操作的“門 控制”任務(wù)定義為異步并發(fā)任務(wù)。 ）任務(wù)的實時性在電梯進(jìn)入正常工作狀態(tài) 控制系統(tǒng)的實現(xiàn) ）狀態(tài)嵌套的實現(xiàn) 圖只是一個頂層的狀 態(tài)圖模型，在原點復(fù)歸、上升態(tài)、下降態(tài)、空閑態(tài) 中又包含了各自的底層的轉(zhuǎn)態(tài)一轉(zhuǎn)換邏輯。也就是 萬方數(shù)據(jù) 控制工程 第卷 說，它們嵌套了子狀態(tài)。很多廠家提供了順 序功能圖（）語言編程環(huán)境，利用順序功能圖語 言可以實現(xiàn)平面的狀態(tài)圖模型。但語言編程不 能直接實現(xiàn)狀態(tài)嵌套使用起來不方便。但與 狀態(tài)圖基本思想是一致的，就是“把大的任務(wù)分成 小的（階段）步一即狀態(tài)，每個階段（步）的程序只考 慮處理與該步有關(guān)的輸入，通過控制小的（階段） 步程序的執(zhí)行順序，實現(xiàn)狀態(tài)轉(zhuǎn)換，與當(dāng)前小的 （階段）步無關(guān)的程序和輸入被忽略”。該方法的關(guān) 鍵是，忽略了無關(guān)的輸入和程序，把大的控制任務(wù) 簡化成很多小的控制任務(wù)一狀態(tài)。受此啟發(fā)，可以 把小的控制任務(wù)即狀態(tài)封裝在子程序（或函數(shù)） 中，通過控制子程序“使能輸入端”（參見圖中 的語句）控制子程序是否被執(zhí)行，就可以方便的實 現(xiàn)任務(wù)的調(diào)度，控制調(diào)度的順序也就實現(xiàn)了任務(wù)的 切換即狀態(tài)的轉(zhuǎn)換。同時子程序是可以嵌套的，狀 態(tài)嵌套問題隨之解決。 ）控制軟件框架用西門子的編 程環(huán)境 實現(xiàn)的主程序（），如圖所示。 轉(zhuǎn)移，需要在子程序外部置位子程序中的第一個狀 態(tài)的控制位變量。 子程序中定時器問題的解決 在用“子程序封裝任務(wù)”實現(xiàn)狀態(tài)嵌套的實 現(xiàn)中發(fā)現(xiàn)，子程序中的定期器在第一次啟動 運行時可以正常工作，在此后，定時器不能正常啟 動，以致程序在定時器處卡殼。 幫助 中的使用說明中要求： 啟動定時器需要在其輸入端（）加一個正向邊 沿，并且信號的變化是必須的。造成子程序中定時 器不能啟動的原因是子程序不是連續(xù)掃描的，而是 根據(jù)狀態(tài)轉(zhuǎn)換的需要調(diào)度執(zhí)行的。 這樣，定時器的輸入端（）在使能（置）前可 能無法得到復(fù)位（置）信號，滿足不了“邊沿觸 發(fā)”的條件。因此，可把子程序中定時器的語句放 到子程序中所有語句的最前面，這樣在子程序進(jìn)入 時。先掃描定時器語句，定時器的輸入端（）可得 到復(fù)位信號，此后的掃描中定時器的輸入端再使能 啟動，就滿足了定時器“邊沿觸發(fā)”的啟動條件。 結(jié)語 本系統(tǒng)設(shè)計在一個層曳引型模型電梯上實現(xiàn) 并驗證，軟件運行穩(wěn)定可靠。設(shè)計中使用控制子程 序“使能位”實現(xiàn)了系統(tǒng)任務(wù)調(diào)度，在掃描程 序時只需掃描執(zhí)行部分子程序，正常工作時 程序掃描條數(shù)為整個程序的，系統(tǒng)效率較不 使用任務(wù)調(diào)度的設(shè)計有較大提高。另外，本文介紹 的系統(tǒng)開發(fā)方法具有模型和實現(xiàn)對應(yīng)關(guān)系直接明 了、實現(xiàn)的系統(tǒng)結(jié)構(gòu)化程度高的優(yōu)點，提出的任務(wù) 分類方法對實時系統(tǒng)軟件設(shè)計具有普遍的指導(dǎo)意 義。給出的軟件（圖）還可以作為類似控制系統(tǒng)軟 件的模板。這兩點的應(yīng)用町以提高開發(fā)效率。 圖電梯控制主程序 參考文獻(xiàn)（）： 桂先洲，戴金海任務(wù)圖模，！中實時任務(wù)設(shè)計軟件學(xué)報 圖中的初始化在初始化程序塊 中實現(xiàn)。在原點復(fù)歸任務(wù)程序的最后的語句中，通 過復(fù)位原點復(fù)歸使能、置位呼叫顯示使能（見圖） 語句，使呼叫顯示及層更新子程序