基于可視化分析模型的汽車電控系統需求開發方法

韓虎, 呂憲勇, 李云霞, 侯郭順

(濰柴動力股份有限公司內燃機可靠性國家重點實驗室, 濰坊 261061)

在“軟件定義汽車”的時代背景趨勢下,人們對汽車定位逐步由代步工具向智能生活轉變,對汽車體驗的需求呈現多元化和新穎性走勢,汽車電控系統是實現新客戶價值的主要承擔者[1-3]。對日益增加的各種形形色色功能需求,如何對復雜系統需求進行有效開發,是擺在工程開發人員面前一項關鍵和挑戰性的工作。

目前在面對復雜系統需求開發方面的研究已少見報道。文獻[4-6]對需求工程進行了系統性概述,梳理了需求工程的現狀及發展趨勢。文獻[7]對民用飛機復雜航電系統軟件研制過程中的需求不準確問題,提出了一種基于模型的需求開發方法。文獻[8]和文獻[9]在直升機和機載系統上對需求工程進行了研究應用。文獻[10]以安注系統為例,將需求建模方法應用于需求分析,為需求建模在核電設計中的進一步應用提供了參考。文獻[11]提出了一種基于需求驅動的輸變電工程多尺度場景構建方法,并進行了有效驗證。需求開發在各行業都有涉及,旨在為高效需求分析提供一種觀點[12-16]。通過對國內外標準、文獻研究分析,闡述了對需求開發的重要性,但針對如何進行有效需求開發方面,只是從宏觀層面闡述了需求開發基本過程和相應活動,并沒有給出一種可視化的需求開發方法。現結合實際研發項目及能力成熟度模型集成(capability maturity model integration, CMMI)-3等級認證過程的經驗,提出一種基于可視化分析模型的汽車電控系統需求開發方法,旨在解決電控系統需求開發過程中需求描述模糊不清、理解不一致問題,不斷提高需求開發的效率和質量。

1 需求開發的重要性

需求是正向設計的起點,所有產品或項目的開發都是源于客戶需求。根據斯坦迪什集團在歷年的報告數據顯示,如何有效開發項目的需求成了項目成敗與/或項目時間是否超時以及項目預算是否超支的一個重要原因[17]。開發人員對不正確或不完整需求有一種憑借自己的主觀臆斷或潛意識去完成它們的趨勢,從而導致這些錯誤在項目的后期階段或者部署系統時才被發現。不清晰、不完整或者錯誤的需求就不可避免地導致所開發的系統不具備需求所要求的關鍵屬性或者具備需求中未做要求的屬性。

需求是系統開發的基礎。各種類型的需求直接或者間接地影響著分析、設計、實現和測試的階段。一個需求的質量對于項目的進展有著很強的影響,進而決定了項目的成敗。如果需求不能準確地反映出客戶的期望或者說如果沒有一種準確的方式來描述需求從而導致有多重解釋的存在,通常其結果便是所開發出的系統并不能滿足客戶或者用戶的期望[18]。多數的利益相關者對于需求有著錯誤的理解,他們認為需求是不言自明的,已經顯示得很清楚了,并不需要明確地闡述。導致了參與各方因各自經驗和知識背景的差異而在溝通中出現了問題。

需求貫穿于汽車電控系統開發的全生命周期過程中,是電控系統設計方案的基本依據和設計約束,也為系統最終的驗收提供依據,會從頭到尾、從上到下影響整個電控系統開發過程。電控系統需求是模糊的、多變的、主觀的。只有通過電控系統需求工程的活動才能把系統功能和性能的總體概念描述為具體的系統需求規格說明,從而奠定電控系統開發的基礎。它是系統分析和軟硬件設計的橋梁。

2 需求開發內容

需求開發,是對獲取的客戶需要或需求進行詳細的分析、研究,準確地理解客戶內在的期望或目標,去除與需求無關的信息,找出需求間的聯系并解決,確認后形成描述完整、清晰與規范的技術文檔,確定系統必須做什么以及如何執行好。研究待開發的系統在功能上需要“實現什么”,而不考慮具體的實現技術。最終將客戶的非技術性描述轉換成可供開發人員設計解決方案的技術性規格文件。

需求是開發正確電控產品的基礎。需求開發內容如圖1所示,包括:需求獲取、需求分析、需求規格書和需求驗證四部分。這些活動涉及產品需求的開發、評估、記錄和確認。需求獲取是整個汽車電控系統開發工作的第一步,要做好分析與設計,首先要做的事就是對客戶需求進行咨詢和調研,完整、準確地收集和記錄客戶的需求、期望、痛點和難點是正確地進行分析與設計的前提。需求分析要對獲取的每個需求進行深入理解并充分分析,然后將分析出的需求按照規范化的方式表達出來。需求規格說明以一種連貫、結構清晰的方式來表達和存儲獲取到的需求知識。需求驗證是指確認需求信息是正確的,能使開發人員制定出能滿足客戶需求的解決方案。

圖1 需求開發主要內容Fig.1 Requirements development content

在需求開發過程中,會涉及如下工作:獲取、分析、確認和溝通客戶的需求、期望和約束條件;開發產品的生命周期需求;開發操作概念和場景;開發客戶功能和質量屬性需求,包括描述、分解和分配需求到功能。在整個產品生命周期內持續識別和細化需求,確保客戶的需求和期望得到滿足。

3 基于可視化分析模型的需求開發方法

需求開發并不是簡單以一種一次性線性順序來開展此項活動。需求開發所涉及的內容是相互交織、漸進的和迭代式的。在需求開發中,“逐步完善細節”是實施中的關鍵要點,需要從一些原始的需求想法向更精確的理解和表述演進。需求開發關注的是用戶需要系統做什么以及系統必須具有什么功能,而不是應該如何實現系統。需求開發最困難的部分是準確判斷開發什么以及如何將客戶需求轉換成可驗證的詳細的技術需求,保證其一致性和完整性。

人類認知的研究表明,使用圖形而并非自然語言,可以使人類更好和更快地感知以及記憶事物[19]。與自然語言相比較,使用模型的另外一個優點是所使用的建模語言有著嚴格定義的聚焦點。模型也有一個優點,那就是在相同的建模語言中的不同建模元素規定了抽象的方法以及什么要被抽象和什么不要。模型的創建本質上是描述性和說明性的。模型是對現存的或者將要創建的現實事物的抽象表達。模型具有三個重要的特性:現實的映射、現實的縮小、實用屬性(通常為一個特定的目的以及在特定的上下文中構造一個模型)。

基于文本的需求開發方法會導致模棱兩可的需求,因為汽車電控系統是一個復雜的系統,它在多層相互依賴關系上擁有成千上萬的需求,給需求分析工作增加了棘手難度。為了使需求開發工作高效高質髙量,筆者使用可視化分析模型從不同角度分析電控產品需求,將需求可視化,更好地增進不同團隊成員之間理解與溝通。圖2為基于可視化分析模型的汽車電控系統需求開發總體方案。汽車電控系統開發遵循V模型流程,V模型的左側部分屬于系統正向分析過程,其主要目的是分析電控產品的組成以及功能和要求的實現方式;V模型的右側部分屬于系統測試驗證,其主要目的是驗證系統按照設計方案正確實現的以及所設計的系統能夠滿足協定的客戶要求。這樣,就完成了一個完整的系統生命周期過程。在這個過程中,客戶有可能變更需求,就會重新回到需求獲取階段,按照相應的流程開展工作。汽車電控系統是一個復雜的系統,客戶提出的需求往往是從客戶的直觀感受與體驗角度出發的,基于的視角非常頂層,無法直接用于系統設計實現,為了厘清復雜系統的錯綜關系,必須對需求進行結構化分層設計。這里,將需求從上至下依次劃分為用戶需求、系統需求、子系統需求和組件需求。將頂層的需求逐步展開分解,需求分析的顆粒度逐漸推導細化,使電控系統的原始黑盒狀態逐步變成灰盒狀態,再推演變成白盒狀態,最終清晰呈現系統設計的各個細節。

圖2 基于可視化分析模型的汽車電控系統需求開發總體方案Fig.2 Overall scheme of automotive electronic control system requirements development based on visual analysis model

在需求自頂向下逐步開發過程中,單純的基于文本的需求分析方法很容易造成系統功能點的遺漏和理解偏差,難點在于對其完整性、一致性、準確性和正確性的分析,就必須對需求進行可視化。構建需求分析模式是一種強有力的方法,工程師使用圖形可以更好和更快地感知以及記憶待開發系統。與此同時,沒有哪一個需求視圖能夠讓我們全面理解需求。為了看清待開發系統的全貌,需要在不同的抽象層次綜合使用多種模型來表達需求。因此,現提出一種基于可視化分析模型的需求開發方法,旨在提升電控系統正向設計能力。其思想就是根據待開發系統所處的外界環境以及內外部邏輯關系,用用例場景模型、靜態結構模型和動態行為模型從不同角度去分析和展示目標系統相關特征和/或特性。整個需求分析過程如圖3所示,輸入需求凍結后,借助可視化分析模型對每項需求進行分析與建模,并將分析的結果進行文檔記錄,會衍生新的需求和驗證策略,并對這些衍生的需求進行評審固化,作為下一層級需求分析的依據。下面開始具體闡述需求轉換方法。

圖3 需求分析過程模型Fig.3 Requirements analysis process model

針對客戶需求進行分析,應識別兩種需求:一類是從客戶要求引申出來的邏輯結果;另一類是客戶雖然沒有明確表態但似乎有意向的隱含需求。現使用用例場景模型,來展示待開發系統與外部系統之間的界限及接口,便于分析系統與外部環境之間的關聯。系統所處環境是影響系統的現實環境部分,因此系統所處環境也會影響系統的需求。為了能夠獲取待開發系統的需求,首先要定義系統與系統所處環境之間的邊界,以及系統所處環境與無關環境之間的邊界,如圖4所示。當系統邊界確定之后,系統的范圍也會隨之被確定。然后構建用例模型,用例模型中的方框將“系統-用例”與外部角色分離。用例是用來說明客戶期望從系統中得到什么,以及通過使用系統能實現什么。將用戶簡短的、孤立的表述轉變為可以被完全理解的表述,即分析系統在與其外部環境的各種不同元素的高度復雜交互過程中必須如何運行。場景描述的是系統使用方法。用例是相關使用場景的一個集合,場景是用例的特定實例。在場景分析時,可分為正常流程、備選流程和異常流程三種情況,構成一個用例下的多個場景。通過用例場景模型,需求工程師可以獲得開發人員必須實現的功能需求;測試人員可以確定測試方法來判斷用例是否正確實現;開發人員可能在一次發布或迭代實現一個完整的用例。在客戶需求開中,通過對系統與外部環境交互的分析,可以得到待開發系統的邊界以及系統與外界的交互信息;通過對不同用例場景的分析,可以提煉出待開發系統所要具備的功能需求及性能需求、約束等,將這些分析結果梳理后形成系統需求,這樣就完成了客戶需求到系統需求的轉換。

圖4 系統邊界圖Fig.4 System boundary diagram

獲得的系統需求是上層的系統層級需求,它是用工程語言表述的,但仍然是一個黑盒狀態,只描述了上層系統所要做什么以及做到什么程度。系統內的這些功能是什么邏輯關系,有怎樣的交互行為和信息?必須把這些問題分析清楚,才能設計出有效的解決方案。因此,必須對待開發系統繼續進行分解剖析,分解成顆粒度更小的子系統層級、組件層級,直到不可再分解或者細節比較清晰為止。從系統層級到子系統層級和從子系統層級到組件層級的逐步細化過程是一樣的,所使用的方法相同,這里只闡述系統層級到子系統層級的需求開發方法。根據文章前述的用例場景,導出用例功能流,可采用動態行為模型去展示系統所進行的行為。活動圖、序列圖和狀態機圖是系統建模語言SysML提供的指定系統行為的三種選擇。它們都可以表達連續和并發的行為,以及隨著時間的推移發生的事件。針對系統中涉及的交互接口信息,采用靜態結構模型去定義不同子系統的端口和接口,如圖5所示。將系統分解成的各子系統可用模塊定義圖來表達,針對單個子系統的內部結構,可以用內部模塊圖來表達,它用于顯示系統內部組成部分(也就是子系統)之間的關系,以及它們之間的接口。

圖5 系統靜態結構示意圖Fig.5 Diagram of the static structure of the system

確保所有接口準確反映在所屬層級的需求中,并且盡可能明確地確定接口控制權限。將這些分析結果整理后形成子系統需求,這樣就完成了系統需求到子系統需求的轉換。在需求逐層分解分析的過程中,基于可視化分析模型,也會衍生出系統所必須滿足的需求,同樣要把這些衍生的需求進行記錄,形成一份完整的需求技術文檔,作為下一層級需求分析工作的輸入。在每層需求開發時,需要梳理每條需求,同時要制定每條需求的驗證準則,用于為測試人員提供參考依據,設計相應的測試用例及測試方案。

4 案例研究

排氣中的顆粒物和氮氧化物是柴油機排放控制的主要對象。為了應對史上嚴格的國六柴油機排放法規,目前,柴油機顆粒捕集器(diesel particulate filter,DPF)技術被認為是解決柴油機顆粒排放問題最有效的手段。其蜂窩狀的陶瓷載體結構通過擴散、沉積和撞擊機理來過濾捕集柴油機廢氣中顆粒物。在過濾捕集過程中,隨著顆粒不斷在DPF中聚集累積,會引起柴油機排氣背壓升高,導致柴油機性能惡化,必須定期除去DPF中的顆粒,使DPF恢復到初始狀態,實現DPF的再生。本文以人員操作DPF駐車再生的案例為依托,針對前文所述方法進行應用研究。

圖6為人員操作DPF駐車再生的用例圖。圖中的人員與車輛為系統外部角色,所開發的系統為電控單元(electronic control unit,ECU)。人員可細分為駕駛員和維修人員,駕駛員通過操作“DPF再生開關”按鍵觸發DPF駐車再生;維修人員通過操作診斷儀觸發DPF駐車再生。DPF電控系統及后處理系統安裝在車輛上,通過ECU與車輛的交互最終實現DPF的駐車再生。DPF駐車再生涉及DPF內捕集的碳載量水平、再生條件要滿足和再生溫度控制等過程,可以將這些過程放到一個用例里,但為了控制用例的規模及模塊化,將這些過程設計成一個單獨的用例。

圖6 DPF駐車再生用例圖Fig.6 DPF parking regeneration use case diagram

根據DPF駐車再生用例圖,對這個過程進行分析,形成的觸發DPF再生活動圖如圖7所示。所開發的系統ECU與外部角色人員、車輛處于不同的泳道上,分別負責各自的活動。DPF再生請求信號由人員操作產生,可通過按鍵開關或診斷儀產生請求信號。ECU負責DPF再生控制的主要活動,包括相關信號的獲取與處理、信號的有效性判斷、再生條件的檢測、獲取DPF內捕集的碳載量信息、再生溫度控制的管理、控制指令的發送以及相關故障信息的管理及發送等。車輛為DPF再生提供相應的狀態信號以及執行實際再生溫度控制指令等,通過儀表顯示屏與人員進行互動。通過活動圖,可以直觀清晰地辨別各角色所承擔的功能,為需求開發提供了可視化分析依據。

圖7 DPF駐車再生活動圖Fig.7 DPF parking regeneration activity diagram

為了進一步詳細分析DPF再生動態行為,描述系統隨著時間推移而發生的行為和事件的序列,設計了DPF再生時序圖,如圖8所示。圖8中,使用生命線的元素為DPF系統行為中的參與者建模,使用生命線之間的消息,為DPF系統參與者之間的交互行為進行建模。在描述系統行為時,有些系統行為是同步發生的,有些行為是異步發生的,可以使用組合片段的方式向交互添加相應的控制邏輯,如循環、可選和并發行為等。DPF再生過中,提升柴油機氧化催化器(diesel oxidation catalyst,DOC)入口溫度和控制DPF再生溫度是同時進行的,使用了并發行為操作符;檢測再生條件滿足要求,控制DOC入口溫度和DPF再生溫度以及再生結束條件的判斷是處于迭代循環過程的,除非再生結束或再生中斷事件的發生,退出再生控制程序,否則一直在執行這些行為。因此,通過可視化的分析界面,為描述系統的動態行為提供了強有力的直觀表達方法。

圖8 DPF駐車再生時序圖Fig.8 DPF parking regeneration sequence diagram

由前文所述,通過對觸發DPF再生場景的頂層用例開始分析,識別系統的外部參與者與邊界,以及各參與者之間交互信息,逐步推導出該用例下所涉及的所有活動行為,這些活動都是系統哪個參與者負責,以及交互行為在時間域上的執行順序,為各子系統的開發提供了分析依據。通過對這些靜態結構和動態行為的逐步深入分析,可梳理提煉相應的需求條目,如圖9所示。這里,將需求按照系統層次結構進行分級,由粗到細,逐步分解,直至分解到可進行具體模型設計為止。不同層級之間的需求有相應的關聯關系,比如,包含、跟蹤、繼承需求、細化、滿足和驗證。針對頂層的一個抽象需求,可采用圖10所示的可視化方法逐步描述刻畫,生成下一層級更為詳細的需求條目。在這個過程中,也會衍生出一些新的需求條目,把該層級所分析出來的需求條目進行整理,形成該層級的需求規格說明,為下一層級的需求開發和架構設計提供上層方案基準。

圖9 DPF駐車再生需求圖Fig.9 DPF parking regeneration requirement diagram

圖10 可視化需求分析圖Fig.10 Visual requirements analysis diagram

基于可視化模型需求分析方法得到的需求規格說明,對觸發DPF再生功能實現進行模型設計,如圖11所示,將設計的模型生成代碼集成到ECU系統里,進行整車驗證,得到的試驗結果如圖12所示,當系統檢測到DPF再生觸發請求時,并且滿足再生使能條件,系統執行DPF再生溫度控制,綠色曲線為設定的目標溫度,紅色曲線為實際的DPF再生溫度,能夠跟隨設定目標,滿足再生功能需求,最終驗證了DPF駐車再生功能是滿足需求和要求的。

圖11 DPF駐車再生功能模型Fig.11 DPF parking regeneration function model

圖12 DPF駐車再生試驗驗證結果Fig.12 DPF parking regeneration test verification results

5 結論

對于系統高度復雜的汽車電控產品,需求方面的問題一直是項目開發成功與否的關鍵因素,也是企業正向開發過程中遇到的重大挑戰之一。基于需求開發過程的痛點和自身經驗,提出了一種基于可視化分析模型的正向需求開發方法,形成的如下結論。

(1)與基于純文本形式的需求開發方式相比,基于可視化分析模型表述需求更直觀,易于項目團隊人員對待開發系統的一致理解。

(2)采用可視化分層的需求開發方法,能夠將抽象的復雜邏輯關系逐步清晰化,能夠挖掘系統靜態結構與動態行為隱藏的特征關系,為系統方案設計提供了強力支撐。

(3)通過DPF再生實際研究案例,系統闡述了可視化分析模型的需求方法的應用過程,驗證了所提方法的可行性與有效性,為汽車電控系統正向開發提供技術手段和指導建議也可推廣應用到其他工程領域。