這一章是HLA中的精華和困難的部分。主要是時間管理，時間同步。
主要包括三方面的內容：1）時間管理服務，爲仿真中的事件排序；2）對各個獨立的聯邦成員進行同步；3）使聯邦與真實世界的時間同步。
上述三個內容，其目的就是確保聯邦運行於不同的分佈式系統時能夠產生相同的結果。
-------------------------
5.2 時間管理 -- 事件都是有序的
時間管理服務就是要確保事件能以正確的次序發送到各聯邦成員。對於聯邦餐館例子來說，我們的目的就是使聯邦時間的推進速率與牆鐘的推進速率大致相同：小船以仿真速度沿水槽前進，壽司以合理的間隔時間出現，用餐者以一定的時間享受食物。因此可以這樣粗略地定義實時仿真：仿真中事件出現的時間間隔等於觀察者所感受到的時間間隔。
仿真時間和牆鍾時間的區別在於：仿真時間是仿真運行所代表的時間，牆鍾時間是觀察者在牆鐘上所看到的時間。兩者之間沒有直接的聯繫。如果仿真是實時運行的，仿真時間與牆鍾時間以相同的速率推進。但兩者的初值不同。 也就是說，如果不考慮實時仿真的話，仿真時間可以跟牆鍾時間完全沒有關係，可以大大快於牆鍾時間（比如爲了仿真真實世界發生的順序和結果），可以大大慢於牆鍾時間（比如爲了仿真真實世界發生的順序和結果），也可以跟牆鍾同步（比如爲了進行實時仿真，強調仿真的時間性）。 通常情況下，我認爲第一種和第三種情況會多一些。
要使聯邦實時運行，在編寫程序時必須使每個聯邦成員能以牆鍾時間相同的推進速率改變狀態。以餐館聯邦爲例，運輸聯邦成員仿真時間的推進量是牆鍾時間的函數。運輸聯邦成員由計算小船的下一個時間（1s後）的位置開始，在200ms後完成。因爲下1s的小船位置已經計算完成，所以在計算完成點它（運輸聯邦成員）的仿真時間可以推進1s，但是由於運輸聯邦成員的仿真時間比牆鍾時間要早，它將等待800ms，此時其仿真時間保持不變。休眠後運輸聯邦成員的仿真時間與牆鍾時間相符合，小船位置開始更新，下一循環開始。
因此運輸聯邦成員能否實時運行取決於它在相應的牆鍾時間推進前能否完成狀態的計算。
---------------------------------
事件驅動的仿真與上面流程類似，只是它的時間推進間隔是變化的。而時間驅動是以相同的步長推進仿真時間。事件驅動的仿真，其計算的是事件隊列中下一個事件時間到來時的狀態，而且必須在相應的牆鍾時間到來之前完成計算。
---------------------------------------------
時間管理服務的目的就在於確保事件能以正確的因果次序到達每個聯邦成員，保證同一個聯邦的多次執行能產生相同的結果。
時間管理服務用於處理仿真時間，它並不在聯邦成員與現實時間（牆鍾時間）之間建立任何聯繫。時間管理服務只是協調聯邦內仿真時間的推進以及帶有時間戳的數據的分發。
時間管理服務可以支持多種時間管理機制:1）沒有明確的時間管理機制；2）保守的同步機制，只有在確信不會收到過去發生的事件的前提下聯邦成員纔會推進仿真時間；3）優化的同步機制，聯邦成員能自由推進仿真時間，但如果收到過去發生的事件，它能退回到其以前的時間狀態；4）行爲掃描機制，各聯邦成員同時相互交換信息，在共同允許的條件下推進仿真時間。
每個聯邦成員都有各自的仿真時間，時間管理服務的目的就是協調所有聯邦成員仿真時間的推進。
仿真時間：1）具有初值；2）有次序；3）大於等於初值；4）有一個正的無限大值。
-----------------------------------------------
時間調節的聯邦成員 時間受限的聯邦成員
----------------------------------------------------
HLA中時間管理的效果在事件的接收與發送中體現，當聯邦成員有下列行爲之一時發出事件：1）更新屬性值；2）發送交互；3）刪除對象實例。
當RTI執行下列行爲之一時聯邦成員接收事件：1）反射屬性值；2）接收交互；3）移去對象實例。注意，上述三個行爲都是回調實現的。由RTI主動回調聯邦成員的函數來實現的。同時，值得注意的是登記對象實例和發現對象實例沒有包含在上述之列，原因在於這兩個操作發出的事件與時間管理無關。
圖5-6的理解：某聯邦成員A獲得Grant，則進入時間批准狀態。此時，A具有當前仿真時間和前瞻量，A可以進行各種仿真操作，A也可以發出事件，但是A能發出的事件的最小時間戳=當前仿真時間+前瞻量。因此，從RTI角度來看，RTI能夠得到所有的聯邦成員所能發出事件的最小時間戳。則當某聯邦成員請求推進其仿真時間時，RTI就可以評估一下，是否要推進的仿真時間已經小於所有聯邦成員所能發出事件的最小時間戳。如是，則可以順利推進仿真時間；如否，則當前還不能推進仿真時間。當A完成當前仿真任務，就可以請求推進仿真時間（TAR），則A進入時間推進狀態。進入該狀態後，聯邦成員的仿真時間並不該改變，但是A所能發出事件的最小時間戳發生了改變，改變爲其請求時間與前瞻量之和。同時，在時間推進狀態下，A開始接收TSO事件。這裏還有一個細節需要注意，當A進入時間推進狀態時，A所能發出的事件的時間戳已經改變爲t+2s，假如A發出的TAR請求延遲很久，其實也不會影響RTI的決策。因爲如果發所發出的TAR不能到達RTI，則在RTI看來，A所能發出的事件的時間戳最小還是t+s，則別的時間受限聯邦成員的仿真時間就不能推進到大於t+s，則時間戳爲t+2s的事件的到來更不可能導致其他時間受限的聯邦成員接收“過去”的事件。
圖5-7理解時，一定要注意兩個聯邦成員的前瞻量爲常數，並且在圖上表示得特別小，或者說在圖上，顯得比s小了很多。因此，看起來好像管理者聯邦成員的最小允許時間戳僅僅比其當前仿真時間多了一點點。
還要注意：在這個例子中，要區分最小允許時間戳和時間推進步長。最小允許時間戳是聯邦成員在某時刻所能發出的TSO事件所攜帶的最小的時間戳；而時間推進步長是當該聯邦成員使用TAR並獲得RTI的grant時，仿真時間的增加值。
圖5-6和圖5-7中的核心是：當聯邦成員處於時間批准狀態（初始時或者接收到grant時）時，最小時間戳等於仿真時間與前瞻量之和；當聯邦成員處於時間推進狀態（聯邦發出TAR請求時）時，最小時間戳等於請求時間與前瞻量之和。 通常情況下，請求時間等於當前仿真時間與時間推進步長之和。那麼，當聯邦成員處於時間推進狀態時，其最小時間戳等於當前仿真時間+時間推進步長+前瞻量。
-----------------------------------------------------------------
5.2.4.5 事件驅動的仿真
事件驅動中，仿真模型通過對下一個事件的處理來進行推進，所謂下一事件是指聯邦成員事件隊列中具有最小將來仿真時間的事件。
HLA聯邦使用事件驅動的時間管理機制時，聯邦成員根據聯邦中其他聯邦成員產生的事件來調整其事件隊列。 聯邦沒有一個集中的包括所有事件的事件隊列，聯邦成員使用RTI的時間管理服務來發現其他聯邦成員產生的事件（外部事件），這些外部事件要與聯邦成員自身產生的事件（內部事件）相結合，聯邦成員負責維護自己的內部事件隊列。
事件驅動的聯邦成員使用Next Event Request服務來請求時間推進，並指定內部事件隊列中下一事件的仿真時間。 RTI以下列形式之一作出回覆：
1）RTI調用回調函數Time Advance Grant，並返回聯邦成員使用Next Event Request服務所申請的仿真時間。這種情況下，RTI保證聯邦中其他聯邦成員發出的事件不早於該內部事件，該聯邦成員的仿真時間增加到該內部事件時間。 因此該聯邦成員可以從隊列中移掉該事件，並對其加以處理。
2）RTI調用回調函數（Reflect Attribute Values, Receive nteraction 或者 Remove Object Instance）返回一個外部事件。該外部事件的時間戳早於請求的時間，緊接着RTI調用回調函數Time Advance Grant，允許聯邦成員推進到該外部事件的時間。這種情況下，RTI保證不會有其他外部事件的時間早於該外部事件的時間。聯邦成員的仿真時間增加到該外部事件的時間後，對該外部事件加以處理，處理結果可能產生其他外部或者內部事件。
因此，聯邦成員的仿真時間增加的步長不是固定不變的，而是從一個事件的時間到另一個事件的時間。這些事件可能是外部事件也可能是內部事件，聯邦成員的主循環如下：
仿真循環：
檢查內部事件隊列中的下一個事件；
調用Next Event Request，並指定該內部事件的時間；
等待並處理RO與TSO事件和其他RTI的回調服務；
等待Time Advance Grant；
仿真事件推進到批准時間；
如果仿真事件大於或等於內部事件的時間，從隊列中移掉該內部事件並加以處理；
-----------------------------------------------------------------------------------
5.2.4.6 事件管理服務如何調度事件驅動的聯邦成員
假設：1）管理者聯邦成員，使用TAR以相等的時間步長推進仿真時間，在時間批准狀態他的計算負擔很小，大部分時間都在等待；2）生產聯邦成員，事件驅動。使用NER服務推進時間，它能及時地完成處理事件所需要的計算，不會發生延遲管理者聯邦成員的情況。它的推進依賴於管理者聯邦成員和事件的到達。
圖示在圖5-9中。
這裏的一個關鍵點是輸出時間概念的引入。該輸出時間是RTI計算出的事件時間戳的最小值。對於處在時間批准狀態的聯邦成員，其輸出時間等於其仿真時間與前瞻量之和。
而在時間推進狀態，對於使用TAR服務的聯邦成員，其輸出時間等於它所發送事件的最小時間戳。對於使用NER服務的聯邦成員，情況要複雜一些。主要是：RTI不能把使用NER服務的聯邦成員的最小時間戳作爲允許其他聯邦成員推進時間的依據，而是使用聯邦成員的輸出時間作爲依據。主要原因是：使用NER服務的聯邦成員一旦發出NER服務請求，其最小時間戳就隨之改變。但RTI最後grant的仿真時間有可能比其最少時間戳小。則如果在發出NER請求到得到grant期間發出的事件，其時間戳可能會比較大。假設其他聯邦成員被允許根據先前的大一些的最小時間戳推進仿真時間。因此，當最小時間戳減小後，就有可能發生接收到過期事件的問題。
因此，RTI對每個聯邦成員都實時計算所有其他時間調節聯邦成員的最小輸出時間，這個最小輸出時間叫做LBTS（時間戳的下限）。 其理解可以是，聯邦成員的LBTS表示聯邦執行的每一刻，該聯邦成員所能收到的事件的最小時間戳。
而使用NER的聯邦成員，在處於時間推進狀態時，其輸出時間是下列幾個值的最小值：1）聯邦成員的請求推進事件與前瞻量之和；2）聯邦成員的事件隊列中最早事件的時間戳；3）聯邦成員的LBTS
則可以對圖5-9解釋如下：第一個事件Manager TAR to t+s發生後，管理者聯邦成員使用TAR請求推進到事件t+s,它進入事件推進狀態，其輸出時間（最小時間戳）改變爲t+s+lookahead；而此時生產者聯邦成員的輸出時間並不增加，處於時間批准狀態。當第二個事件Production NER to t+2s發生後，生產聯邦成員使用NER服務請求推進到t+2s，並進入事件推進狀態。注意，此時，其輸出時間只能增加到t+s+lookahead，也就是其LBTS（生產聯邦成員所能接收到的事件的最小的時間戳 == 管理聯邦成員所能發出的最小的時間戳）和請求時間中的最小值。同時，事件2還同時導致事件3 manager grant to t+s事件的出現，使管理者聯邦成員的仿真時間修改爲t+s.但是其能發出的事件的最小時間戳還是t+s+lookahead。 當事件4 enqueue t+1.5s發生後，管理者聯邦成員發送時間戳爲t+1.5s的事件，該事件進入生產聯邦成員的事件隊列。但是管理者成員的輸出時間並不增加，因爲它的LBTS比事件的時間戳小。當事件5 manager TAR to t+2s發生後，管理者聯邦成員請求推進時間到t+2s,隨之發生幾個事件：1）管理者聯邦成員的輸出時間增加到t+2s+lookahead，生產聯邦成員的LBTS也隨之增加；2）生產聯邦成員的輸出時間增加到其事件隊列中事件所帶的時間戳，這裏就是帶有t+1.5s時間戳的事件。因此該時間戳比它的LBTS小；導致 事件6 Production receive t+1.5s發生。生產聯邦成員在其隊列中接收事件（並進行處理）；生產聯邦成員LBTS的增加還導致 事件7 Production grant to t+1.5s發生，生產者聯邦成員仿真事件增加到t+1.5s
----------------------------------------------------------
5.4 對餐館聯邦實例需求的增加
5.4.1 聯邦與牆鍾時間同步：1）RTI約束所有聯邦成員的仿真時間；2）其中一個聯邦成員根據牆鍾時間的步調推進仿真時間；3）那麼所有的聯邦成員都以牆鍾時間的步調推進仿真時間。
這裏有一個重要假設：即聯邦能比牆鍾事件運行更快。 否則，連RTI也沒有辦法。
這裏的道理和關鍵點是：管理者聯邦成員是以固定的時間間隔發出時間推進請求的，而各批准點的間隔是變化的。管理者聯邦成員休眠相應的時間，以確保能以相同的時間間隔發出推進請求。
這些推進請求通過改變管理者聯邦成員的輸出時間，從而改變其他聯邦成員的LBTS，因此允許其他聯邦成員推進仿真時間。
------------------------------------------------
5.4.2 觀察餐館聯邦的運行 -- 引入一個特殊的聯邦成員--觀察者聯邦成員，其作用就是直觀地表現其他所有聯邦成員的行爲。
觀察者聯邦成員的主要任務：1）獲取它所需要的所有數據；2）與其他聯邦成員保持同步，但不影響其他聯邦成員的時間推進；3）把數據更新轉變爲顯示更新。
觀察者聯邦成員如何及時減小數據更新與顯示更新間的差異？在一個時間推進循環週期內到達的所有新的參數值將外推到進行顯示更新那一時刻的值。即通過擬合等預測顯示更新那一時刻的值。
