作者 | 張旭海
隨著智能汽車的不斷發(fā)展,智能座艙在性能與可靠性上暴露出體驗(yàn)不佳、投訴漸多的問題,本文從工程化的角度簡(jiǎn)述了如何構(gòu)建智能座艙軟件的評(píng)估框架,以及如何持續(xù)改進(jìn)其性能和可靠性。
據(jù)畢馬威發(fā)布的《2023智能座艙白皮書-聚焦電動(dòng)化下半場(chǎng)》中的數(shù)據(jù),中國(guó)汽車智能座艙市場(chǎng)規(guī)模呈逐年擴(kuò)大之勢(shì),2022 到 2026 的 5 年復(fù)合增長(zhǎng)率將超過(guò) 17%,預(yù)示著這一領(lǐng)域的蓬勃發(fā)展。隨之而來(lái)的是智能座艙軟件功能日益豐富,整體智能化程度顯著提升。
(來(lái)源:《2023智能座艙白皮書-聚焦電動(dòng)化下半場(chǎng)》)
在市場(chǎng)規(guī)模預(yù)測(cè)逐年擴(kuò)大的同時(shí),消費(fèi)者對(duì)智能座艙軟件的相關(guān)投訴占比也愈發(fā)顯著。這主要聚焦在智能座艙軟件的操作體驗(yàn)度、性能和可靠性方面,揭示出智能化功能不斷增加所帶來(lái)的挑戰(zhàn)。
根據(jù)車質(zhì)網(wǎng) 2023 年四個(gè)季度的汽車投訴分析報(bào)告匯總,智能座艙(車機(jī))涉及的質(zhì)量問題占比顯著,其中 Q1~Q4 的投訴故障點(diǎn) TOP20 中與車機(jī)相關(guān)的部分(影音系統(tǒng)故障,導(dǎo)航問題,車載互聯(lián)故障,行車安全輔助系統(tǒng)故障等)分別占據(jù)總投訴的 15.89%,10.99%,10.56% 和 9.56%。
_(來(lái)源:車質(zhì)網(wǎng))_進(jìn)一步查閱具體投訴單,會(huì)發(fā)現(xiàn)包括死機(jī)、黑屏、卡頓、響應(yīng)慢等問題非常普遍,嚴(yán)重影響了用戶的駕乘體驗(yàn),也降低了用戶對(duì)品牌的信心和認(rèn)同。
結(jié)合智能座艙軟件的發(fā)展趨勢(shì)和用戶投訴問題后,可以發(fā)現(xiàn)性能和可靠性是除了操作易用性以外,最為關(guān)鍵的使用體驗(yàn)影響因素。這兩個(gè)關(guān)鍵因素不僅直接關(guān)系到用戶的滿意度,也在很大程度上決定了智能座艙軟件在市場(chǎng)中的競(jìng)爭(zhēng)力。
后文我們將結(jié)合軟件研發(fā)的最佳實(shí)踐和智能座艙領(lǐng)域軟件的自身特點(diǎn),探討評(píng)估和改進(jìn)其性能和可靠性的方法。
If you can't measure it, you can't improve it.
智能座艙軟件系統(tǒng)本身是一種軟件,其研發(fā)過(guò)程也遵循軟件的架構(gòu)設(shè)計(jì)、開發(fā)落地和質(zhì)量驗(yàn)證的常見流程。因此在討論如何改進(jìn)之前,我們首先應(yīng)當(dāng)明確:如何正確評(píng)估軟件系統(tǒng)的性能和可靠性?
Mark Richards 和 Neal Ford 在《軟件架構(gòu):架構(gòu)模式、特征及實(shí)踐指南》中曾這樣描述 “架構(gòu)特性”:
架構(gòu)師可能會(huì)與他人合作確定領(lǐng)域或業(yè)務(wù)需求,但架構(gòu)師的一個(gè)關(guān)鍵職責(zé)是定義、發(fā)現(xiàn)和分析軟件所必須的、與領(lǐng)域無(wú)關(guān)的事情:架構(gòu)特性。
架構(gòu)特性(Architecture Characteristics)是架構(gòu)師在設(shè)計(jì)軟件時(shí)需要考慮的與領(lǐng)域或業(yè)務(wù)需求無(wú)關(guān)的軟件特性,如可審計(jì)性、性能、安全性、可伸縮性、可靠性等等。在很多時(shí)候我們也會(huì)稱之為非功能性需求(Nonfunctional Requirements)或質(zhì)量屬性(Quality Attributes)。
顯然,對(duì)于關(guān)鍵的軟件架構(gòu)特性,需要在架構(gòu)設(shè)計(jì)之初就納入整體考量,并且在軟件研發(fā)的流程中持續(xù)進(jìn)行關(guān)注。那么在研發(fā)軟件系統(tǒng)的時(shí)候,都有哪些關(guān)鍵架構(gòu)特性需要考慮呢?
ISO/IEC 25010:2011 是由國(guó)際標(biāo)準(zhǔn)化組織推行的一套標(biāo)準(zhǔn)(現(xiàn)已更新至 2023 版本),它隸屬于 ISO 系統(tǒng)與軟件質(zhì)量需求和評(píng)估(SQuaRE)體系,定義了一組系統(tǒng)和軟件質(zhì)量模型。該質(zhì)量模型被廣泛應(yīng)用于描述和評(píng)估軟件質(zhì)量,可以很好的指導(dǎo)我們對(duì)軟件關(guān)鍵架構(gòu)特征進(jìn)行建模。
ISO 25010 描述的質(zhì)量模型如下(圖中著重標(biāo)明了與性能和可靠性相關(guān)的部分):
ISO 25010 對(duì)軟件架構(gòu)特性(標(biāo)準(zhǔn)原文中稱為“質(zhì)量屬性”)進(jìn)行了劃分,涵蓋了眾多方面,如功能性、可靠性、性能效率、可維護(hù)性、可移植性等。每個(gè)架構(gòu)特性都定義了與之相關(guān)的關(guān)鍵方面,特性下還包括多個(gè)子特性,更細(xì)致地描述了特性的具體維度。可見該質(zhì)量模型提供了一個(gè)全面且通用的框架,以便更好地理解和評(píng)估軟件的質(zhì)量。
對(duì)于性能特性,該模型劃分了三種子特性:時(shí)間特性,資源利用性,容量;而對(duì)于可靠性特性,模型劃分了四種子特性:成熟性,可用性,容錯(cuò)性和易恢復(fù)性。
當(dāng)然,任何一種軟件都有其自身的特點(diǎn)和運(yùn)行環(huán)境,能夠滿足上述模型中所有架構(gòu)特性的軟件固然優(yōu)秀,但成本勢(shì)必高昂,正如對(duì)于一套只有 3 個(gè)用戶的內(nèi)部系統(tǒng),設(shè)計(jì)彈性伸縮來(lái)滿足可用性是毫無(wú)必要的。顯然在智能座艙軟件的領(lǐng)域,以用戶體驗(yàn)來(lái)評(píng)估性能和可靠性特性,比用吞吐量和彈性伸縮比來(lái)評(píng)估更符合智能座艙軟件的設(shè)計(jì)目標(biāo)。
分析前面的軟件質(zhì)量模型,我們會(huì)發(fā)現(xiàn)該模型主要定義了軟件的架構(gòu)特性“應(yīng)當(dāng)表現(xiàn)為什么樣子”,但沒有講明“需要怎么評(píng)估”才能判斷已經(jīng)達(dá)成了架構(gòu)特性的要求。質(zhì)量模型中的特性和子特性是對(duì)架構(gòu)特性的定性描述,而如何對(duì)架構(gòu)特性進(jìn)行定量評(píng)估未能提及。
事實(shí)上,SQuaRE 也提供了對(duì)質(zhì)量模型的評(píng)估框架(詳見 ISO/IEC 25020:2019):
以上評(píng)估框架本質(zhì)上就是采用一組權(quán)重不同的指標(biāo)集來(lái)評(píng)估一項(xiàng)架構(gòu)特性(子特性),指標(biāo)可以由一些指標(biāo)元素計(jì)算得出,而指標(biāo)元素可通過(guò)一些實(shí)施在軟件研發(fā)活動(dòng)中的測(cè)量方法測(cè)量而得。
在軟件行業(yè),許多評(píng)估指標(biāo)都能夠跨業(yè)務(wù)領(lǐng)域達(dá)成共識(shí),如響應(yīng)時(shí)間、吞吐量、RTO、RPO、MTTR 等等,企業(yè)在建立自己業(yè)務(wù)領(lǐng)域的指標(biāo)體系時(shí)可以直接采納。
如下就是一些相對(duì)通用的軟件性能和可靠性指標(biāo)示例,這些指標(biāo)對(duì)絕大多數(shù)的軟件都適用:
當(dāng)然,由于功能領(lǐng)域和運(yùn)行環(huán)境的不同,用于評(píng)估架構(gòu)特性的指標(biāo)體系勢(shì)必會(huì)存在一定的差異。
首先,不同的業(yè)務(wù)場(chǎng)景對(duì)評(píng)估指標(biāo)的權(quán)重設(shè)置會(huì)存在區(qū)別。例如對(duì)智能座艙系統(tǒng)和軟件的性能效率評(píng)估,由于關(guān)系到用戶駕乘體驗(yàn),時(shí)間特性至關(guān)重要,而對(duì)提供互聯(lián)網(wǎng)服務(wù)的 Web 應(yīng)用,為了向更多用戶提供服務(wù),容量特性就是其需要關(guān)注的重點(diǎn)。
其次,特定的領(lǐng)域會(huì)有其獨(dú)特的性能指標(biāo)。這些差異性指標(biāo)需要從實(shí)際業(yè)務(wù)中提煉。例如 UI 界面流暢度無(wú)法簡(jiǎn)單的用響應(yīng)時(shí)間來(lái)評(píng)估,而是需要通過(guò)幀率、丟幀數(shù)等指標(biāo)來(lái)綜合判斷。
在建立了指標(biāo)體系之后,接下來(lái)面臨的問題就是如何尋找合理的指標(biāo)元素來(lái)計(jì)算指標(biāo)值。
同樣的,有非常多通用的指標(biāo)元素可以直接采納,例如圈復(fù)雜度,模塊耦合度,CPU 使用率,內(nèi)存使用率,事務(wù)執(zhí)行時(shí)間,并發(fā)度等等。但指標(biāo)元素相比指標(biāo)本身而言,與業(yè)務(wù)領(lǐng)域相關(guān)度更高,更需要結(jié)合領(lǐng)域知識(shí)來(lái)尋找合適的指標(biāo)元素。
GQM 方法是一種有效的尋找和建立指標(biāo)元素的分析法:GQM 即“Goal - Question - Metrics”,可譯為“目標(biāo) - 問題 - 指標(biāo)” ,是一種歷史悠久的分析方法,由 Victor Basili 和 David Weiss 在 1984 年提出。
本質(zhì)上 GQM 是通過(guò)樹形分析結(jié)構(gòu),層層遞進(jìn)。首先以如何實(shí)現(xiàn)目標(biāo)為前提,對(duì)目標(biāo)進(jìn)行提問,之后將每個(gè)問題拆解為多個(gè)能支撐解決該問題的指標(biāo)元素,最后評(píng)選出最合適的指標(biāo)元素。
如下我們以“幫助尋找智能座艙軟件的性能和可靠性特征的評(píng)估指標(biāo)元素”為例,分別基于“評(píng)估智能座艙主屏操作流暢度”和“計(jì)算智能座艙系統(tǒng)與應(yīng)用的故障率和可用性”為目標(biāo),建立 GQM 分析樹:
在分析之初,為了擴(kuò)展思路,可以先不考慮指標(biāo)元素的價(jià)值和獲取難度,盡可能多的識(shí)別可能的指標(biāo)元素,之后再分析每一個(gè)指標(biāo)元素的價(jià)值和獲取的難易程度,并據(jù)此對(duì)其進(jìn)行優(yōu)先級(jí)排序,篩選最適合的指標(biāo)元素。這一過(guò)程可遵循如下優(yōu)先級(jí)原則:
基于 GQM 方法,我們能夠?qū)Τ橄蟮闹笜?biāo)進(jìn)行拆解,得到更為清晰的指標(biāo)計(jì)算公式和采集數(shù)據(jù)點(diǎn),至此一個(gè)完整的評(píng)估框架就搭建完成了。
基于前文引入的評(píng)估框架,我們已經(jīng)掌握了一定的分析方法,明確了改善智能座艙軟件性能和可靠性的方向。
評(píng)估的下一步就是改進(jìn),本節(jié)將要討論如何以工程化的方法,對(duì)智能座艙軟件的性能和可靠性架構(gòu)特性進(jìn)行持續(xù)改進(jìn),從而確保隨著軟件的迭代,其性能和可靠性不僅不會(huì)劣化,而是會(huì)長(zhǎng)期、穩(wěn)步地提升。
建模是在設(shè)計(jì)階段對(duì)業(yè)務(wù)領(lǐng)域和架構(gòu)特征進(jìn)行分析的有效實(shí)踐。許多組織在進(jìn)行軟件架構(gòu)設(shè)計(jì)時(shí),往往注重業(yè)務(wù)領(lǐng)域建模,輕視架構(gòu)特性建模,經(jīng)常會(huì)導(dǎo)致諸如安全性、可靠性、性能等的設(shè)計(jì)考量嚴(yán)重后置,等軟件發(fā)布之后再被生產(chǎn)問題倒逼改進(jìn)。
事實(shí)上早期的架構(gòu)特性建模不僅可以指導(dǎo)后續(xù)研發(fā)過(guò)程中的代碼開發(fā),也天然能轉(zhuǎn)化為白盒測(cè)試來(lái)驗(yàn)證代碼是否符合設(shè)計(jì)要求。
對(duì)于性能建模,可以通過(guò)識(shí)別軟件架構(gòu)的性能關(guān)注點(diǎn),以及預(yù)定義性能指標(biāo)來(lái)形成性能模型。關(guān)于性能建模,筆者曾在《什么是性能工程》中有過(guò)介紹。
對(duì)于可靠性建模,得益于汽車生產(chǎn)制造領(lǐng)域已有很多成熟的建模方法,軟件領(lǐng)域也可直接參考和剪裁。故障樹分析(FTA)、故障模式和影響分析(FMEA)等建模方法。_(來(lái)源:描述 FMEA 程序的國(guó)家標(biāo)準(zhǔn) G)_
(B/T 7826-2012)
為了避免建立的模型只在架構(gòu)評(píng)審會(huì)議上有效,而實(shí)際落地的時(shí)候完全沒有遵循架構(gòu)設(shè)計(jì),很有必要基于模型構(gòu)建對(duì)應(yīng)的適應(yīng)度函數(shù),以確保架構(gòu)不會(huì)慢慢腐化,下一小節(jié)將介紹架構(gòu)適應(yīng)度函數(shù)。
有了指標(biāo)體系,我們可以定量的對(duì)智能座艙軟件的性能和可靠性進(jìn)行分析和評(píng)估。然而,如果評(píng)估的過(guò)程過(guò)于復(fù)雜、冗長(zhǎng)且難以快速進(jìn)行,那么隨著時(shí)間的推移,對(duì)這些架構(gòu)特性的評(píng)估就會(huì)成為團(tuán)隊(duì)沉重的負(fù)擔(dān),這意味著評(píng)估活動(dòng)的次數(shù)會(huì)越來(lái)越少,反饋越來(lái)越慢,難以持續(xù),最終停滯下來(lái)。
一切可以被自動(dòng)化的事情,都應(yīng)該被自動(dòng)化。
在評(píng)估軟件功能是否滿足要求時(shí),我們會(huì)構(gòu)建大量的自動(dòng)化測(cè)試,這樣就能形成一張軟件特性安全網(wǎng),持續(xù)的保障軟件符合要求。而對(duì)于架構(gòu)特性的評(píng)估,傳統(tǒng)的做法更像是 “運(yùn)動(dòng)式” 評(píng)估:
ASPICE 是一個(gè)典型的案例,由于流程和文檔的復(fù)雜性,以及對(duì)每個(gè)研發(fā)階段的嚴(yán)格要求,導(dǎo)致設(shè)計(jì)和測(cè)試很容易停留在上一個(gè)較早的快照版本狀態(tài),永遠(yuǎn)都跟不上軟件變化的速度。
(來(lái)源:An ASPICE Overview)
在 Neal Ford、Patrick Kua 和 Rebecca Parsons 合著的《演進(jìn)式架構(gòu)》一書中,將適應(yīng)度函數(shù)定義為“用于總結(jié)預(yù)期設(shè)計(jì)的解決方案與實(shí)現(xiàn)設(shè)定目標(biāo)接近程度的目標(biāo)函數(shù)”。引出適應(yīng)度函數(shù),就是要通過(guò)工程化的手段實(shí)現(xiàn)對(duì)架構(gòu)的評(píng)估也能自動(dòng)化、常態(tài)化。
(來(lái)源:《演進(jìn)式架構(gòu)》)
當(dāng)我們的指標(biāo)和模型被轉(zhuǎn)換為一個(gè)個(gè)適應(yīng)度函數(shù),它們就能夠綁定在研發(fā)流水線上,從而實(shí)現(xiàn)對(duì)架構(gòu)特性的自動(dòng)化評(píng)估。
有了自動(dòng)化作為前提,接下來(lái)就可以采用架構(gòu)看護(hù)來(lái)驅(qū)動(dòng)持續(xù)改進(jìn)。
基于已經(jīng)建立的各類適應(yīng)度函數(shù),在每日構(gòu)建、迭代測(cè)試以及集成測(cè)試等流程中,適應(yīng)度函數(shù)產(chǎn)生的執(zhí)行結(jié)果能夠形成一組完整的性能和可靠性評(píng)估報(bào)告。取上一版本的評(píng)估結(jié)果作為基線,與最新版本的評(píng)估結(jié)果進(jìn)行對(duì)比,就能對(duì)軟件在性能和可靠性上的表現(xiàn)實(shí)現(xiàn)細(xì)致的看護(hù),從而判斷新版本哪些部分進(jìn)行了優(yōu)化,哪些部分發(fā)生了劣化,一目了然。
至此我們已經(jīng)擁有了一些手段來(lái)支持持續(xù)的性能和可靠性評(píng)估,但評(píng)估本質(zhì)上是為了暴露問題,之后的分析和優(yōu)化才是持續(xù)改進(jìn)的難點(diǎn)。
暴露了問題之后,往往需要以最快的速度開展優(yōu)化,而對(duì)于業(yè)務(wù)型組織而言,團(tuán)隊(duì)絕大多數(shù)時(shí)間都在業(yè)務(wù)領(lǐng)域工作,對(duì)性能和可靠性一類的問題分析和優(yōu)化能力不足,通常此時(shí)組織就會(huì)尋找或聘請(qǐng)技術(shù)專家來(lái)幫助改進(jìn)。但技術(shù)專家作為稀缺資源,面對(duì)多種多樣的問題,往往捉襟見肘。
因此,期望實(shí)現(xiàn)持續(xù)改進(jìn)的組織,建立工程化的分析和優(yōu)化手段來(lái)提升效率必不可少,這里首當(dāng)其中的就是構(gòu)建可觀測(cè)工具集。在前面提到的評(píng)估框架中,指標(biāo)的作用主要是為了指示當(dāng)前狀態(tài)如何,指標(biāo)可以評(píng)估優(yōu)劣,但不能幫助分析問題根因。分析軟件問題需要能復(fù)現(xiàn)系統(tǒng)運(yùn)行時(shí)發(fā)生了什么,組件是如何交互的,產(chǎn)生了哪些數(shù)據(jù),而這些信息都需要通過(guò)可觀測(cè)工具來(lái)抓取和記錄。
擁有了這樣的工具集之后,當(dāng)評(píng)估發(fā)現(xiàn)某些指標(biāo)出現(xiàn)劣化,就能基于一些基本信息迅速關(guān)聯(lián)出系統(tǒng)運(yùn)行時(shí)的上下文和觀測(cè)記錄,從而快速分析和定位問題,快速實(shí)施優(yōu)化。
智能汽車市場(chǎng)前景廣闊,發(fā)展迅速,隨著競(jìng)爭(zhēng)的深入,智能座艙的極致體驗(yàn)一定會(huì)成為各汽車廠商的一大目標(biāo)。
本文主要從軟件研發(fā)和交付的角度,結(jié)合軟件領(lǐng)域的優(yōu)秀實(shí)踐和探索,討論了智能座艙軟件在性能和可靠性方面的持續(xù)評(píng)估方法和持續(xù)改進(jìn)方法。
隨著越來(lái)越多的外部投資和跨領(lǐng)域人才涌入智能汽車領(lǐng)域,相信未來(lái)在相關(guān)產(chǎn)業(yè)中定能不斷地創(chuàng)造巨大的價(jià)值。
本文鏈接:http://www.www897cc.com/showinfo-26-76570-0.html智能座艙軟件性能與可靠性的評(píng)估和改進(jìn)
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com
上一篇: Java程序員易踩的坑及解析