使用基于模型的設計來開發和驗證安全關鍵系統軟件
發布時間:2007/8/28 0:00:00 訪問次數:520
本文描述了高度完整性代碼的開發和測試技術,并顯示如何在模型級上應用和自動化來提高嵌入系統的質量同時縮短開發周期。
開發用于航空、汽車、軌道交通和其他行業中的安全關鍵系統軟件的要求相當嚴格,開發者通常使用自我保護的編程技術來確保系統具有容錯能力,并使軟件能在出現未預料到的情況下繼續工作。因此,首先實現可靠的驗證和確認策略來減少故障進入系統的可能性同樣重要。
這個額外步驟要求需要增加開發成本。行業報告顯示,用在安全關鍵系統的驗證和確認過程的成本和工作常常超過開發整個系統的一半,基于手工編程和紙上規范的傳統方法的這個問題更嚴重。使用Ada、C或Fortran開發模型不僅代碼冗長而且代碼可能有錯誤,在不同設計階段重新利用模型時可能產生不經意的改變而導致不正確的結果。類似地,在團隊間頻繁用于交流的需求、規范、測試和其它內容的文檔可能引起歧義和誤解。
通過使用基于模型的設計和集成開發環境,如MathWorks公司的Simulink產品系列,工程師能使開發和驗證自動化,減少費用和降低錯誤。
在基于模型的設計中,從通過建模和仿真來獲得需求到設計實現和測試,系統模型是開發過程的核心。模型是在整個開發過程中不斷細化的可執行規范,與寫在紙上的規范相比,可執行的規范能使系統工程師更深入了解他們策略的動態表現。在開始編碼之前的很長時間就對模型進行測試,確保規范的完整性和無歧義。自動代碼生成避免了手工拼寫錯誤和對設計的誤解,同時自動化的驗證和確認讓測試工程師開發完整的、基于需求并可在自動產生的代碼上重用的測試用例(test case)。
建模和仿真
開發工作從由結構框圖和狀態機組成的控制算法模型開始,每一個框圖和狀態機都具有特別的實時執行特性。算法模型結合周邊部件,如傳感器、執行器(actuator)、機械設備、電子單元和其它與控制算法有相互影響的物理元件,產生一個系統模型。
例如,顯示在圖1中的車輛故障檢測、隔離和恢復(FDIR)應用的系統模型,包括了FDIR邏輯模型、工作模式邏輯、控制規則、執行器模型、被控對象(車輛動力學和大氣作用)、信號調理和插入故障的方法。一個設置故障的圖形界面讓開發者了解系統正常和故障下的行為。
模型風格的指導方針
模型風格指導方針使從系統規范到嵌入代碼產生的轉化變得簡單有效。對于編碼標準,生產單位通常建立他們自己的模型指導方針,準備用來產生嵌入代碼模型的步驟。
在建立這些標準時,回顧一下已發布的模型和代碼的指導方針和標準很有用。在一些組織,如MathWorks汽車咨詢部(MAAB)和發動機工業軟件可靠性聯合會(MISRA),已存在著指導方針,這些方針一般集中在安全性、一致性和簡潔性。
圖1:故障檢測、隔離和恢復模型。
MAAB建立于1988年,開始是協調包括福特、Daimler Benz(現在DaimlerChrysler)和豐田客戶間產品特征要求,現在MAAB把對象擴展到世界范圍,包括大多數主要的OEM廠商和供應商。MAAB的一個重大成果就是建立了一系列公開、可用的建模風格指導方針。其中一條MAAB規則規定了控制器模型必須只能使用離散模塊,因為連續模塊不能更貼切地表示控制器的實現方式而不允許使用。
MISRA的《在車輛中用C語言編制軟件的指導方針》(MISRA-C),于1998年4月發布,2004年十月更新,提供了安全相關的汽車嵌入系統的C語言編程指導。使用C語言開發電控單元軟件的汽車工業開發者創建了其中很大的部分。
雖然MISRA-C不是為自動代碼生成而定制的,其規則關注于C語言編譯器的可移植性,對于手工開發和自動產生的代碼是一致的。下面就是一個規則例子:
MISRA規則11(必要的):內部和外部標識符應該不超過31個有效字符。此外,應該檢查編譯器/連接器來確保31個字符串有意義,并支持外部標識符的大小寫敏感特性。這個規則很重要,可以避免有長名字的標識符間的名字沖突。這個規則已可使代碼更有可移植性,因為大多數編譯器和連接器支持至少31個有效字符。
在自動產生的代碼中,標識符在模型中標明。盡管MISRA-C給出的是編碼風格指導方針,但它可以幫助在建模風格指導方針中包含相應的規則,因為模型是代碼發生器的輸入。MathWorks為它的嵌入代碼發生器-Real-Time Workshop Embedded Coder提供一個MISRA-C分析包。另外,最近MISRA建立了一個工作組來檢查自動代碼生成。
模型檢查器
明確的指導方針和標準使軟件開發者編寫可以系統地檢查對這些方針的符合性的腳本,所以建模環境必須提供每一個在設計中使用的圖形特征和參數相對應的API。然后它直接用來開發系統檢查規則,如限制標識符名字長度的工具。
在Simulink中的Model Advisor識別模型中那些阻止嵌入系統開發和限制代碼效率的部分。這個工具幫助開發者準備一個用來生成代碼的模型,通過分析模型或模塊級別上的配置,給出在每個領域查找結果并提出改進建議的報告。在設計周期早期它特別有用
本文描述了高度完整性代碼的開發和測試技術,并顯示如何在模型級上應用和自動化來提高嵌入系統的質量同時縮短開發周期。
開發用于航空、汽車、軌道交通和其他行業中的安全關鍵系統軟件的要求相當嚴格,開發者通常使用自我保護的編程技術來確保系統具有容錯能力,并使軟件能在出現未預料到的情況下繼續工作。因此,首先實現可靠的驗證和確認策略來減少故障進入系統的可能性同樣重要。
這個額外步驟要求需要增加開發成本。行業報告顯示,用在安全關鍵系統的驗證和確認過程的成本和工作常常超過開發整個系統的一半,基于手工編程和紙上規范的傳統方法的這個問題更嚴重。使用Ada、C或Fortran開發模型不僅代碼冗長而且代碼可能有錯誤,在不同設計階段重新利用模型時可能產生不經意的改變而導致不正確的結果。類似地,在團隊間頻繁用于交流的需求、規范、測試和其它內容的文檔可能引起歧義和誤解。
通過使用基于模型的設計和集成開發環境,如MathWorks公司的Simulink產品系列,工程師能使開發和驗證自動化,減少費用和降低錯誤。
在基于模型的設計中,從通過建模和仿真來獲得需求到設計實現和測試,系統模型是開發過程的核心。模型是在整個開發過程中不斷細化的可執行規范,與寫在紙上的規范相比,可執行的規范能使系統工程師更深入了解他們策略的動態表現。在開始編碼之前的很長時間就對模型進行測試,確保規范的完整性和無歧義。自動代碼生成避免了手工拼寫錯誤和對設計的誤解,同時自動化的驗證和確認讓測試工程師開發完整的、基于需求并可在自動產生的代碼上重用的測試用例(test case)。
建模和仿真
開發工作從由結構框圖和狀態機組成的控制算法模型開始,每一個框圖和狀態機都具有特別的實時執行特性。算法模型結合周邊部件,如傳感器、執行器(actuator)、機械設備、電子單元和其它與控制算法有相互影響的物理元件,產生一個系統模型。
例如,顯示在圖1中的車輛故障檢測、隔離和恢復(FDIR)應用的系統模型,包括了FDIR邏輯模型、工作模式邏輯、控制規則、執行器模型、被控對象(車輛動力學和大氣作用)、信號調理和插入故障的方法。一個設置故障的圖形界面讓開發者了解系統正常和故障下的行為。
模型風格的指導方針
模型風格指導方針使從系統規范到嵌入代碼產生的轉化變得簡單有效。對于編碼標準,生產單位通常建立他們自己的模型指導方針,準備用來產生嵌入代碼模型的步驟。
在建立這些標準時,回顧一下已發布的模型和代碼的指導方針和標準很有用。在一些組織,如MathWorks汽車咨詢部(MAAB)和發動機工業軟件可靠性聯合會(MISRA),已存在著指導方針,這些方針一般集中在安全性、一致性和簡潔性。
圖1:故障檢測、隔離和恢復模型。
MAAB建立于1988年,開始是協調包括福特、Daimler Benz(現在DaimlerChrysler)和豐田客戶間產品特征要求,現在MAAB把對象擴展到世界范圍,包括大多數主要的OEM廠商和供應商。MAAB的一個重大成果就是建立了一系列公開、可用的建模風格指導方針。其中一條MAAB規則規定了控制器模型必須只能使用離散模塊,因為連續模塊不能更貼切地表示控制器的實現方式而不允許使用。
MISRA的《在車輛中用C語言編制軟件的指導方針》(MISRA-C),于1998年4月發布,2004年十月更新,提供了安全相關的汽車嵌入系統的C語言編程指導。使用C語言開發電控單元軟件的汽車工業開發者創建了其中很大的部分。
雖然MISRA-C不是為自動代碼生成而定制的,其規則關注于C語言編譯器的可移植性,對于手工開發和自動產生的代碼是一致的。下面就是一個規則例子:
MISRA規則11(必要的):內部和外部標識符應該不超過31個有效字符。此外,應該檢查編譯器/連接器來確保31個字符串有意義,并支持外部標識符的大小寫敏感特性。這個規則很重要,可以避免有長名字的標識符間的名字沖突。這個規則已可使代碼更有可移植性,因為大多數編譯器和連接器支持至少31個有效字符。
在自動產生的代碼中,標識符在模型中標明。盡管MISRA-C給出的是編碼風格指導方針,但它可以幫助在建模風格指導方針中包含相應的規則,因為模型是代碼發生器的輸入。MathWorks為它的嵌入代碼發生器-Real-Time Workshop Embedded Coder提供一個MISRA-C分析包。另外,最近MISRA建立了一個工作組來檢查自動代碼生成。
模型檢查器
明確的指導方針和標準使軟件開發者編寫可以系統地檢查對這些方針的符合性的腳本,所以建模環境必須提供每一個在設計中使用的圖形特征和參數相對應的API。然后它直接用來開發系統檢查規則,如限制標識符名字長度的工具。
在Simulink中的Model Advisor識別模型中那些阻止嵌入系統開發和限制代碼效率的部分。這個工具幫助開發者準備一個用來生成代碼的模型,通過分析模型或模塊級別上的配置,給出在每個領域查找結果并提出改進建議的報告。在設計周期早期它特別有用
上一篇:Java的線程機制