王海濱,周宇星,朱明,張元才
(上海汽車集團股份有限公司 技術(shù)中心,上海201804)
在現(xiàn)代的汽車電子控制器開發(fā)中,普遍采用了國際知名供應商開發(fā)的硬件控制器和包括Bootloader、符合OSEK標準的實時操作系統(tǒng),以及底層硬件驅(qū)動等底層軟件,并提供相應的軟件接口層給上層控制策略應用軟件。但根據(jù)底層軟件因不同的硬件設計而不同的特點,以及考慮到代碼執(zhí)行效率的原因,多采用定點手寫代碼來完成。
而隨著微電子技術(shù)的不斷進步和電子芯片價格的不斷下降,越來越多的控制器已支持32位帶浮點數(shù)運算單元的解決方案,這就為基于模型的控制算法的開發(fā)提供了廣闊空間。
在最新的ISO 26262(汽車行業(yè)功能安全標準)中對控制器的三層安全架構(gòu)要求如下:
①Level1實現(xiàn)動力系統(tǒng)管理功能,如轉(zhuǎn)換動力系統(tǒng)請求扭矩、零部件監(jiān)控、輸入/輸出變量診斷及在錯誤確認時控制系統(tǒng)響應。
②Level2負責監(jiān)控Level1功能軟件缺陷,如監(jiān)控計算的扭矩值或車輛的加速度值,如果檢測到此類錯誤將觸發(fā)系統(tǒng)錯誤。
③Level3監(jiān)控模塊獨立于Level2和Level1,通過應答機制監(jiān)控Level2和Level1層軟件是否正常運行,如錯誤發(fā)生將觸發(fā)獨立于功能控制器的系統(tǒng)錯誤。
根據(jù)ISO 26262三層安全架構(gòu)的闡述,第二層負責監(jiān)控第一層與安全相關(guān)的功能,與安全相關(guān)的輸入變量的值在被第一層軟件讀取的同時也要被第二層監(jiān)控軟件讀取,且要有冗余備份。例如,通過監(jiān)控計算的或車輛加速時的扭矩輸出,當?shù)诙颖O(jiān)控模塊計算扭矩與第一層功能層計算扭矩不一致時,會引起控制系統(tǒng)故障響應。
根據(jù)以上安全相關(guān)需求,在設計扭矩監(jiān)控模塊TQM時,極大地提高了對參與計算的輸入/輸出變量的安全性的要求,由此引入了安全內(nèi)存(Safety RAM)。下面首先介紹底層軟件中基于定點數(shù)的安全內(nèi)存的實現(xiàn)原理。
與安全有關(guān)的RAM 中的數(shù)據(jù)在防止信息丟失、讀寫能力的保護等方面需要額外的保護。基于這個原因,將雙倍的RAM 內(nèi)存區(qū)用于軟件比較和讀/寫測試可大幅提高數(shù)據(jù)的安全性。地址空間在兩個內(nèi)存區(qū)域復制,原始數(shù)據(jù)存儲在第一個內(nèi)存區(qū)域,第二個內(nèi)存包含補充信息,將與第一塊內(nèi)存區(qū)并行訪問。在輸出時比較兩塊內(nèi)存的數(shù)值,如果發(fā)現(xiàn)任何偏差,會產(chǎn)生一個復位。為了檢測特定類型的位錯誤,在第二個內(nèi)存區(qū)域的數(shù)據(jù)存儲采用二進制補碼的形式。一般安全內(nèi)存支持訪問下列類型:不受中斷保護的訪問類型、寫入或讀取的安全內(nèi)存數(shù)據(jù)、中斷保護的訪問類型。需要寫入或讀取相關(guān)數(shù)據(jù)的安全保護。
在當前的底層,基于定點數(shù)接口說明如下:存儲到安全內(nèi)存區(qū)變量定義,分為變量的源地址定義與補碼地址定義,分別存放在兩處非相鄰內(nèi)存區(qū);讀取存儲在安全內(nèi)存區(qū)的變量參與邏輯運算的接口RdSafetyRam32(&Var),當這個接口被調(diào)用時與存儲在源碼區(qū)與補碼區(qū)的值進行比較,如發(fā)現(xiàn)任何不一致將導致系統(tǒng)錯誤發(fā)生;存儲變量到安全內(nèi)存區(qū)接口函數(shù)為WrSafetyRam32(&Var,com_var),通用內(nèi)存區(qū)變量com_var的當前值將分別存放到Safety RAM 區(qū)變量var的源碼地址區(qū)和補碼地址區(qū)。
在關(guān)于安全內(nèi)存典型應用的示例中,Var1為定義到安全內(nèi)存區(qū)的變量,同時在安全內(nèi)存補碼區(qū)定義了相同變量名,即用后綴Cpl加以區(qū)分的補碼。RdSaftyRam32(&Var)和WrSafetyRam32(&Var,Common_Var)兩個函數(shù)分別為讀32位變量和寫32位變量的接口函數(shù)。在讀寫兩個函數(shù)中完成變量Var的源碼與補碼的效驗以確保示例中變量Var1的安全,從而提高整個扭矩監(jiān)控算法的安全等級。
目前的實際情況是,底層軟件提供的接口API函數(shù)只支持uint8、uint16、uint32三種數(shù)據(jù)類型,對于定點數(shù)的操作完全沒有問題。可是對于基于Simulink模型生成的基于浮點數(shù)的C代碼,主要應用single的數(shù)據(jù)類型就沒有辦法直接應用安全內(nèi)存的接口函數(shù)了,以下是針對這個問題的幾個解決方案的比較。
強制類型轉(zhuǎn)換為:
結(jié)果會導致B精度損失,不能滿足工程需要。
上述代碼對應的Matlab模型如圖1所示。
圖1
該方法通過應用Simulink的S-Function,并通過修改相應的代碼生成時的TLC腳本來實現(xiàn)。利用聯(lián)合體共享數(shù)據(jù)空間的方式來實現(xiàn)浮點數(shù)與定點數(shù)的轉(zhuǎn)換。但使用過程中需要定義大量的聯(lián)合體類型數(shù)據(jù),且這些變量經(jīng)RTW 代碼生成后為全局變量常駐內(nèi)存,占用大量的內(nèi)存空間,且代碼可讀性差,不適合應用于量產(chǎn)控制器中。同時,因為其變量類型定義也不夠靈活,比如定義32位數(shù)據(jù)類型需要定義一個聯(lián)合體,16位和8位數(shù)據(jù)類型則需要重新定義新的聯(lián)合體,給應用Simulink完成算法開發(fā)的工程師帶來不便。
應用Simulink data store、data read、data write修改相應的TLC代碼生成腳本。
代碼對應的Matlab模型如圖2所示。
圖2
對比方案3生成的代碼與安全內(nèi)存接口應用的典型代碼,可以發(fā)現(xiàn)以下優(yōu)點:
典型代碼只能直接讀取uint32類型變量,而由方案3模型生成的代碼首先調(diào)用底層接口函數(shù),驗證定義到安全內(nèi)存區(qū)的變量A 的源碼與二進制補碼是否一致,接下來運用C語言逗號運算法將采用指針取地址的方式把定點數(shù)A 轉(zhuǎn)換成浮點數(shù)賦給變量Val_A。
典型代碼把變量寫入32位的接口時只能接受uint32的數(shù)據(jù)類型,而由方案3模型生成的代碼則是通過指針取地址的方式把浮點數(shù)Val_2轉(zhuǎn)換成定點數(shù)賦值給定義到Safety RAM 區(qū)的變量A,從而保證了變量精度沒有任何損失。
方案3通過修改RTW 的TLC腳本來控制data store、data read、data write生成代碼,從而實現(xiàn)底層定點數(shù)和上層策略浮點數(shù)的結(jié)合,對于開發(fā)控制算法的工程師為透明的。同時,對于模型中用到的數(shù)據(jù)類型無任何限制,可根據(jù)開發(fā)的需要隨意修改,而相對于產(chǎn)生的C 代碼數(shù)據(jù)類型定義,則體現(xiàn)為uint32、uint16、uint8 三種數(shù)據(jù)類型。
方案創(chuàng)新地應用了C語言中的逗號運算符和取地址的方法,解決了數(shù)據(jù)安全性問題,同時在存儲浮點數(shù)到定點數(shù),及讀取定點數(shù)到浮點數(shù)的過程中,變量無任何精度損失,很好地解決了上層基于浮點數(shù)的模型生成代碼和底層基于定點數(shù)接口的結(jié)合問題,更重要的是解決了扭矩監(jiān)控功能模塊的數(shù)據(jù)安全性問題。
該方法對建模工程師和負責底層軟件與上層控制策略模型的工程師均無任何額外工作,提高了工作效率。
目前該方法已在兩個項目中得到應用,并取得了很好的應用效果,可在類似的開發(fā)中借鑒。
越來越多的國內(nèi)OEM 廠商已不滿足完全委托國際知名供應商開發(fā)電子控制系統(tǒng),而是逐漸開始組建開發(fā)團隊開發(fā)控制器的控制策略,同時委托國際知名供應商開發(fā)硬件和底層軟件。但開發(fā)過程中很可能遇到底層軟件提供的接口與上層控制策略模型不匹配的情況,如本文遇到的扭矩監(jiān)控模型生成代碼為浮點數(shù)而底層軟件接口為定點數(shù)的情況。在這種情況下就需要工程師們用創(chuàng)新的方法來解決這一矛盾,以保證后續(xù)開發(fā)得以順利進行。
[1]Brian W Kernighan,Dennis M Ritchie.C程序設計語言[M].北京:機械工業(yè)出版社,2004.
[2]黃永安,馬路,劉慧敏.MATLAB 7.0/Simulink 6.0建模仿真開發(fā)與高級工程應用[M].北京:清華大學出版社,2005.
[3]國際標準組織(ISO).ISO26262 規(guī)范汽車行業(yè)功能安全標準,2010.