采用模型驅動的設計方法 ， 在研究了平面型網絡體系結構 、快車道和慢車道 、嵌入式通信網絡參 考模型的基礎上 ， 完成 WTB協議棧的軟件結構 設計 ， 劃 分了功能性模塊和非功能性模 塊 ， 對 WTB 初運行模塊 進行了控制平面和數據平面劃分 ， 指出了并行工作需求 、是否包括定時器 、任務切換的系統開銷是否可 以忍受 、可移植性等是模塊實現方式選擇的重要因素 ， 最后給出了各任務的優先級 。

　　WTB （ Wire Train Bus ， 絞 線 式 列 車 總 線） 是 IEC61375- 1 定義的列車 總線協議 〔1〕 ， 也是 TB/ T3035 - 2002推薦的車輛間通信協議 〔2〕。該總線源于西門子的 DIN43322 和意大利 CD450〔3〕。該總線的設計目標有 3 個 ： 提供實時可靠的數據傳輸服務 ， 能夠適應列車編組變化并自動識別車輛在列車中的位置和方向 ， 不同制造商生產的車輛可互操作 。WTB 在屏蔽雙絞線上的傳輸速率為 1 Mb/ s， 32 個節點 ， 傳輸距離可達 860 m 〔1〕。WTB 傳輸的數據分為兩類 ， 一類是實時過程數據 ， 另一類是按需發送的非實時消息報文 ， WTB 通過主節點控制下的周期性輪詢方式實現過程數據硬實時傳輸 ， 在每個周期的空閑時間按需傳輸消息報文或監視數據 。開發 WTB 協議棧 ， 選擇合適的方法是首先要考慮的問題 。而對于軟件結構設計 ， 有兩種途徑 ： 需求驅動和模型驅動 。需求驅動開發方法按需求分解系統的功能 ， 同時將系統分成物理組件 ， 然后將功能分配到物理組件中 ， 這些物理組件最終被集成起來 。采取這樣的開發方法有一個前提 ， 即在開發前充分的理解需求 ， 而在現實世界中 ， 是很難做到的 。采取這樣的開發方法 ， 還需要較早的將功能分配到物理組件中 ， 隨著開發的深入 ， 功能需要被分配到更低層次的物理組件中 ， 有可能單個功能被分配到多個物理組件中 ， 這個分配過程可能形成數百上千的多對多決策樹 。現有的開發方法缺乏相關指南 ， 指導如何進行這種分配 ， 如何分析平衡優化 。對于 WTB 來講 ， IEC61375對協議做了規范 ， 但作為產品需求 ， 還不夠完整 。因此 ， 從分解產品需求入手 ， 不如從建立產品的通用結構入手 。而且 ， 模塊化過程是 EN50128對鐵路電子產品軟件開發的要求之一 。模塊化過程有兩個重要方向 ： 一個是建立通用的體系結構 ， 另一個是模塊抽象化 。前者重點解決模塊如何劃分 ， 后者重點解決模塊如何復用 。本文重點研究如何設計 WTB 協議棧的軟件結構 ， 并給出具體實現 。