軟件系統架構的選擇對于軟件系統開發的成敗至關重要,軟件架構各種風格各種方法,光分層架構方法就很多,如何評估哪個軟件系統架構方法更合適。CMU/SEI(卡梅隆大學軟件工程協會)提出了一套架構權衡分析方法,Architecture Tradeoff Analysis Method,簡稱ATAM。
傳統軟件架構評估方法按評估形式,一般分為三種。一是調查問卷法,即直接請對系統架構了解的專家學者對系統架構做出主觀評估。二是度量法,即將軟件系統架構完全量化,通過一些客觀的數字指標來評估架構的好壞。三是場景評估法,即挑選出重要的系統使用場景,根據不同場景中各架構的表現分別作評估,ATAM屬于場景評估法,主客觀程度介于前面兩種方法之間。
首先先了解三個概念。
一、軟件質量屬性
軟件質量屬性說的是我們評估軟件架構,到底評估它的什么特性,一般有如下幾個:
性能:指系統的響應能力,即系統執行某個特定事務所需要的時間。
可靠性:即在意外或錯誤使用的情況下,維持軟件系統的功能特性的能力。一般包括容錯和健壯性兩個方面的能力。
可用性:是系統能夠正常運行的時間比例,和可靠性相比,可用性除了體現出錯概率外,還體現出錯后恢復正常的速度上。
安全性:是指阻止非授權用戶使用的企圖或拒絕服務的能力。又可分為機密性、完整性、不可否認性及可控性。
可修改性:是指能夠快速地以較高的性價比對系統進行變更的能力。包括可維護性,可擴展性,結構重組和可移植性。
二、敏感點和權衡點
敏感點和權衡點都是在軟件架構中所做的關鍵決策,不同的是,敏感點決策只影響一個軟件質量屬性,而權衡點則同時影響多個質量屬性,有時不同屬性間還會互相沖突,比如選擇不同的加密方式同時影響性能和安全性,所以需要權衡。
三、風險承擔者
風險承擔者是指那些關心軟件架構,個人利益受軟件架構好壞影響的人,在項目管理領域也稱為項目干系人或涉眾。這照些人整體上又可以分為系統的生產者和系統的消費者。生產者包括架構師,開發人員,維護人員,測試人員等;消費者包括客戶,最終用戶等。
ATAM通過理解體系結構方法來分析體系結構,評估過程分9個步驟:
1、描述ATAM方法
即評估小組負責人向參加會議的風險承擔者介紹ATAM評估方法,負責人將解釋評估的原則、評估的方案及目標(例如:那些質量特性應該優先考慮)。
2、描述業務動機
從業務角度介紹系統的概況,一般包括業務環境,背景,業務約束條件,技術約束,質量屬性需求等內容。
3、描述體系結構
設計師或設計小組對體系結構進行詳略適當的介紹。包括技術約束,與本系統交互的其他系統,用以滿足質量屬性要求的體系結構方法(功能,模塊,進程,硬件)。
4、確定體系結構方法
由設計師確定體系結構方法,由分析小組捕獲,但不進行分析。
5、生成質量屬性效用樹
評估小組,設計小組,管理人員和客戶代表一起確定系統最重要的質量屬性目標,并對這些目標設置優先級和細化。
6、分析架構方法
7、頭腦風暴并確定場景的優先級
8、分析架構方法
9、描述評估結果
下面通過汽車后保險杠上加裝后視攝像頭案例介紹下ATAM在汽車軟件中的應用。
1、描述ATAM方法
汽車后保險杠上加裝后視攝像頭。目前大部分汽車都有尾部攝像頭,倒車時通過中控顯示倒車影像。
當在原有的電氣系統中加入攝像頭后,從汽車尾部傳輸到汽車頭部的數據量會急劇增加。同時,為確保倒車期間的安全性,倒車影像數據必須保證實時傳輸。而在總線上,還有其他安全關鍵信號也需要保證實時傳輸,這意味著通信總線不得不持續地在視頻信號反饋和諸如駐車輔助等安全關鍵性傳感器之問調整傳輸的優先級。在這一場景下,架構師需要回答一個問題:如何保證攝像頭的加人不會對車上原有的安全關鍵性功能造成負面影響?相比實際車輛的軟件架構,該案例有一定的簡化和修改,僅作為ATAM的說明,這里充當“描述ATAM方法。”
2、描述業務動機
該架構的主要業務動機是使車輛達到高度安全性。
通過示例圖來描述該架構。首先展示的是汽車的功能架構。因為關注的是攝像頭功能,我們只選取了架構中與之相關的主動安全域、底盤域和車載娛樂域的功能,主動安全域包括緊急制動、制動防抱死(ABS)功能,底盤域包括轉向燈、近光燈和刮水器,車載娛樂域包括中控屏和抬頭顯示設備(Head-up Display,HUD)中的信息顯示功能。
架構中的功能從屬示例
在介紹下汽車的EEA架構,這個案例中簡化的物理視圖。
架構的物理視圖示例
在物理視圖中,存在兩條總線:
?CAN總線:連接車載娛樂域中的控制單元。
?FlexRay總線:連接安全域和底盤域中的控制單元。
除此之外,視圖中還有如下控制單元節點:
?主控制單元:汽車的中樞控制單元,控制車輛配置,負責整個電子電氣系統的初始化和診斷。該單元是車輛上計算能力最強的控制器。
?制動防抱死控制單元(ABS):該控制單元負責車輛的制動和相關功能。這是一個高度安全關鍵的系統,具有車輛上最高的軟件安全等級。
?高級駕駛輔助系統(ADAS):該控制單元負責主動安全領域更高級別的決策,例如制動防碰撞、緊急制動、防滑等功能。它也負責駐車輔助等功能。
?轉向:該控制單元負責車輛的轉向功能,例如電子轉向系統;駐車輔助等功能的一部分也通過該控制單元實現。
?尾部控制單元(Back Body Controller,簡稱BBC):該控制單元負責與車輛尾部相關的非安全關鍵功能,例如:調節后視鏡、行李艙電子開關、后窗除霧等功能。
接下來,是架構的邏輯視圖,在該視圖中,聚焦在車載娛樂系統顯示的主要功能組件,以及它對攝像頭控制單元的信號輸人的處理。
架構的邏輯視圖示例
還有一種增加了攝像頭后架構的潛在布置方案。在這種方案中,信號處理的主要工作在尾部控制器節點完成;
潛在方案示例
3、確定架構方法
我們關注的是目標控制單元上的軟件組件的劃分。無論采用何種軟件架構,系統的物理架構(硬件)都沒有變化。因此,架構方法的確定應僅依賴于汽車的電子電氣系統。有另一種架構的替代方案,不同于將攝像頭功能的軟件組件劃分至主控制器和尾部控制器的方式,所有的信號處理工作都在主控制器中進行。因為系統的主要功能是對圖像信號的處理,因此我們采用了常見的管道過濾器(pipe-and-filter)風格來設計架構。汽車的電氣系統應該支持主動安全的先進機制(通過軟件控制),并且確保這些機制之間不會互相干擾,從而危及車輛安全。
另一種替代方案示例
對這兩種替代方案都進行研究,最終決定選擇何種架構來支持最初期望的質量目標,基于它們的各自生成的質量屬性效用樹來完成架構的選型。
4、生成質量屬性效用樹
在這個案例中,讓我們考慮兩個互補的場景,雖然可以為上文提到的每個質量屬性都找到多個場景,這里我們只關注安全性:場景一,當車輛倒車、倒車影像激活后,CAN總線出現了信號擁擠;場景二,當惡劣氣候下主控制器單元已經過載時,影像信號的計算會對雨刮器、近光燈等功能的性能造成于擾。
場景多方面描述
方面 | 詳細含義 |
源 | 后攝像頭 |
刺激 | 影像信號 |
構件 | 主控制單元,尾部控制單元,CAN總線 |
環境 | 倒車過程中 |
響應 | 處理彩像數據并顯示在中控屏上 |
度量 | 視頻影像可以實時顯示,同時來自駐車傳感器的安全關鍵信號不會丟失 |
在第一個場最中,我們所關注的是倒車影像對安全性的影響。需要了解視頻信號的數據傳輸會對連找主控制器和尾部控制器的CAN總線造成何種影響。因此,我們設計的兩種架構布置方視頻信號處理布置在主控制器單元或布置在尾部控制器中,都需要被納入分析。假設兩種架構方案都不會導致硬件的增加,因此對電氣系統的整體性能沒有影響。通過這一簡化我們將不必分析物理架構,而將關注點全部放在架構的邏輯視圖和布置方案上。
通信總線占用
場景編號 | 場景1:倒車過程中的總線信號擁擠阻止了安全關鍵信號的傳輸 |
剌激 |
該場景中,當車輛倒車時,來自尾部攝像頭的倒車視頻影像占用了過多的總線容量,導致總線信號無法傳播由制動傳感器發來的信號。 對該場景評估的關鍵問題是,哪種布置方案會對汽車軟件的安全性造成最小的影響。 |
響應 |
—分析兩種架構布置方案中潛在的信號擁擠 —列舉每種架構方案對功能的限制因素 |
需求 | 該架構應該能讓安全關鍵信號在任何時刻被發出、被接收 |
質量屬性 | 安全性:在該場景中,需要找到不會造成總線信號擁擠并造成潛在信號丟失的架構。 |
文本(可選) | 當倒車時,車尾攝像頭發出的視頻信號削減了制動傳感器向主控制單元發送信號的能力,從而導致在潛在碰撞即將發生時,駕駛員沒有得到預警提醒 |
主控制單元的過載
場景編號 | 場景2:在氣候惡劣的情況下,已經滿負載的主控制器單元會削減倒車影像信號的質量 |
剌激 |
當車輛倒車且遇到下雨/下雪等路況時,主控制單元需要同時負責驅動雨刮器工作、點亮近光燈以及處理視頻信號,ECU的工作負載可能過大,而不足以同時完成所有的計算工作 對該場景評估的關鍵問題時:哪種布置方案會對汽車軟件的性能造成最小的影響 |
響應 |
—分析兩種架構布置方案中各類信號計算需要占用的ECU資源 —列舉每種架構方案對功能的限制因素 |
需求 | 在任何氣候條件下,車輛在倒車時都應該穩定地提供來自尾部攝像頭的影像信號 |
質量屬性 | 性能:在該場景中,我們需要找到不會造成車輛控制器計算過載并削減視頻信號傳輸質量的架構方案 |
文本(可行) | 當在惡劣氣候條件下倒車時,汽車的控制單元可能會出現計算量過載,從而無法充分應對視頻信號傳輸的任務 |
在上述分析中,之所以要同時考慮兩種方案,是因為它們展示了功能在節點上分布方案背后的不同邏輯可能性。在這個的案例中,基于場景分析得到的質量效用樹包含著兩種質量屬性安全性和性能。兩種場景在效用樹中的評級都是高。當生成了效用樹后,就可以對兩種架構進行分析,并找到它們各自的權衡點和敏感點。
質量屬性效用樹
5、分析架構方法和決策
對架構及其兩種部署方案進行深入分析。在分析過程中,會發現了很多風險,這里以一個風險為例:信號無法傳輸到另一個控制器的風險。
可以使用風險模板來完成描述。可以看到該風險會影響到乘客的安全,因此需要被消除。進一步分析,消除該風險意味著總線通信不能對安全關鍵信號造成影響。因此,應該優先考慮第一種架構方案—在尾部控制單元完成視頻信號的處理。這一方案意味著尾部控制器需要有足夠的計算能力完成對視頻信號的實時處理,這可能會導致車輛電氣系統的成本增加。但既然安全性是業務動機,單車成本的增加應該可以被車型銷量的增加所平衡。
風險描述
風險編號 | R1_S1 |
描述 | 來自制動傳感器的信號無法通過總線傳輸。造成的風險,當車輛遇到障礙物時將無法有效制動,從而發生碰撞。 |
危險源/敏感點 |
該風險發生在連接主控器單元和尾部控制器單元之間的FlexRay總線上,如下圖(SP1): |
風險影響 |
功能安全ASIL等級C要求: RQ1:車輛需要在檢測到前方障礙物后,在2m之內制動停車。 該風險對用戶的影響是,車輛無法制動停車,從而對系統造成危險。同時也會對乘客的健康造成輕微危害。 |
風險嚴重性 | 3 |
風險概率 | 5—該現象非常容易在倒車過程中發生(只要安全信號和視頻信號影響信號需要同時傳播) |
6、描述評估結果
在實踐中,架構和評估團隊會執行與上述類似的完整討論和展示工作,包括問題的發現,場景、場景優先級的排定以區頭腦風暴等。
ATAM評估總結
場景 | 在倒車過程中捕獲來自尾部的倒車影像信號并將其顯示在中控屏上 | ||
屬性 | 安全性 | ||
環境 | 車輛處于倒車狀態 | ||
刺激 | 倒車影像信號在中控屏顯示 | ||
響應 | 處理視頻數據并在中控屏顯示 | ||
架構決策 | 敏感點 | 權衡點 | 風險 |
將視頻信號處理任務放在主控制單元進行 | S1 | T1 | R1 |
將視頻信號處理任務放在尾部處理單元進行 | T2 | R2 | |
推理 |
主控制器單元的功能對系統至關重要(敏感點S1) 安全性的提升造成成本提升(權衡點T1) 由于主控制器的信號處理負荷過高,安全需求可能存在風險(風險R1) |
||
架構視圖 |
ATAM方法是為軟件架構的設計而開發的。但是在汽車領域,汽車軟件架構和物理硬件的架構是緊密聯系的。建議在對汽車領域的軟件架構進行ATAM評估時,將硬件也納入評估團隊,只有這樣才能確保所設計的軟件架構完全滿足系統的要求。
審核編輯:劉清
-
控制器
+關注
關注
112文章
16442瀏覽量
179006 -
CMU
+關注
關注
0文章
21瀏覽量
15268 -
智能汽車
+關注
關注
30文章
2887瀏覽量
107449
原文標題:智能汽車軟件架構評估方法-ATAM
文章出處:【微信號:智能汽車電子與軟件,微信公眾號:智能汽車電子與軟件】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論