帳號:
密碼:
CTIMES / 文章 /   
以模型化基礎設計流程開發測試AUTOSAR軟體元件與複雜裝置驅動
 

【作者: Enric Valencia、Joan Albesa】   2019年09月25日 星期三

瀏覽人次:【1262】
  

AUTOSAR現在已成為車用軟體的設計與實現的產業實際標準(de facto industry standard)。有鑑於AUTOSAR的開放、標準化的軟體架構能幫助OEMs與供應商們在專案上進行合作,因為大部分的應用邏輯可以實現在應用層內的軟體元件(software components,SW-C)上,並與標準的運行環境層(run-time environment,RTE)介接,而不是在ECU硬體上實現(圖1)。



圖1 : AUTOSAR軟體架構
圖1 : AUTOSAR軟體架構

當我們團隊進行的某些AUTOSAR專案,其中一組須在RTE上層的應用層執行SW-C,而其他專案可能會需要通過在RTE層內運作的複雜裝置驅動(complex device driver,CDD),直接介接到ECU微控制器。


從過往歷史來看,CDD的開發代表著更大的工程挑戰,因為CDD的程式碼除了必須與RTE互動之外,還需要與RTE下層的基礎軟體(basic software,BSW)層互動。


我們使用模型化基礎設計(Model-Based Design)來進行SW-C的開發已經有一段時間了。模型化基礎設計支援了完善且成熟的工作流程,在這裡面,由AUTOSAR認可編寫工具產生的軟體元件描述ARXML檔案被用來建立初步的Simulink設計呈現。我們最近和MathWorks進行顧問服務專案合作,將我們在這方面的能力擴展至CDD開發。現在,與其用人工手動編寫CDD軟體程式碼,我們改採用模型化基礎設計來進行SW-C和CDD的開發。


使用相同的工作流程和工具組進行兩種不同型態的AUTOSAR軟體開發,不僅能降低成本、訓練時間、和花在其上的經常性維護資源,也讓我們能夠很容易地在SW-C和CDD團隊之間進行工程師的調度。更重要的是,使用模型化基礎設計於所有AUTOSAR專案,我們已縮短了至少50%開發時間,同時在設計早期階段能夠發現的設計瑕疵數量也增加了,且在硬體測試階段之後所發現的瑕疵數量也因此減少。


一個由上而下的元件設計方法

利用AUTOSAR編寫工具-DaVinci Developer,我們定義出軟體元件架構及介面,接著匯出軟體元件描述的ARXML檔。接下來,我們採取由上而下的開發方法,將這些檔案匯入至Simulink中,建立一個包含所有如同在DaVinci Developer定義的介面設置的骨幹模型。


我們以這個骨幹模型作為基礎,在Stateflow中建立應用控制邏輯的模型和進行模擬(圖2)。把Simulink模型中的元素連結到相關的設計規格,該設計規格係由IBMR Rational DOORS進行管理。這種方法能夠建立可追蹤性,能夠支援衝擊分析(impact analysis)和認證所需要的文件活動。



圖2 : (上)骨幹模型;(下)完整的模型。
圖2 : (上)骨幹模型;(下)完整的模型。

程式碼生成與驗證

在執行模擬來檢查初始的設計之後,我們會執行正式的測試。從前,若單單只用MATLABR程式腳本作為AUTOSAR專案的驗證套件,雖然這一個內部的架構能夠良好地運作,不過仍會需要花費相當大的心力來開發和維護。


現在透過MathWorks顧問的協助,我們評估以Simulink測試工具箱(Simulink Test?)作為另一種設計選擇,我們發現,Simulink測試工具箱不但提供了和MATLAB程式腳本相同的測試功能,還能減輕維護上的負擔。


我們現在利用Simulink測試工具箱來定義測試套件及測試案例,並且將產生測試器具的過程自動化(圖3)。首先執行基礎測試,在這裡將模擬結果與期望的結果作比較。但是,仍然會執行搭配軟體迴圈(software-in-the-loop,SIL)版本模型的等效測試來做進一步的驗證。



圖3 : 透過Simulink測試工具箱產生的測試器具樣本。
圖3 : 透過Simulink測試工具箱產生的測試器具樣本。

接下來執行的以模擬為基礎的測試,我們會透過嵌入式程式碼轉碼器(Embedded Coder)從我們的模型產生符合MISRAR的C程式碼。所產生出來的是已經準備好、且可在目標硬體RenesasR微控制器上使用的程式碼,而且不需要任何的後處理。作為驗證流程的一部分,我們會利用PolyspaceR靜態和動態的程式碼分析工具收集程式碼度量,並且檢查是否出現除以零、溢出、以及其他執行階段錯誤。


開發時間更短、品質改善、還有其他優勢

使用模型化基礎設計來進行AUTOSAR CDDs和SW-Cs的開發,對我們帶來顯著的改善,從而為IDNEO公司的事業各方面帶來很大的商機,例如與客戶的合作。如果我們的客戶也在使用Simulink,我們可以直接透過模型來合作,這樣能夠消除自然語言既定會存在的模棱兩可,而且可以將開發時間縮短至一半。


除此之外,當具備使用模型化基礎設計來開發CDDs的能力,而不是以人工撰寫程式碼來開發,我們能夠有更大的彈性去符合客戶的需求,因為我們可以視特定的使用案例來決定要單獨使用SW-C、CDD,或者兩起一起使用來進行功能的實現。


有的時候,客戶提供已開發的AUTOSAR元件給我們,並且希望我們可以把這些元件整合至更大的系統,而這個系統可能還包含其他第三方元件。在這種情況,我們使用元件介面的ARXML定義來簡化整合的流程,也讓開發時間縮短了70%。


比起以往領域相似、但未使用AUTOSAR和模型化基礎設計的專案,現在我們產品開發到上市的時間縮短了許多—以某些例子來說,可從一年縮短為六個月。此外,我們可以更早偵測到錯誤,讓我們可以在設計階段找出並修正80%的錯誤,而不是到了硬體測試階段才發現。


我們現在準備要更精煉模型化基礎設計的工作流程,藉由持續的整合與採用最佳實踐方式,讓此工作流程變得更為敏捷。我們在將Polyspace測試合併到Jenkins持續整合(continuous integration,CI)中獲得很大的進展,未來也計畫要在近期之內將測試套件從Simulink測式工具箱整合至我們的Jenkins CI管道。


(本文由鈦思科技提供;作者Enric Valencia、Joan Albesa任職於IDNEO公司)


相關文章
以模型化基礎設計混合訊號多波束聲納系統
預認證互聯簡化IoT應用
強化學習:入門指南
透過Simulink將模擬資料視覺化
如何利用數位分身進行預測性維護
comments powered by Disqus
相關討論
  相關新聞
» 南樺發表Line警報器解決方案 協助提升製造業擴廠彈性
» NexCOBOT結合AWS雲平台服務 簡化智慧機器人開發及部署流程
» 產學合作創益加乘 群聚力打造科技生態鏈
» 金屬中心協同搬運模組 實現智慧工廠搬運效益
» 強化物聯網與工業設備效能 ST推出高效能MPU
  相關產品
» Fluke首款可攜式口袋熱像儀上市
» Fluke首款工業聲學成像儀ii900上市
» Fluke四款640 x 480解析度熱像儀齊登場
» 明緯擴充EPP-500系列
» KNX用於現代建築 可降低事後維護與火災風險

AD


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2019 遠播資訊股份有限公司版權所有 Powered by O3
地址:台北市中山北路三段29號11樓 / 電話 (02)2585-5526 / E-Mail: webmaster@ctimes.com.tw