專利名稱：電梯目的樓層的呼叫控制的制作方法
技術領域：
本發明涉及電梯目的樓層的呼叫控制。
在較大的建筑物中，通常安裝一組二到八部電梯，為此，就需選擇從一個樓層新輸入之轎箱呼叫最為適宜出現的電梯，即所謂樓層呼叫。通常這就是具有到達該樓層的最短行進路徑的電梯。但是，在該行進路徑中，如果這組電梯中的每一部都不得不預先為其它樓層呼叫提供服務，然后乘客才能在該層登梯，則僅當他們按下對應的轎箱按鈕，才知道其目的地。因此，由于總是存在關于要到達的目的地的不確定性，向電梯分派樓層呼叫就成問題。
因此，在電梯工業中，通過使用基于神經網絡或者遺傳算法的學習方法，可以觀測大量的試驗，以便熟練地“猜測”乘客的可能目的樓層。但是，這些方法的效果非常有限，因為僅只是粗糙的運行圖，比如早晨的上樓高峰，可以各種可能性去認知它。但仍然不清楚哪一個乘客想在哪一個時候登梯，例如，他或者她在星期一早上大約10點37分在高樓層辦公室的10層呼叫電梯。
解決控制問題的另一個出發點是所謂目的樓層呼叫控制。利用目的樓層呼叫控制，乘客在登梯或者登電梯轎箱之前，比如通過類似于電話的鍵盤，即所謂終端輸入他們想要的目的樓層。根據終端位置，目的樓層控制就知道了登梯的樓層。在輸入目的樓層之后，控制分配算法就弄清了電梯組中能夠最快最舒適地將乘客運送到他或她的目的的電梯。終端指示電梯組中的該部電梯，乘客可以按照他或她自己的步幅進入相應標記的電梯。如果電梯為了乘客登梯而停靠，然后比如通過門框上的顯示裝置來確定乘客的目的地。在轎箱中不再出現任何用于輸入目的地的按鈕。按照這種方式，通過利用目的樓層呼叫控制，可以將具有確定目的地的乘客分組，從而增加電梯系統的運送能力。
另外，從EP 0 699 617 A1得知這種目的呼叫控制的示例，其用于識別每位乘客的位置。對于每個被識別的乘客，可以通過訪問數據存儲器，按照最優運送可能性的決定考慮關于登梯位置和下梯位置的附加數據、乘客空間需求和可能的附加服務需求。
這種以及其它常規目的樓層呼叫控制都以基于分配規律的直接逼近算法為基礎。按照每個特定實例的要求設計該分配算法并編程。在運行請求的情況下，即目的樓層呼叫的情況下，將與人和設備有關的、并通過適當傳感系統檢測的數據傳遞給分配算法，運行算法，用以確定運行次序。
如果在運行次序的執行期間出現新的附加運行請求，則修改已經計算的運行次序，以達到所述效果。但是，在這種情況下，僅可以進行簡單的修改，其結果可以是僅僅執行與目的樓層呼叫有關并針對變化的前提不再是最優運行次序的修改運行次序。這會導致乘客較長的等待時間和/或運送時間。此外，在固定程序分配算法中，并不總是符合邏輯地和以不間斷的方式來表達單獨控制選項的相互關系，即所謂的服務需求。此外，用于計算運行次序，以特定需求形式創建的控制軟件錯綜復雜。具體地講，其缺點在于，以前創建的分配算法要付出相當的代價才能適用于不同特定客戶的控制需求。實際上，為了適應變化的服務要求，不得不在每種情況下預備新的特定電梯分配算法并整體實現。
為了滿足該目的，本發明提出了一種具有權利要求1給定特征的運行次序規劃方法，其特征在于，它能夠提供一種用來確定最優運行次序的基于環境的搜索程序。權利要求6限定的目的樓層控制給出關于裝置的解決方案，其使用所謂規劃系統提出了一種運送量的結構。
因此，根據本發明，提供一種本質上已為人們所了解的規劃系統，以取代以前采用的特定用途的固定程序控制算法。規劃程序根據基于環境的搜索程序來工作，并確定特定環境的最優運行次序，它與目的樓層呼叫和從電梯設備的瞬時操作狀態開始的行動以及電梯設備要產生的目的狀態有關。
根據以環境為基礎的搜索程序的應用實際上提供了一些優點在瞬時環境的任何有關變化情況下，例如，關于新的運行請求的注冊，中斷執行運行次序等，在執行的每個運行次序步驟之后的極端情況下，確定全新的實際運行次序，然后電梯驅動裝置執行這一次序。
例如，利用每個有關變化的注冊，在每個目的樓層呼叫的情況下，基于狀態描述的實際情況，宣布合并電梯設備的瞬時操作狀態和想要的目的操作狀態。狀態描述中說明的并且即將得到的電梯設備狀態變化作為情況表示的一部分，以轉換的形式傳遞給規劃系統；下面將會說明所述情況表示。因此，利用每個注冊的目的樓層呼叫，以環境搜索程序為基礎，獲得關于電梯設備運行狀態的全部信息。因而，可以針對固定的、預定的最優化標準來計算目的樓層呼叫的最優服務。設計該計算程序，以便實際上可以按照給定的標準在實時需求的情況下找到最優值。
通過規劃系統，按照可以在運行次序計劃的執運行序中得到所要的狀態變化的方式，制成確定的運行次序計劃。
因此，帶有本發明規劃運行次序的電梯設備，按照每種特有的實際情況執行表示實際規劃環境最優的運行次序。在這種情況下，可以按照完全不同的標準實現最優化，其中由電梯性能的提高、乘客等待時間/服務時間以及運行時間的減少，或者平穩運行管理的提高來產生最優化目的。
規劃程序以有利的方式局限于時間方面，這是因為計算性能和存儲器要求受到限制。搜索程序在有限計算資源種尋求最優或者近似最優的運行次序。用于這一目的的所謂“無論何時”算法已為本領域的技術人員所熟知，并且可將它用在這種搜索程序中。
按照本發明搜索程序的優選實施例，最好以轉換的形式將狀態描述與情況表示中的操作符描述一起傳遞給規劃系統。
根據本發明，配置時，將操作符描述傳達到目的樓層呼叫控制；最好包括規定電梯設備基本狀態轉移的操作符。與所要構建的運行次序解決方案的基本模塊一樣，在要確定的運行次序規劃基礎上，形成所述操作符。在每個目的樓層呼叫分配或者具體規劃任務的解決方案情況下，規劃系統從操作符描述中選擇要在方案中使用的操作符，并確定操作符參數的具體數值，以及運行次序規劃中出現操作符的排列次序。這種排列次序規定操作符在規劃中的執行次序，即運行次序。
與以前的固定程序分配算法相比，所述規劃系統可以具有任何數目的操作符，包括那些可以滿足安裝時用戶一方尚未出現的服務需求。如果在稍后的時候出現這些需求，那么，幾乎不需要向規劃系統傳達這些服務得以被表達的相應情況表示。于是，系統可以立即解決這個任務。如果沒有為出現的服務需求提供操作符，則規劃系統中操作符的模塊性將會保證能以簡單的方式添加或取出新的操作符，而不致影響已存在的操作符。因此，通過改變可以得到的操作符數目以及操作符自身的定義，電梯設備可以簡單靈活地適應客戶所需有關運量結構的變化。
在通過本發明的電梯呼叫控制控制電梯組的情況下，如果電梯組中沒有要滿足乘客單獨服務需求的單獨預約電梯，就要考慮到電梯設備連續工作情況下的服務需求。從原理上講，電梯控制和各操作符按照下面的方式互相匹配任何電梯在任何時刻以情況表示的方式執行所有預定的特別服務需求。如果需要，服務需求是結合在對組的操作中的準特別呼叫。
可按中心原則、分散原則或中心原則與分散原則相結合嵌入規劃系統，作為目的樓層呼叫控制。
在使用所謂中心作業管理器構成目的樓層呼叫控制的情況下，這就是電梯的終端和單獨作業管理器之間的判定界面。終端向中心作業管理器指示其運送查詢。作業管理器對各注冊目的樓層呼叫，即為了所謂作業而向每個單獨電梯的作業管理器請求輸送許可。中心作業管理器負有單獨管理乘客的所有實際運送查詢，即目的樓層呼叫的責任，并預約各個被選擇的電梯的運送請求，即所謂的作業。終端從中心作業管理器收到作為(被)選擇的電梯的確定響應，并將它們顯示于其上(如“A”或“B”)。
因為所有的通信都通過中心控制的方式，即中心作業管理器來進行，所以終端和電梯之間的通信簡單而便于組織。在中心作業管理器中以等待隊列來組織作業，即所謂“先進先出”的數據結構。這種組織比較簡單，并保證清晰的運行次序。
在中心原則情況下，終端僅需處理乘客的目的樓層呼叫輸入以及中心作業管理器預約的電梯確認，并且終端需要用于這一目的的簡單軟件。使用簡單而經濟的終端能夠實現該目的。
在作業管理器的分散結構情況下，終端通過通信網絡的形式與電梯組中單獨電梯的作業管理器相連接。終端為各自注冊的目的樓層呼叫直接向單獨電梯的作業管理器請求運送許可。終端獨立地收集并比較這些許可，并確定乘客的最佳預訂。在分散作業管理器的情況下，以并行的方式組織多個作業，其中可疊加查詢和預訂。
目的樓層呼叫控制的分散原則的另一個優點在于，與中心原則相比，作業管理器對查詢的反應較快，因為不必提供分離的中心控制，所以由于作業管理器的分散化和簡化結構的緣故，增強了整個系統的穩定性。
目前，作為提供的分散實施例，終端裝有智能預訂軟件。最好通過使用約定的網絡協議執行終端與單獨電梯的作業管理器之間的通信聯系。單獨電梯的作業管理器能夠并行組織作業和正確管理其狀態。
在目的樓層呼叫控制中，作業管理器的中心原則和分散原則也可以彼此結合。可以在網絡中出現任何數目的控制一部或者多部電梯的作業管理器。
按照本發明特別的優選發展，基于環境的目的樓層呼叫控制表現為實現設備的全部管理的多代理系統(multi-agent system)，其中在該多代理系統中，所述規劃系統是代理。電梯設備可以包括任何數目的具有任何布局的電梯。因此，也可以使多部電梯與一組不同數目的樓層相互協作，即所謂非一致多樓層組。
與所述多代理系統一樣的構造使模塊化能夠實現目的樓層呼叫控制，其中，可以依需變換各組成部分，即所謂代理，如規劃系統，轎廂門，驅動裝置和運行操縱員而不必非得改變整個系統。
多代理系統中控制事件的代理激活使所述系統相對于錯誤的發生而言實際上更為耐用。例如，如果某層的旋轉門因錯誤的聯系而失控，則要么作業管理器可以撤銷運行，要么運行操縱員可以執行已經存在的計劃。對于其它的乘客查詢，可以向配置管理器傳達錯誤，向系統所有的有關組成部分通知該電梯暫時不能在該層樓提供服務。組成部分的故障并不意味著整個系統的迅速崩潰，從而保證了乘客的安全。
圖1以圖例的形式示出第一實施例，它具有控制各個電梯的分散作業管理器的目的樓層呼叫控制；圖2示出在具有用以控制一組電梯之分散作業管理器的目的樓層呼叫控制中所要求的以及所許可的作業池的結構示意圖；圖3示出第一實施例的瞬時狀態描述；圖4示出根據第一實施例確定運行次序的曲線圖；圖5以圖例的形式示出第二實施例結構，它具有作為終端和各個電梯之間界面的中心作業管理器的目的樓層呼叫控制；圖6以方框電路圖的形式示出中心作業管理器的等待隊列中作業的結構；圖7示出第二實施例電梯A的瞬時狀態描述；圖8示出第二實施例電梯B的瞬時狀態描述；圖9示出具有停止指令的操作符構造，有如第二實施例中所用的那樣。
按照理想的方式，選擇自動聯網結構作為通信網絡2。在本實施例中，實質上已為人們所知的網絡具有指定的IRON。IRON幫助自動聯網，而且它是配置自由控制的判定前提。
已知的自動聯網的示例結構是“Jini”，“Universial Plug and Play(通用即插即用)”和“Bluetooth(藍牙)”。在這種通信網絡2中，能夠聯網的裝置(所謂代理)登錄并相互作用，而不用進行配置或者管理。所有這些裝置的綜合以及實現的服務因此而完全自動地運行。這種通信網絡2最主要的方法是“注冊”，“查找”，“通知”。
通過“注冊”，各個裝置登錄網絡并使其服務為人所知。
通過“查找”，一個裝置可以找到另一個裝置或者請求的服務。
通過“通知“，對于特定時間項目的信息，一個裝置可以登錄另一個裝置。
在電梯組中，終端、驅動裝置、轎箱門、中心作業管理器和/或分散作業管理器作為能夠聯網的裝置登錄。
—終端使用樓層位置和網絡中的x，y坐標，以登錄網絡并向它們本身通知存在所有的管理器；—驅動裝置表示電梯控制的物理組成部分。它們獲知有關可以到達的樓層信息，某樓層有多少個旋轉門，以及位于哪一側。此外，可以將關于特定時間，如選擇器的變化和狀態的變化(例如，行走，到達，停止)信息提交給驅動裝置。
—轎箱門以屬于哪一個驅動裝置，設置在哪一個樓層和哪一側打開的信息登錄。通過這些信息，作業管理器立即找到一部電梯管多少個樓層和每個樓層有多少門。
—作業管理器使用有關它們表示哪一個驅動裝置的信息登錄網路；嚴格分散原則下的單一驅動裝置或者嚴格中心原則下出現的所有驅動裝置。
從原理上講，任何數目的組成部分都可以登錄到網絡中。因此傳統的電梯組概念成為多余，具體地說，布局完全不同的任何數目的電梯都可以出現在一個組中。
例如，如果十一部驅動裝置登錄，其中的三部僅有一個門，四部具有兩層上的三個門，四部具有均勻分布在三層上的六個門，那么這就有了所謂的非一致多樓層組，其包括三個帶有一個門的單層樓層，四個雙層樓層，其中一層樓層具有一個門，另一層樓層具有兩個門，四個三層樓層，其中每層樓層有兩個門。
在控制中，每個單獨電梯的作業管理器能夠識別和正確處理與驅動裝置有關的一定數目的樓層和門。具體包括；在多層樓層的情況下，規劃系統通過出現的所有樓層來規劃乘客的登梯和下梯。
作業管理器的運行操縱員在停止時，向乘客想要登梯或者下梯的樓層的所有門發出開門命令。
在這里使用的IRON通信網絡2的情況下，代理可以相互通知在自己的操作邏輯中改變、預備數據和對數據進行綜合。代理可以通過廣播發現其它代理中的哪一個已經登錄到網絡中，并且與其它代理通信。此外，代理可以向另一個代理預訂數據。
所述多代理系統的各個組成部分，即所謂代理，除是上述終端外，還是作業管理器4，它對電梯的邏輯控制和物理控制所需的所有組成部分進行綜合。這里有規劃系統或者規劃者5、調度器(程序)6、轎廂門管理器7、運行操縱員8、電梯驅動裝置9和觀察器(程序)10。
終端3.1，3.2，3.3安裝有智能預訂軟件，并直接向每個作業管理器4為各自的注冊目的樓層呼叫請求運送許可。通過規定的網絡協議執行終端與作業管理器4之間的通信聯系。每個終端3.1，3.2，3.3都裝備有配置管理器11所屬的乘客識別裝置，實際建組物布局，例如，樓層數，進入區域，乘客分組，進入識別，服務需求等和乘客數據都存儲在能夠被呼叫的配置管理器11中。在注冊目的樓層呼叫時，每個終端都可以從配置管理器11收集乘客數據，并將這些數據傳遞到調度器6。于是，每個終端檢查注冊的乘客是否具有進入想去的目的樓層的允許。如果檢查成功，則終端向作業管理器4請求其運送許可。
規劃器5本身考慮實際的和特定運量情況，來計劃向新乘客提供最優服務，并且在這種情況下產生最優計劃，然后傳遞給調度器6，用來控制電梯驅動裝置9，后面將會說明所述的調度器。規劃器5的起始點是情況表示，這在調度器6記錄新乘客的每個時間點都是實際的，而觀察器消除被運送的乘客數據。
調度器6通過兩階段規定的網絡協議與三個終端3.1，3.2，3.3通信聯系。它接收終端3.1，3.2，3.3的輸入，并以情況顯示的方式將其記錄在規劃器5，針對運送預訂的乘客中新乘客的影響檢查所生成的最優計劃，并將運送許可傳達給終端。如果譬如因該電梯的乘客組之間不可解決的矛盾而導致不能解決該問題而找不到辦法，那么調度器6同樣向對應的終端通知該事實。如果有乘客預訂，則調度器6向運行操縱員8發送實際的運行次序計劃。終端將其表示在顯示器上。
觀察器10監控電梯設備的狀態，并更新規劃器5的情況表示。如果確定電梯已經停止在某層，并且轎廂門正確地打開，那么所有的乘客都加上提出-boarded-的乘客-served-標記則把所有“登梯”的乘客標記為“已服務”，并且他們的目的地與該樓層相應。從當電梯到來時他們登梯算起，乘客一直等到標記為“已登梯(boarded)”。
在這種情況下，觀察器對計劃或者運行操縱員的行為一無所知，僅僅由在驅動裝置9和轎廂門管理器7預訂的信息來維持。這與發生特殊操作是一樣的，例如在火警的情況下觸發控制，通過驅動裝置9來處理控制，并中斷運行操縱員的正常操作，以便保證情況表示按照實際狀態發生的變化來更新。
運行操縱員查看各自的實際計劃，也就是把相應的命令傳輸給電梯驅動裝置9和門的驅動裝置。根據時間表，從其實際的計劃可以得知電梯停靠的下一站和轎廂門打開多長時間，以便所有的乘客具有足夠的時間登梯和下梯。規劃器5已經確定有多少乘客在停靠時改變狀態。如果運行操縱員8不再有計劃，他就放棄電梯，以便停放該電梯。在任何位置，運行操縱員8都可以對于調度器6向其發送的實際計劃而調換其實際的運行計劃。這種變化如何發生，取決于運行操縱員處于何種實現狀態。因此，例如，在運行操縱員8可以行進到新計劃的第一停靠站之前，需要首先結束啟動的老計劃的停靠步驟。
驅動裝置9執行從運行操縱員8得到的行進和停止命令，除此之外，它獲知電梯在各樓層之間的行進時間。為了最優化，它作出規劃器5可以使用的行進時間表，同樣報告電梯的實際所處位置和行進方向，或者是否剛剛停止過。
轎廂門管理器7管理電梯所有的轎廂門，并監控轎廂門是否正常地打開和關閉。在這種情況下，所述轎廂門可以開在轎箱的不同側面。其同樣確定門打開和關閉的時間，并將其傳達給規劃器5，以便最優化乘客服務時間。
作為在發生特別情況下執行獨立行動的獨立代理來實現每個代理。具體地，多數的驅動時間因此可以疊加。因此，例如，調度器可以同時接收不同終端3.1，3.2，3.3的查詢，并向它們提交規劃器5。分散的作業管理器可以并行運送多個作業的許可，同時仍保持其它作業的預訂。僅當相應的終端預訂時，作業管理器才是必須的。
由于調度器6傳送許可和各自終端的預訂之間在理論上可以經過任何長的時間，因此，在該期間內，另一個終端能夠進行預訂。在這種情況下，當終端發出它的預訂時，調度器6必須檢查所傳送的許可是否仍然有效。查詢和預訂的隨機疊加需要終端等待其預訂的確認，在沒有確認的情況下，尋找另一個作業管理器4的預訂。如果因為電梯中的情況已經按照某種方式改變，以致出現已經預訂的乘客和要預訂的乘客之間的矛盾，從而再次規劃同樣未取得成功，則終端接收相應的反饋。
圖2示出分散作業管理器4中請求并許可的作業1到作業4的作業池。每個終端1，2通常只有一個電梯想要預訂的具體作業X或者作業Y。于是，終端將該作業發送給電梯組的所有作業管理器4，其從驅動數據得知相關的電梯是否既可以充當乘客的登梯樓層又可以充當乘客的下梯樓層。可以避免對電梯的不必要的請求，從原理上講，這對運送也不構成問題。
分散作業管理器4中出現兩種工作一方面，存在作業X，它被請求，并且作業管理器4必須為其計算許可，另一方面，存在作業Y，作業管理器4已經傳送了許可，但是尚不知道終端是否實際上預訂了它。
這里以及圖1所示的第一實施例的情況下只存在單獨一個電梯。不過，所述電梯也可以是一組電梯的一部分。本發明可以毫無限制地應用于這種電梯組。在電梯組的情況下，同樣，終端3.1，3.2，3.3直接向每個電梯的作業管理器4請求運送許可。終端3.1，3.2，3.3單獨收集這些許可，比較并計算乘客的最優預訂。所查詢的每個電梯主題與其它主題無關，并考慮到特定電梯的實際運量情況計算其最優的運行次序計劃，用來為新乘客提供服務。所查詢的每個電梯主題的許可返回到終端，選擇最優的許可和并委托相應的電梯運送乘客。如果作業管理器4確認與已經請求運送許可的終端相關的預訂，則預訂是必須的，并且在終端向用戶示明。如果作業管理器不再報告，則終端同樣有反應，并且不再無止境地等待所缺少的許可。
下面參考圖1，以具有單電梯單轎箱門的電梯設備的規劃問題為例，說明目前所述本發明目的樓層呼叫控制的工作模式，所述電梯設備為具有七層f1到f7停靠點的大樓(未示出)提供服務。電梯轎箱目前停靠在f4層。乘客P1在f2等待并希望到達f7層，而乘客P2已經在轎箱之中并要從樓層f1到f5。根據本發明通過規劃系統3來組織轎箱的運行次序。
觀察器10按情況表示方式檢測并實現電梯的特性，即電梯的瞬時工作狀態。乘客P1，P2的特性和乘客P1，P2的具體目的樓層呼叫作為目的樓層呼叫控制1的輸入量，通過與配置管理器11相聯系的終端3.1，3.2，3.3傳遞給調度器6。如圖2所示，所述調度器6在規劃器5的情況表示中將它們記錄下來。
在每個規劃程序中，例如(圖3所示那樣)，通過目的樓層呼叫的注冊來啟動哪一個，確定的操作狀態和想要的目的狀態，以及電梯狀態要得到的改變都在規劃系統可理解的狀態描述14中以聲明的方式合并。
圖3所示的狀態描述14在按McDermott et al.，1998的規劃表示語言PDDL中得以表達。本領域的技術人員同樣清楚，還有其它具有不同表達能力的建模語言，以及用來描述情況表示，而不改變本發明核心的建模語言。但是，在選擇規劃系統中，要注意的是要獲得建模的適當能力的規劃算法。
在如圖4所示狀態描述14的目的聲明15中，規劃系統3在開始獲知報告的乘客P1，P2和大樓的樓層f1到f7。為每個對象引入象征性常數。這里對于電梯2，有等待乘客P1，已經在轎箱中的乘客P2和所有的七層樓f1到f7。(objects(p1 -passenger)(p2 -passenger)(f1，f2，f3，f4，f5，f6，f7 -floor))調度器6從配置管理器11獲得有關大樓拓撲結構的詳細情況。其可以作為拓撲描述在狀態描述14中以下面的形式來發現(upper f1 f2)(upper f1 f3)(upper f1 f4)(upper f1 f5)(upper f1 f6)(upper f1 f7)(upper f2 f3)(upper f2 f4)(upper f2 f5)(upper f2 f6)(upper f2 f7)(upper f3 f4)(upper f3 f5)(upper f3 f6)(upper f3 f7)(upper f4 f5)(upper f4 f6)(upper f4 f7)(upper f5 f6)(upper f5 f7)(upper f6 f7)在拓撲描述1 6中，在每個實例中建立命令(upper？fi，？fj)，樓層fj在fi之上。大樓拓撲表示并非絕對必要。在簡化中，在假設電梯可以提供任何一層到其它任何一層的服務的條件下，在本方法的其它實施例中可以省略大樓的拓撲16的外在描述。
包括登梯樓層，即“origin”和目的樓層，即“distin”的具有乘客P1和P2的目的樓層呼叫的實際運送請求17如下表示(init(origin p1 f2)(origin p2 f1)(destin p1 f7)(destin p2 f5)(boarded p2).
根據前面規劃的運行次序，運送請求17另外還包括信息“boardedP2”，即乘客P2已經登梯并在轎箱之中。觀察器10將該信息插入狀態描述。
基本上，在運行次序的規劃范圍中，每個乘客P1，P2有三種狀態“waiting”，“boarded”和“served”，它們如下定義
waiting乘客在電梯門前等待。這里的電梯最初停靠在乘客的開始位置，即“origin”，在此之后，處于乘客指示的目的樓層，即“destin”。
boarded乘客位于轎箱中，并被運送到他或她的目的樓層，即“destin”，該目的樓層以前并未到達過，即served。
Served乘客在他或她的目的樓層已經離開電梯轎箱，即“destin”。該運送請求結束，乘客非常滿意該電梯所提供的服務。
在PDDL建模語言中，以兩條命令-boarded？p-和-served？p-來表示這三種可能的狀態。乘客P1等待電梯轎箱，并因此既不被注冊為-boarded-也不被注冊為-served-。
觀察器10設置電梯轎箱的實際位置18，其按照狀態表示如下表達(lift-at f4)).
規劃系統15的目的19按照狀態描述14如下表達(goal(forall(？p-passenger)(served？p)).
現在搜索將所有的乘客P1，P2轉換為-served-狀態的最短次序，當乘客離開其目的樓層-destin-時，可以精確地得到該結果。
除了通過狀態描述14對初始狀態的描述和規劃問題的目的狀態外，同樣也將操作符描述12傳送到規劃系統3。在此說明的實施例中，為了建立初始狀態和目的狀態之間的狀態轉移模型，還傳送停靠操作符以及向上運行-up-操作符和向下運行操作符-down-。作為這些操作符-stop-，-up-，和-down-的其它選擇，本領域的技術人員還知道其它的夠使電梯達到想要的變化的操作符，在給定的情況下并采用適當定義的參數，不會改變本發明的核心。根據McDermott等人1998的PDDL的語法，這里可以獲得以下的停靠操作符<pre listing-type="program-listing">(define(domain miconic)(requirementsadl)(types passenger-object) floor-object)(predicates(origin？person-passenger？floor-floor)<!-- SIPO <DP n="13"> --><dp n="d13"/>(destination？person-passenger？floor-floor)(boarded？person-passenger)(served？person-passenger)(lift-at？floor-floor))(action stop parameters(？f-floor) precondition(and(lift-at？f)) effect(and(forall(？p-passenger)(when(and(boarded？p) (destination？p？f)) (and(not(boarded？p))(served？p)))) (forall(？p-passenger)(when(and(origin？p？f)(not (served？p)))(boarded？p)))))</pre>向上運行操作符被表示為(action upparameters(？f1-floor？f2-floor)precondition(and(lift-at？f1)(upper？f1 f2))effect(and(lift-at？f2)(not(lift-at？f1))))向下運行操作符被表示為(action downparameters(？f1-floor？f2-floor)precondition(and(lift-at？f1)(upper？f1 f2))effect(and(lift-at？f2)(not(lift-at？f1))))停靠操作符用信號向電梯驅動裝置9的控制通知轎箱必須停靠在樓層f1到f7的特定樓層。于是，這里所述的實施例中將停靠操作符被定義成使它包括轎廂門的打開和關閉。也可以把轎箱門的打開和關閉看作門管理器7的獨立附加基本指令，或者可以對停靠操作符進行改進，以達到電梯還能打開和關閉門的效果。
向上運行操作符-up-和向下運行操作符-down-向驅動裝置控制發出關于控制方法的指令，以使驅動裝置9按照適當的方向運行。運行操縱員8按時間預置操作符控制驅動裝置9的次序。
基本上只有在轎箱停靠時乘客狀態才變化。在電梯轎箱在樓層的預定停靠的情況下，所有為了由轎箱運送而在該樓層-origin-等待的乘客都登梯，并且當該停靠處于他們的目的樓層-destin-時，所有的乘客都離開電梯。從而，在觀察器10的幫助下，這里發生的變化被注冊在停靠操作符中，并且在規劃系統5的運行次序規劃中得到考慮。同操作符-up-和-down-一樣，如果-effect-中編碼的標準都得到滿足或者被輸入，則作為驅動裝置9的指令的停靠操作符同樣有效。這里所示的實施例中，如果在停靠操作符中選擇了？f＝f5，當-boarded p2-和-destin p2 f5-應用在作為操作符實例stop(f5)的-effect-的停靠操作符中時，則P2根據狀態描述14和行為模型下梯。
操作符描述中或者作為狀態描述14的數據而說明到那個程度的數據被傳遞到規劃系統5，用于計算最優運行次序計劃。
從其它技術領域可以清楚規劃系統5。本實施例中的IPP規劃系統3可見于Koehler等人的‘Extending planning graphs to an ADL subset’(1997)inSteel，5，Proceedings of the 4th European Conference on Planning，pp.273-285，Springer，Vol.1348 of LNAI，這可從http//www.informatik.uni-freiburg.de/～koehler/ipp.html獲得，其搜索滿足規劃目的13(goal(forall(？p-passenger)(served？p))的STOP指令的可使用次序。同樣可以使用其它的規劃系統，只要它們能夠檢測并處理瞬時情況表示。
在理論上，在狀態描述14的輸出的情況下，規劃系統5在由操作符描述可獲得的操作符的基礎上獨立地選擇實例，同樣在確認的運行次序計劃20中確定次序。規劃系統5每一次都確定三種操作符-stop-，-up-，-down-的參數，產生所要的狀態變化。
在本實施例中的結果是，規劃的運行次序，即最優計劃，有如圖3中曲線所示。
Time step 0up f4 f5Time step 1stop f5Time step 2down f5 f2Time step 3stop f2Time step 4up f2 f7
Time step 5stop f7把這個計算的最優計劃13傳遞到調度器6。調度器在此基礎上檢查所產生的最優計劃，新規劃進來的乘客P1如何具有已經預訂的乘客的運送效果，并將運送許可傳達給終端。
這里描述的實施例中，為了規劃，只出現目的樓層呼叫。因此，對于一件作業只要提供一個許可。因此，在分散作業管理器4的許可計算與各自終端的預訂之間，沒有其它終端3.1，3.2，3.3的其它作業預訂。因此，在終端確認其預訂是多余的，但是預訂是即時而必要的。此時終端承擔顯示器上的指示，而調度器將實際的最優運行次序計劃20傳輸給運行操縱員8。
運行操縱員8檢查該實際的運行次序計劃20，即其將相應的命令按照各自的操作符的形式傳輸給電梯9的驅動裝置，以及轎廂門驅動裝置。
該運行次序計劃20具有這樣的效果電梯轎箱在步驟0從其所處的實際樓層f4行進到下一停靠站樓層f5。電梯轎箱按照步驟1-stop f5-停靠，而轎箱門在預訂的時間打開，以便乘客P2下梯，并因此得到服務，“served”。在步驟2，電梯轎箱向下運行，從f5到f2，-down f5 f2-，并在步驟3停靠在樓層f2，-stop f2-。乘客P1在那里登梯。在步驟4，電梯向上運行，從f2到f7，-up f2 f7-，并在最后的步驟5停靠在路層f7-stop f7-。同樣，乘客P1在這里下梯。通過該運行次序13，所有的乘客P1，P2都轉換為狀態-served-，并且因此得到運行次序計劃的目的模式10。
同時，運行操縱員8執行最優運行次序計劃13，觀察器10監控電梯設備的狀態，并不間斷地更新規劃器5的情況表示。在步驟1，它確定電梯已經停靠在樓層f5，并且轎廂門被正常地打開；它對乘客P2加上-served-標志。在步驟2，觀察器10對在f2樓層等待的乘客加上標記-boarded-。因此，電梯轎箱停靠在樓層f7，并且，在轎廂門正常打開之后，觀察器10同樣在位置描述中將乘客P1設置為“served”，以及在樓層f7的狀態表示5中設置電梯轎箱的實際位置9。
但是，并非必須完全執行產生的這個運行次序計劃20，相反，如果在此之前已經完全實現乘客的狀態或者特征和/或設備以相關方式的變化，根據本發明，啟動下一個規劃周期，并為新的規劃位置創建最優運行次序計劃20。因此不對計劃進行修改。
圖5示出本發明第二實施例的目的樓層呼叫控制的示意結構和基本構造。目的樓層呼叫控制25包括中心作業管理器26和兩個分散作業管理器，配置管理器29，以及具有所有典型終端特性的終端30，通過通信裝置31相互連接這些組成部分。分散作業管理器27，28的結構和功能示意性地與第一實施例的分散作業管理器4的相對應。
在這里，作為所謂電梯組運量分組控制來組織所述目的樓層呼叫控制，所述的電梯組有兩個電梯A和B，并在七層大樓中有停靠點。在這種情況下，規劃任務如下表示在此時，電梯轎箱A向上運行；位于樓層f2并將到達樓層f3。電梯轎箱B位于樓層f1。電梯A運送限制進入樓層3和4并且目的樓層是f7的乘客P1，而電梯B空閑。在這種情況下，新的乘客P2作為VIP(貴賓)出現，其因為優先權的緣故，而在其它乘客之前被運送。乘客P2剛剛將她或他的從樓層3運送到樓層f7的請求發送出去。
本例中以下面的方式將乘客P2分配給電梯A、B之一以盡可能少的停靠站來運送乘客P1，P2，并且要滿足所希望的服務需求“VIP”和“進入限制”。
中心控制管理器26收集來自配置管理器29的終端的請求以及分別檢測的與人有關的數據，即等待隊列中的作業，這里的Job1到Job4，有如圖6所示的那樣。從隊列中選擇Job1并將其傳輸給各自電梯的分散作業管理器27，28。電梯A，B的分散作業管理器27，28之一獨立于其它作業管理器，并在規劃系統的幫助之下按預定的最優標準確定最佳運行次序方案，并將其作為許可返回給中心作業管理器26。中心作業管理器26檢查所有的許可，從中選擇最佳許可，并以最佳許可預訂電梯上的乘客。在成功分配之后，將最佳電梯的標識傳輸給最初開始作業的終端30。終端30因此僅僅作為顯示器。因此處理Job1，并將其刪除。對于Job2等等，重復該程序，直至等待隊列中的所有作業都已處理完畢。
對于作為實際規劃任務作業的注冊通信數據信息，開始時，電梯A，B的每個分散作業管理器27，28創建情況表示，該情況表示被傳輸到各自的規劃系統21。所述情況表示包括狀態描述32和操作符描述。
對于電梯A，在目標聲明33中，規劃系統獲知報告的乘客P1、P2和大樓的樓層f1到f7。為每個對象引入象征性常數。此外，在對象(目標)聲明33中為每個乘客P1，P2執行與一個或多個服務需求的聯合，例如，“VIP”，“conflict”，“going_direct”等。
在根據配置管理器29識別乘客的范圍中的每種情況下，服務需求都是已知的，并且將它們作為部分作業或者許可查詢，從中心作業管理器26傳遞給單獨電梯A，B的分散作業管理器27，28。可以按照電梯設備或者大樓的情況，或者按照一天中的時間來為所有的或者任何選擇的乘客提供特定服務需求。此外，通過使用規劃系統，對于確定運行次序，可以按照運量將其表示為各項服務需求，尤其是VIP需求的靈活加權。
提供如下的服務需求將所有的乘客分成兩組“conflict_A”和“conflict_B”，他們可能從未進入過電梯；“never_alone”型乘客，對于他們而言，在運行中，必須有以“attendant”型的乘客為形式的同伴。在這種情況下，運行中并非絕對總是需要相同的同伴，而是可以改變的；“going_direct”型乘客，他們在行進中不停靠，直接到達他們的目的樓層；“vip”型乘客，因為優先的緣故，他們在其它乘客之前被運送；闡明限制進入特定樓層的乘客；“going_up”型乘客，只向上運送他們；“going_down”型乘客，只向下運送他們；因此，乘客P1，P2可以容易成為多種服務需求的主體；但是，這些需求應該是不沖突的，從而也可以有效地運送乘客。例如，兩個乘客P1，P2是本質上是沖突的，對此，聲明以下的事項(P1 (either conflict_A never alone))(P2 (either conflict_B attendant))這里，電梯中不單獨運送P1，他屬于乘客組A。但系統所知道的唯一可能同伴P2屬于乘客組B；乘客組A可能從未進入電梯。伴隨于此，就與所排除的情況不同，當另一個不屬于組B的同伴變得為系統所知時，則僅僅P1被運送。
對于電梯A，對象聲明33包括已經在行進的乘客P1，即正常乘客，新乘客P2，即VIP，以及所有的七層樓f1到f7。(objects(p1 -passenger)(p2 -vip)(f1，f2，f3，f4，f5，f6，f7-floor))本實施例中，假設從每一層開始到其它每一層都可以得到服務，故省去了大樓的拓撲表達描述。
乘客P1和P2實際注冊的運送請求34表示如下(init(origin p1 f1)(origin p2 f3)(destin p1 f7)(destin p2 f7)(boarded p1)運送請求34的基本原則就是一般假設當出現無對應的“boarded”信息時，乘客在樓層等待。準確地講，這表示乘客P2在這里等待。其中對乘客P1的進入限制表示為(no-access p1 f3)(no-access p1 f4)電梯A的電梯轎箱2的實際位置在狀態描述32中表示為(lift-at f2))所有表達的事實加權為正確，而所有其它的加權為錯誤。
規劃系統的目的36用公式表示為(goal(forall(？p-passenger)(served？p)).
搜索將所有乘客P1，P2轉換為“served”狀態的停靠站最短次序，當他們在目的樓層或者樓層f7下梯之后，就可以準確地得到該結果。
由于在本實施例中，僅確定一種停靠最少的次序，規劃系統同樣接收一個所謂的停靠操作符37，根據它，系統可構建有效的運行次序計劃。圖9示出停靠操作符32的例子。同前面狀態描述32中一樣，這里，用按McDermott等人1998的建模語言PDDL來說明。停靠操作符37包括說明性描述38，其中說明了在何時允許電梯A，B在樓層f1到f7中停靠。這里，在這種情況下或者為乘客或者為乘客組具體定義進入限制-no-access-，在電梯轎箱應該停靠的樓層f1到f7建立功能指令39，以及在電梯設備18的實際停靠狀態下該停靠所具有的效果。功能指令39在這種情況下的前提表示特定用戶想要的服務需求的轉換。如圖9所示的復雜停靠操作符，能夠通過與乘客有關的所有服務需求和對象聲明33來繞過規劃系統21。
對于這里描述的規劃示例來說，僅與圖5中下劃線表示的操作符32的前提條件有關，該前提用公式表示在出現VIP和具有進入限制的乘客時在樓層f1到f7停靠的條件。
把為每個電梯A創建的瞬時情況表示32傳遞給屬于電梯A的規劃系統。
本發明使用的合適規劃系統獨立于實際的規劃問題來工作。本領域的技術人員清楚這種規劃系統。
在第二實施例中，同樣，來自Koehler等人的1997，Extending planninggraphs to an ADL subset(1997)，appearing in Steel，Proceedings of the 4thEuropean Conference on Planning，pp.273-285，Springer，Vol.1 348 of LNAI，并且可在http//www.informatik.uni-freiburg.de/～koehler/ipp.html獲得的IPP規劃系統下，搜索滿足規劃目的31的STOP指令的有效次序。同樣可以使用其它的規劃系統，只要它能夠完全檢測和處理瞬時情況表示。
在解決具體規劃問題時，規劃系統選擇操作符描述23的要在運行次序計劃中使用操作符，這里指停靠操作符37。如果在狀態描述32中出現服務需求，例如“VIP”，“going_direct”等，則規劃系統獨立地檢查操作符37的功能指令39的相應前提條件。如果在與呼叫有關的狀態描述32中未出現作為前提條件的包括在操作符37中的服務需求，則被認為是操作符37的多余前提條件，而被自動丟棄。這里未考慮的服務需求的示例是前提條件-attendant-。然后確定操作符參數的具體數值和運行計劃中出現操作符的排列次序。該排列次序確定運行次序中操作符的執行次序，并因此確定為各自目的樓層呼叫服務的運行次序。
規劃系統不能夠為電梯A找到解決方案乘客P2應該立即被運送，即電梯A必須在f3停靠。但是，P1在電梯中，并不可進入f3。因此，在P1下梯之后才能在f3停靠，即電梯A必須首先行進至樓層f7；由于VIP條件，需要VIP在所有乘客之前被運送，所以反過來是不可允許的。
由于電梯B根本上并不知道乘客P1，故規劃系統可以為電梯B毫無問題地解決位置42(圖8)，因為他或者她實際上在電梯中處于中途，而僅僅乘客P2被報告。因此，規劃系統中電梯B的對象聲明43同樣僅包括由服務需求VIP表示的新乘客P2，和所有的七層樓f1到f7。(objects(p2-vip)(f1，f2，f3，f4，f5，f6，f7-floor))此外，從任何一層開始到任何一層都可以得到服務。
乘客P2的實際運送請求44表示為(init(origin p2 f3)(destin p2 f7).
在狀態描述42中電梯轎箱B的實際位置描述45表示為(lift-at f1).
在電梯B的情況下，規劃系統的目的表示式46與電梯A的相同。它與對象43和作為電梯B的情況表示42一部分的上述停靠操作符37一起轉移到規劃系統中。對于電梯B的運行次序規劃，僅僅與操作符前提條件“停靠在出現VIP的樓層”有關，因為電梯B的狀態描述32同樣只把服務需求VIP轉移到規劃系統。在這種規劃次序中，未予考慮按STOP操作符37的功能指令39的指示和前提條件形式提供的所有剩下的服務需求，從而不對運行次序計劃24產生效果。
從該輸入開始，規劃系統21為電梯B產生下面的運行次序time step1(stop3)time step2(stop7)，它表示成功運送乘客P2的最少停靠次序。
如果在中心作業管理器26輸入電梯A，B的運行計劃結果，則對電梯A，B的兩個運行次序許可進行加權。中心作業管理器26選擇具有最佳許可的電梯。這里，最佳解決方案就是電梯B唯一可能的運行次序計劃。因此，中心作業管理器預訂電梯B上的乘客P2。電梯B在接收到預訂之后，實現運行次序計劃；所有其它的電梯按其原先的計劃行進。
權利要求
1.一種規劃電梯設備運行次序的方法，其中對通過傳感系統測得的運行查詢來確定關于預定最優化標準的最優運行次序，其特征在于，設置用來確定最優運行次序的以環境為基礎的搜索程序，并在規劃環境中各相關變化的情況下確定實際運行次序。
2.根據權利要求1所述的方法，其特征在于，在規劃環境中各相關變化的情況下，針對特定人測得的實際數據和與規劃有關的數據合并為情況表示中搜索程序可理解的格式。
3.根據權利要求1或2所述的方法，其特征在于，在情況表示中向搜索程序提供電梯設備所要產生的目的狀態和表示電梯設備基本狀態轉移的一個或多個操作符。
4.根據權利要求3所述的方法，其特征在于，針對特定人的測得的數據和與規劃有關的數據合并為情況表示中搜索程序可理解的格式，其中針對服務需求按照模塊形式構建所述操作符，并且所述操作符包括與控制方法有關的指令。
5.根據權利要求4所述的方法，其特征在于，在電梯組的情況下，電梯組的多部電梯同時滿足多項服務需求。
6.一種目的樓層呼叫控制，用于確定電梯設備的一部或者多部電梯轎箱的運行次序，它包括至少一個用于檢測運行請求的呼叫注冊裝置；還包括用于確定運行次序的處理單元，為了注冊的運行請求，所述運行次序關于給定的最優標準是最優的，其特征在于，提供作為處理單元的規劃系統，并且規劃系統確定特定環境的最優運行次序。
7.根據權利要求6所述的目的樓層呼叫控制，其特征在于，所述規劃系統是多代理系統的一部分，其中呼叫注冊裝置可操作地通過通信網絡與規劃系統相連接。
8.一種電梯設備，包括至少一部帶一層樓層的電梯和至少一部帶兩層樓層的電梯，以及根據權利要求6所述的目的樓層呼叫控制。
全文摘要
本發明涉及用于電梯邏輯結構的目的樓層呼叫控制系統，其提高了運送能力，靈活并且耐用，具體地，它能夠考慮到個人/群體乘客的運送需求。為了為注冊的目的樓層呼叫確定最優運行次序，其通過基于情況的搜索方法為固定的、預定的最優標準計算目的樓層呼叫的服務。隨著電梯瞬時位置的每個相關變化，確定全新的計劃，然后運行電梯。通過運送量和/或使用的操作符定義，可以將控制技術服務需求調整到滿足客戶的需求。能夠使用作為多代理系統而設置的目的控制系統來實現任何數目具有變化布局的電梯的邏輯控制，例如多樓層組。
文檔編號B66B1/18GK1420836SQ01807393
公開日2003年5月28日 申請日期2001年3月29日 優先權日2000年3月29日
發明者亞娜·克勒, 基利安·舒斯特 申請人:因溫特奧股份公司