|
2007年5月，超過200位開發者在斯圖加特匯聚一堂，參加了由Vector Informatik公司主辦的FlexRay大會。會上，汽車OEM和供應商展示了他們現在取得的成就、在系統集成方面的經驗和針對未來的實現理念。 很久以前CAN總線就遭遇了本身的局限性。現代汽車電子架構需要不斷地擴大網絡化。只有提供更大的傳輸容量，日益加快的控制算法付諸實施時才會產生效果。很多車型在開始生產時就已經達到了最大的總線負載，而沒有預留任何帶寬。總線系統的數量加倍無論如何都不會使數據速率加倍。為系統聯網而增加的必要的網關，不僅使系統變得錯綜復雜，而且可能產生不可接受的報文傳輸延遲。更要命的是，缺乏確定性成為了安全關鍵應用的絆腳石。 在發展過程中，CAN不能滿足汽車中逐漸增長的數據傳輸要求，這導致了FlexRay串行總線系統的發展。去年底，BMW展示了首個FlexRay產品級應用。Vector Informatik公司在那時舉行FlexRay大會正是總結新協議應用經驗和挑戰的好時機。在BMW X5車上使用FlexRay完成減震器控制系統從兩方面來講都是一項“時間關鍵”工程，這讓項目參與者面臨考驗。不僅半導體產品和軟件組件需要按時生產出來，而且面對這樣一項艱巨的工程，其開發流程也必須要很快地適應現有的結構并能正確運轉。在這里需要得到供應商的支持�！霸贐MW我們不能只為了FlexRay而開發一套新的流程”，BMW AG的網絡技術組帶頭人Anton Schedl博士如此表示，“因此我們有意識地決定選取了一種相對簡單的應用，這樣可以根據已有經驗、使用較短的協調和決策路徑迅速實現改造�！� Schedl博士認為，在合適的時間有可用的半導體是這項試驗性項目的最大挑戰。得益于OEM和半導體供應商共同做出的積極承諾，這一目標有可能會按期完成。 萬事開頭難 盡管啟動每個新系統必然會很困難，但是不同的部件還是比較快地集成到了一起�！皶r間觸發通信是將不同供應商的部件和軟件代碼集成起來的理想平臺”，在Robert Bosch公司汽車網絡部門工作的Florian Hartwich說。他還協助FlexRay協會制定協議，之前參與了CAN和TTCAN的開發和標準化工作。因為每個應用系統都在預先規定的時刻發送報文并且知道該在何時接收何報文，所以在之后可以更為容易地將部件加入到分布式系統中。 最重要的工作需要在FlexRay系統開發一啟動時就進行。所有的系統描述參數——比如波特率、循環時間、時隙數目、時隙長度以及靜態段和動態段的報文分配——都在開始時定義。因為確定的時隙是分配給發送任務的，所以在工程定義過程中就必須明確如何組織報文的時隙分配、哪些應用系統可能最適合提到動態事件驅動段以及應該為后續車型系列的應用系統預留多少時隙等，參考圖1。 在分布式系統中保持整體觀特別重要。在一開始，網絡設計者往往不知道真實應用軟件隨后是如何進行實際通信的，也不清楚它們的執行時間。另一方面，ECU開發者習慣于只關注開發應用程序，而不怎么關心整個FlexRay通信過程的時間狀況。但是，一個循環內的FlexRay數據必須保持一致，并且時間觸發型總線的應用程序也必須保證一直同步。 因此，Hartwich留意了那些可能引起數據不一致的問題。比如，必須避免在發送過程中更新發送數據，這會導致在同一幀中同時包含新舊數據。BMW使用所謂的“信號窗口”解決了這一問題，它保證任務僅在該專用窗口中發送報文。這種方法的另一個好處是應用程序與通信分離：如果通信調度發生了改變，那么不會影響應用程序。 在實時系統中，任務同步是一項必須引起特別關注的關鍵特性�！罢{度表的正確同步問題至關重要”，Winfried Janz解釋道，他是Vector公司OSEK實時操作系統開發項目的帶頭人兼產品經理。在關于OSEKtime和AUTOSAR操作系統的演講中，他論述了如何按照規范使調度表與全局時間同步（參考圖2）。選擇硬同步（調度表跳轉到一個預定義的執行點或者暫時停止了）還是軟同步（在每個到期時刻進行時間調整，但是這些時刻的分配是無規律的，會導致一些無規律的時間調整行為）取決于應用程序是否容忍跳轉和暫停。 圖2：調度表狀態圖顯示了同步是如何實現的。調度被啟動，但不必立即完全同步（RUNNING）。為實現同步運行（AND SYNCHRONOUS），可以進入等待狀態（SHEDULETABLE_WAITING）或者進行軟同步。 在開發階段，監視同步和數據一致性由軟件工具來完成。“我們必須做到同步地處理模型，否則就會丟失數據”，當Carsten B?ke博士解釋Vector的工具CANoe時他這樣說道。B?ke演示了CANoe提供的確保同步和檢測不一致數據的機制。CANoe運行模型的主要體系結構基于一種使用所謂“通知句柄”的通知概念。它包括了接收到消息時的模型激活、定時器到期時的處理和錯誤狀態的檢測。尤其是，這種概念針對FlexRay作了擴展，包含了在FlexRay循環的特定時刻進行的同步通知，如圖3所示。另外，B?ke演示了一種運行CANoe RT、具有特定硬件支持的優化平臺，該平臺是為了滿足FlexRay系統嚴格的時間要求而定制的，比較適合中小尺寸的硬件在回路仿真。 圖3：在CANoe中，可以參照循環開始或特定時隙的結束有規律地執行動作。當然，通知也可以發生在總線上接收到幀或丟幀的時候。 FlexRay與AUTOSAR “為將來做準備，必須按照AUTOSAR標準設計新的軟件概念”，負責FlexRay基礎軟件開發的Dirk Gro?mann說。因為Vector Informatik公司是AUTOSAR協會的成員，所以該協會的成果和結論很快就在Vector的FlexRay開發中得到了實踐，如圖4所示。Vector的FlexRay接口和FlexRay driver已經符合AUTOSAR標準了，因而可以在今天不用依賴于以后特定的應用程序而開發這些組件，而且這些組件可以靈活地適合不同的車型和平臺。FlexRay driver對通信控制器進行了抽象，而FlexRay接口提供了針對和FlexRay調度表無關的單個PDU（協議數據單元）的訪問入口。 此外，Vector提供符合AUTOSAR標準的網絡管理和傳輸協議實現。作為對AUTOSAR的補充，可以將XCP協議集成到FlexRay棧中。Gro?mann還談到通過FlexRay進行flash編程的可能性：“一種方案是完全交換協議并且使用單獨的調度表進行flash編程�！� Oliver Kitt在其演講中更為深入地論述了使用XCP（由ASAM標準化的一種標定協議）標定ECU的話題。在Vector公司，他負責測量、標定和診斷工具CANape的硬件接口集成工作。XCP中的“X”表示不同的傳輸層，比如它可以表示XCP-on-CAN、XCP-on-Ethernet以及2006年2月發布的XCP-on-FlexRay等。這是一種單主/多從概念，可以非常高效地與ECU通信并且使用可變帶寬進行測量和標定�？梢詫lave集成到FlexRay棧中，而由工具來提供對協議master功能的支持。在運行時刻根據需要為單個節點重新分配帶寬。有必要使用一種增強版FlexRay driver來實現XCP-on-FlexRay的buffer重配置。這也展示出組件的靈活操作。 圖4：符合AUTOSAR標準的FlexRay軟件方案可靈活地適應不同的需求。該圖展示了一種帶有driver（相對于AUTOSAR進行了擴展并增加了XCP傳輸層和協議模塊）的FlexRay棧。 FlexRay協議規范的編輯，在Freescale公司負責FlexRay相關工作的Mathias Rausch博士（工程學），闡述了buffer結構是如何影響整個系統的。Rausch詳細描述了配置不同的靜態或動態段時優化buffer存放的方法。另外，Freescale利用了FlexRay協議中沒有詳細規定控制器主機接口（CHI）、僅規定最低需求作為約束條件的實際情況。這給了半導體廠商提供特殊功能的自由。CHI的優化設計使隨后的軟件更容易構造。Rausch建議使用工具，因為“配置多達128個消息buffer時需要考慮很多參數”。 在Schedl博士的請求下，NXP半導體公司汽車商務領域創新和發展管理主管Patrick Heuts先生挑選出了更為經濟的FlexRay組件�！俺�收發器，我們也提供FlexRay控制器，它是完全集成在MCU中的，是一種單片機方案。相比較那種通常作為外圍設備嵌入到MCU中的FlexRay控制器，這種完全集成的方案具有明顯的優勢。比如，消息buffer的數量和類型可以靈活配置。事實上，完全集成的FlexRay控制器工作起來更像一種具有一個或兩個通道的DMA工具。NXP半導體公司的下一步計劃是研究在片上集成收發器是否可以進一步降低系統的成本”。參考圖5。 圖5：NXP半導體公司提供了“MCU中心”解決方案，其優點是在MCU中完全集成了FlexRay控制器。 盡管宣稱的目標之一是“降低成本”，FlexRay系統已經不再比相似的CAN架構貴多少了。因為需要增加必要的硅片，FlexRay的芯片成本要高于CAN。但是，BMW的內部研究表明，整個系統的成本是非常接近的，而且還獲得了更高的性能和可擴充性以及更低的復雜度。 結論 FlexRay有很多潛力。BMW的試驗性項目還僅僅是開始，它證明了FlexRay系統“一旦正確建立”就可以穩定地運行。強烈建議在不同的開發階段選擇通用工具，以便保持對眾多不同需求的清晰的整體觀。具有擴展檢查系統的工具簡化了開發者的工作并且從一開始就能幫助預防錯誤。由于FlexRay，很快就會出現大量的計算機通信應用軟件。 |
