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