迎接終端AI新時代：讓運算更靠近資料所在

作者 : Andrew Brown，Strategy Analytics
2021-03-03

資料/數據(data)成長的速度越來越快。據估計，人類目前每秒產出1.7Mb的資料。智慧與個人裝置如智慧型手機、平板電腦與穿戴式裝置不但快速成長，現在我們也真正目睹物聯網(IoT)的成長，未來連網的裝置數量將遠遠超越地球的人口。

這包括種類繁多的不同裝置，像是智慧感測器與致動器，它們可以監控從震動、語音到視覺等所有的東西，以及幾乎大家可以想像到的所有東西。這些裝置無所不在，從工廠所在位置到監控攝影機、智慧手錶、智慧家庭以及自主性越來越高的車輛。隨著我們企圖測量生活週遭數位世界中更多的事物，它們的數量將持續爆炸性成長。

資料爆量成長，讓許多企業把資料從內部部署運作移到雲端。儘管集中到雲端運算的性質，在成本與資源效率、彈性與便利性有它的優點，但也有一些缺點。由於運算與儲存在遠端進行，來自終端、也就是那些在網路最邊緣裝置的資料，需要從起始點經過網際網路或其他網路，來到集中式的資料中心(例如雲端)，然後在這裡處理與儲存，最後再傳回給用戶。

對於一些傳統的應用，這種方式雖然還可以接受，但越來越多的使用場景就是無法承受終端與雲端之間，資訊被接力傳遞產生的延遲。我們必須即時做出決策，網路延遲要越小越好。基於這些原因，開始有人轉向終端運算；越來越多人轉而使用智慧終端，而去中心化的程度也越來越高。此外，在這些即時應用中產生的龐大資料量，意味著處理與智慧必須在本地以分散的方式進行。

與資料成長連袂而來的，是人工智慧與機器學習(ML)也朝終端移動，並且越來越朝終端本身移動。大量來自真實世界的資訊，需要用ML的方式來進行詮釋與採取行動。透過AI與ML，是以最小的延遲分析影像、動作、影片或數量龐大的資料，唯一可行且合乎成本效益的方式。運用AI與ML的演算法與應用將在邊緣運作，在未來還將會直接在終端裝置上進行。

資料正在帶動從集中化到分散化的轉變

隨著資訊科技市場逐漸發展與成熟，網路的設計以及在其運作的所有裝置，也都跟著進化。全盛時期從服務數千個小型客戶端的主機，一直到客戶端伺服器模型中使用的越來越本地化的個人電腦運算效能，基礎架構持續重組與最佳化，以便更貼近網路上的裝置以及符合運作應用的需求。這些需求包含檔案存取與資料儲存，以及資料處理的需求。

智慧型手機與其他行動裝置的爆炸性成長，加上物聯網的快速成長，促使我們需要為如何讓資產進行最佳的部署與安排進行評估。而影響這個評估的因素，包括網路的可用性、安全性、裝置的運算力，以及把資料從終端傳送到儲存設備的相關費用，近來也已轉向使用分散式的運算模型。

從邊緣到終端：AI與ML改變終端典範

在成本、資源效率、彈性與便利性等方面，雲端有它的優點，裝置數量的急遽增加(如圖2)，將導致資料產出量大幅增加。這些資料大部份都相當複雜且非結構化的，這也是為何企業只會分析1%~12% 的資料的原因之一。把大量非結構化的資料送到雲端的費用相當高、容易形成瓶頸，而且從能源、頻寬與運算力角度來看，相當沒有效率。

在終端執行進階處理與分析的能力，可協助為關鍵應用降低延遲、減少對雲端的依賴，並且更好地管理物聯網產出的巨量資料。

終端AI：感測、推論與行動

在終端部署更多智慧的主要原因之一，是為了創造更大的敏捷性。終端裝置處於網路的最邊緣與資料產生的地方，可以更快與更準確地做出回應，同時免除不必要的資料傳輸、延遲與資料移動中的安全風險，可以節省費用。

處理能力與神經網路的重大進展，正協助帶動終端裝置的新能力，另一股驅動力則是對即時資訊、效率(傳送較少的資訊到雲端)、自動化與在多數情況下，對近乎即時回應的需求。這是一個三道步驟的程序：傳送資料、資料推論(例如依據機器學習辨識影像、聲音或動作)，以及採取行動(如物件是披薩，冰箱的壓縮機發出正常範圍外的聲音，因此發出警告)。

感測

處理器、微控制器與感測器產生的資料量相當龐大。例如，自駕車每小時要搜集25GB的資料。智慧家庭裝置、智慧牙刷、健身追蹤器或智慧手錶持續進化，並且與以往相比，會搜集更多的資料。

它們搜集到的資料極具價值，但每次都從各個終端節點把資料推回給雲端，數量又會過多。因此必須在終端進行處理。倘若部份的作業負載能在終端本身進行，就可以大幅提升效率。

推論

終端搜集到的資料是非結構性的。當機器學習從資料擷取到關聯性時，就是在進行推論。這表示使用AI與ML工具來幫忙訓練裝置辨識物件。拜神經網路的進展之賜，機器學習工具越來越能訓練物件以高度的精準度辨識影像、聲音與動作，這對體積越來越小的裝置，極為關鍵。

例如，圖4顯示使用像ONNX、PyTorch、Caffe2、Arm NN或 Tensorflow Lite 等神經網路工具，訓練高效能的意法半導體(ST)微控制器(MCU)，以轉換成最佳化的程式碼，讓MCU進行物件辨識(這個的情況辨識對象是影像、聲音或動作)。更高效能的MCU越來越常利用這些ML工具來辨識動作、音訊或影像，而且準確度相當高，而我們接下來馬上就要對此進行檢視。這些動作越來越頻繁地從邊緣，轉移到在終端運作的MCU本身。

行動

資料一旦完成感測與推論後，結果就是行動。這有可能是回饋簡單的回應(裝置是開啟或關閉)，或針對應用情況進行最佳化(戴耳機的人正在移動中，因此會針對穩定度而非音質進行最佳化)，或是回饋迴路(根據裝置訓練取得的機器學習，輸送帶若發出聲音，顯示它可能歪掉了)。物聯網裝置將會變得更複雜且更具智慧，因為這些能力提升後，運算力也會因此增加。在我們使用新的機器學習工具後，一些之前在雲端或終端完成的關鍵功能，將可以移到終端本身的內部進行。

終端 AI：千里之行始於足下

從智慧型手機到車輛，今日所有電子裝置的核心都是許多的處理器、微控制器與感測器。它們執行各種任務，從最簡單到最複雜，並需要各式各樣的能力。例如，應用處理器是高階處理器，它們是為行動運算、智慧型手機與伺服器設計；即時處理器是為例如硬碟控制、汽車動力傳動系統，與無線通訊的基頻控制使用的非常高效能的處理器，至於微控制器處理器的矽晶圓面積則小了許多，能源效率也高出很多，同時擁有特定的功能。

這意味著利用ML工具訓練如MCU等較不複雜元件來執行的動作，之前必須透過威力更強大的元件才能完成，但現在邊緣與雲端則是理想的場所。這將讓較小型的裝置以更低的延遲執行更多種類的功能，例如智慧手錶、健康追蹤器或健康照護監控等穿戴式裝置。

隨著更多功能在較小型的終端進行，這將可以省下資源，包括資料傳輸費用與能源費用，同時也會產生極大的環境衝擊，特別是考量到全球目前已有超過200億台連網裝置，以及超過2,500億顆MCU(根據Strategy Analytics統計數據)。

TinyML、MCU與人工智慧

根據Google的TesnsorFlow 技術主管、同時也是深度學習與TinyML領域的指標人物 Pete Warden 表示：「令人相當興奮的是，我還不知道我們將如何使用這些全新的裝置，特別是它們後面代表的科技是如此的吸引人，我無法想像那些即將出現的全新應用。」

微型機器學習(TinyML)的崛起，已經催化嵌入式系統與機器學習結合，而兩者傳統上大多是獨立運作的。TinyML 捨棄在雲端上運作複雜的機器學習模型，過程包含在終端裝置內與微控制器上運作經過最佳化的模式識別模型，耗電量只有數毫瓦。

物聯網環境中有數十億個微型裝置，可以為各個產業提供更多的洞察與效率，包括消費、醫療、汽車與工業。TinyML 獲得 Arm、Google、Qualcomm、Arduino等業者的支持，可望改變我們處理物聯網資料的方式。

受惠於TinyML，微控制器搭配AI已經開始增添各種傳統上威力更強大的元件才能執行的功能。這些功能包括語音辨識(例如自然語言處理)、影像處理(例如物件辨識與識別)，以及動作(例如震動、溫度波動等)。啟用這些功能後，準確度與安全性更高，但電池的續航力卻不會打折扣，同時也考量到各種更微妙的應用。

儘管之前提到的雲端神經網路框架工具，是取用這個公用程式最常用的方法，但把AI函式庫整合進MCU，然後把本地的AI訓練與分析能力插入程式碼中也是可行的。這讓開發人員依據從感測器、麥克風與其他終端嵌入式裝置取得的訊號導出資料模式，然後從中建立模型，例如預測性維護能力。

如Arm Cortex-M55處理器與Ethos U55微神經處理器(microNPU)，利用CMSIS-DSP與CMSIS-NN等常見API來簡化程式碼的轉移性，讓MCU與共同處理器緊密耦合以加速AI功能。透過推論工具在低成本的MCU上實現AI功能並符合嵌入式設計需求極為重要，原因是具有AI功能的MCU有機會在各種物聯網應用中轉變裝置的設計。

AI在較小型、低耗電與記憶體受限的裝置中可以協助的關鍵功能，我們可以把其精華歸納至我們簡稱為「3V」的三大領域：語音(Voice，如自然語言處理)、視覺(Vision，如影像處理)以及震動(Vibration，如處理來自多種感測器的資料，包括從加速計到溫度感測器，或是來自馬達的電氣訊號)。

終端智慧對「3V」至關重要

多數的物聯網應用聚焦在一些特定的領域：基本控制(開/關)、測量(狀態、溫度、流量、噪音與震動、濕度等)、資產的狀況(所在地點以及狀況如何？)，以及安全性功能、自動化、預測性維護以及遠端遙控(詳見圖 6)。

Strategy Analytics的研究顯示，許多已經完成部署或將要部署的物聯網B2B應用，仍然只需要相對簡單的指令，如基本的開/關，以及對設備與環境狀態的監控。在消費性物聯網領域中，智慧音箱的語音控制AI已經出現爆炸性成長，成為智慧家庭指令的中樞，包括智慧插座、智慧照明、智慧攝影機、智慧門鈴，以及智慧恆溫器等。消費性裝置如藍牙耳機現在已經具備情境感知功能，可以依據地點與環境，在音質優先與穩定度優先之間自動切換。

如同我們檢視的結果，終端AI可以在「3V」核心領域提供價值，而它觸及的許多物聯網領域，遍及B2B與B2C的應用：

震動：包含來自多種感測器資料的處理，從加速計感測器到溫度感測器，或來自馬達的電氣訊號。
視覺：影像與影片辨識；分析與識別靜止影像或影片內物件的能力。
語音：包括自然語言處理(NLP)、瞭解人類口中說出與寫出的語言的能力，以及使用人類語言與人類交談的能力-自然語言產生(NLG)。
垂直市場中有多種可以實作AI技術的使用場景：

震動

可以用來把智慧帶進MCU中的終端AI的進展，有各式各樣的不同應用領域，對於成本與物聯網裝置與應用的效用，都會帶來衝擊。這包括我們在圖6中點出的數個關鍵物聯網應用領域，包括：

溫度監控；
壓力監控；
溼度監控；
物理動作，包括滑倒與跌倒偵測；
物質檢測(漏水、瓦斯漏氣等) ；
磁通量(如鄰近感測器與流量監控) ；
感測器融合(見圖7)；
電場變化。

一如我們將在使用場景單元中檢視的，這些能力有許多可以應用在各種被普遍部署的物聯網應用中。

語音

語音是進化的產物，也是人類溝通非常有效率的方式。因此我們常常想要用語音來對機器下指令，也不令人意外；聲音檢測是持續成長的類別。語音啟動在智慧家庭應用中很常見，例如智慧音箱，而它也逐漸成為啟動智慧家庭裝置與智慧家電的語音中樞，如電視、遊戲主機與其他新的電器。

在工業環境中，供車床、銑床與磨床等電腦數值控制(CNC)機器使用的電腦語音引擎正方興未艾。iTSpeex的ATHENA4是第一批專為這些產品設計的語音啟動作業系統。這些產品往往因為安全原因，有離線語音處理的需求，因此終端 AI 語音發展在這裡也創造出有趣的機會。用戶可以指示機器執行特定的運作，並從機器手冊與工廠文件，立即取用資訊。

語音整合在車輛中也相當關鍵。OEM 代工廠商持續對車載娛樂系統中的語音辨識系統，進行大量投資。語音有潛力成為最安全的輸入模式，因為它可以讓駕駛的眼睛持續盯著道路，而雙手仍持續握著方向盤。

對於使用觸控螢幕或硬體控制器通常需要多道步驟的複雜任務，語音辨識系統特別能勝任。這些任務包括輸入文字簡訊、輸入目的地、播放特定歌曲或歌曲子集，以及選擇廣播電台頻道。其他的服務包含如拋錨服務(或bCall)與禮賓服務。

視覺

正如我們之前已經檢視過，終端 AI 提供視覺領域全新的機會，特別是與物件檢測及辨識相關。這可能包括觀察生產線的製造瑕疵，以及找出自動販賣機需要補貨的庫存。其他實例包括農業應用，例如依據大小與品質為農產品分級。

曳引機裝上機器視覺攝影機後，我們幾乎可以即時檢測出雜草。雜草冒出後，AI可以分類雜草並估算它對農產收穫的潛在威脅。這讓農民可以鎖定特定的雜草，並打造客製的除草解決方案。機器視覺然後可以檢測除草劑的效用，並找出農地中仍具抗藥性的殘餘雜草。

使用場景

預測性維護工具已經從擷取與比較震動的量測資料，進化到提出即時的資產監控。藉由連接物聯網感測器裝置與維護軟體，我們也可能做到遠端監控。

震動分析

這種類型的預測性維護在旋轉型機器密集的製造工廠裡，相當常見。震動分析可以揭露鬆脫、不平衡、錯位與軸承磨損等狀況。例如，把震動計量器接上靠近選煤廠離心泵浦內部承軸處，就可以讓工程師建立起正常震動範圍的基線。超出這個範圍的震動，可能顯示滾珠軸承出現鬆動，需要更換。

磁感測器融合

磁感測器利用磁性浮筒與一系列可以感應並與液體表面一起移動的感測器，測量液面的高低。所有的這些應用都使用一個固定面上的磁感測器，它與附近平面的磁鐵一起作動，與這個磁鐵相對應的感測器也會移動。

聲學分析(聲音)

與震動分析相似，聲測方位分析也是供潤滑技師使用，主要是專注在主動採取潤滑措施。這意味我們可以避免移動設備時產生的過度磨損，否則會為了修理造成代價高昂的停機。實際的例子可能包括測量輸送皮帶的承軸狀況。出現過度磨損時，承軸會因為潤滑不足或錯位出現故障，可能造成整個生產流程的中斷。

聲學分析(超音波)

聲音聲學分析雖然可以用來進行主動與預測性維護，超音波聲學分析卻只能用於預測性維護。它可以在超音波範圍內找出與機器摩擦及壓力相關的聲音，並使用在會發出較細微聲音的電氣設備與機器設備。我們可以說這一類型的分析與震動或油量分析相比，更可以預測即將出現的故障。目前它部署起來比其他種類的預防性維護花費較高，但終端 AI 的進展可以促成這種細微層級的聲學檢測，大幅降低部署的費用。

熱顯影

熱顯影利用紅外線影像來監控互動機器零件的溫度，讓任何異常情況很快變得顯而易見。具備終端 AI 能力的裝置，可以長期檢測微細的變化。與其他對事故敏感的監視器一樣，它們會觸發排程系統，自動採取適當的行動來預防零件故障。

消費者與智慧家庭

將語音運用在消費者與智慧家庭，是最常看到的場景之一。這包括智慧型手機與平板電腦上、未包含電話整合功能的裝置，例如螢幕尺寸有限的穿戴式裝置。這類型的裝置包含智慧手錶與健康穿戴式裝置，可以為各種功能提供免動手的語音啟動。像 Amazon 的 Echo 或 Google 的 Home 等智慧音箱市場的成長，說明消費者對於可接收與提供語音互動等現有裝置的強勁需求，與日俱增。

消費者基於各種理由使用智慧音箱，最常見的使用場景為：

聽音樂；
控制如照明等智慧家庭裝置；
取得新聞與天氣預報的更新；
建立購物與待辦事項清單。

除了像智慧音箱與智慧電視等消費裝置，智慧家庭裝置語音的使用，也顯現相當的潛力。諸如連網門鈴(如 ring.com)等裝置與連網的煙霧偵測器(例如 Nest Protect 煙霧與一氧化碳警報)目前都已上市可供消費者選購，它們結合了語音與視覺的感測器融合功能以及運動檢測。有了連網的煙霧偵測器，裝置在偵測到煙霧或一氧化碳時，可以發出語音警告。

終端 AI 為強化這些能力提供了全新機會，而且常常結合震動(動作)、視覺與語音控制。例如，增加姿態辨識來控制例如電視等家電，或是把語音控制嵌入白色家電，即是以最低成本強化功能性最直接的方式。

健康照護

用來發現醫護資訊的 AI 驅動終端裝置的應用，將為病況的治療與診斷，提供更多的價值。這種資訊可能是資料，也可能是影像、影片以及說出的話，我們可以透過 AI 進行型態與診斷分析。這些資料將引發全新、更有效的治療方法，為整個產業節省成本。受惠於終端 AI 的進展，像 Google Duplex 等語音系統的複雜性將會降低。例如門診預約等勞力密集的工作，也可以轉換成 AI 活動。利用自然語言語音來延伸 AI 的使用，也可以把 AI 用在第一線的病人診斷，然後再由醫師接手提供諮詢。

其他健康照護實例包括像 Wewalk5 等物件，這是一個供半盲與全盲人員使用的智慧拐杖。它使用感測器來檢測胸口水平以上的物件，並搭配 Google Maps 與 Amazon Alexa 等 app，方便使用者提出問題。

結論

由於連網的終端裝置數量越來越多，這個世界也越來越複雜。連接到網際網路的裝置已經超過 300 億個，而微控制器的數量也超過 2,500 億，每年還會增加約 300 億個。越來越多的程序開始進行自動化，不過，把大量資料傳送到雲端涉及的延遲以及邊緣運算的額外費用，意味著許多全新、令人興奮且引人矚目的物聯網使用場景，可能無法開花結果。

解決這些挑戰的答案，並不是為雲端資料中心持續增添運算力。降低出現在邊緣的延遲雖然會有幫助，但不會解決日益分散的世界的所有挑戰。我們需要把智能應用到基礎架構中。

儘管為終端裝置增添先進的運算能力在十年前仍不可行，TinyML 技術近來的提升，已經讓位處相當邊緣的裝置 (也就是終端本身)增添智能的機會大大改觀。在終端增加運算與人工智慧能力，可以讓我們在源頭搜集到更多更具關聯性與相關的資訊。隨著裝置與資料的數量持續攀升，在源頭掌握情境化與具關聯性的資料，具有極大的價值，並將開啟全新的使用場景與營收機會。

終端裝置的機器學習，可以促成全新的終端 AI 世界。新的應用場景正在崛起，甚至跳過傳送大量資料的需求，因而紓解資料傳輸的瓶頸與延遲，並在各種作業環境中創造全新機會。終端 AI 將為我們開啟一個充滿全新機會與應用場景的世界，其中還有很多我們現在想像不到的機會。

附圖：圖1：從集中式到分散式運算的轉變。
(資料來源：《The End of Cloud Computing》，by Peter Levine，Andreessen Horowitz)
圖2：全球上網裝置安裝量。
(資料來源：Strategy Analytics)
圖3：深度學習流程。
圖4：MCU的視覺、震動與語音。
(資料來源：意法半導體)
圖5：AI 工具集執行模型轉換，以便在MCU上執行經最佳化的神經網路推論。
(資料來源：意法半導體)
圖6：物聯網企業對企業應用的使用-目前與未來。
(資料來源：Strategy Analytics)
圖7：促成情境感知的感測器融合。
(資料來源：恩智浦半導體)

資料來源：https://www.eettaiwan.com/20210303nt31-the-dawn-of-endpoint-ai-bringing-compute-closer-to-data/?fbclid=IwAR0JTRpNsJUl-DmSNpfIcymGQpkQaUgXixEaczwDpELxGCaCeJpkTyoqUtI

佈署 IoT Edge 和霧運算技術以開發智慧建築服務

2021年2月19日 星期五

《3S MARKET》這篇報導把物聯網的架構與實作，描寫的非常詳細，雖然在建築的細節上描述不多，但報導中也提及這是個實際驗證，可適用在很多的場域。不知道，有多少人真正看得懂？當然，連這篇都看不懂的人，就別說他真正了解物聯網、Edge 與 Cloud。

事實上這篇報導的描述不難了解，真正物聯網與邊緣運算的挑戰，是在實作。實作真正面臨的，是這些數據處理、融合、分析上的完整度，還有 —— 找到實作的場景！

摘要

基於 SoC 架構的嵌入式系統的進步，使許多商業設備的開發變得足夠強大，足以運行操作系統和複雜的算法。這些設備整合了一組具有連通性、運算能力和成本降低的不同感測器。在這種情況下，物聯網（IoT）的潛力不斷增加，並帶來了其他發展可能性：「事物」現在可以增加數據源附近的運算量；因此，可以在本地系統上，佈署不同的物聯網服務。

這種範例稱為「邊緣運算」，它整合了物聯網技術和雲端運算系統。邊緣運算可以減少感測器與中央數據中心之間，所需的通信頻寬。此方法需要管理感測器、執行器、嵌入式設備，和可能不連續連接到網路的其他資源（例如智慧手機）。這種趨勢對於智慧建築設計非常有吸引力，在智慧建築設計中，必須整合不同的子系統（能源、氣候控制、安全性、舒適性、使用者服務、維護和營運成本）以開發智慧設施。在這項工作中，分析和提出了一種基於邊緣運算範例的智慧服務設計方法。

這種新穎的方法，克服了現有設計中與服務的互操作性，和可伸縮性有關的一些缺點。描述了基於嵌入式設備的實驗架構。能源管理、安全系統、氣候控制和資訊服務，是實施新智慧設施的子系統。

1. 簡介

建築自動化系統使用開放式通信標準和介面，可以整合多種不同的建築控制規則，例如供暖、通風、空調、照明和百葉窗、安全功能和設備。但是，現有建築物通常不具有這些系統。

通常，每種安裝類型都提供特定的服務：供暖通風和空調（HVAC）控制氣候服務，攝影機和感測器提供安全服務等。僅當設計能源管理系統時，不同的子系統相關，但僅透過以下方式，連接建築物的能源管理系統。能源管理服務，集中在專用軟體中。

對於使用者和維護技術人員來說，提供不同服務的不同製造商，發現很難整合新的服務和功能。自動化建築將用於控制和數據採集的軟體，與工業協議和介面整合在一起。此外，將新服務整合到這種解決方案中並不容易，這取決於已安裝軟體的開發。

這些工業發展還為能源管理，提供了雲端連接解決方案和智慧服務。這些服務，也在集中式電腦系統中開發。數據被傳輸到這些系統或雲端進行分析。本文提出使用佈署在物聯網（IoT）技術中的邊緣和霧運算範例，主要有兩個目的：

A. 在自動化和非自動化建築物中，促進新的智慧和可互操作服務的整合（整合）。

B. 允許在建築物的所有子系統之間，分配智慧服務（互操作性）。

透過該建議，可以促進建築物子系統之間的關係。它還促進創建新的智慧服務（例如，新的分佈式智慧控制算法；使用電源管理捕獲的數據，來檢測人類活動；捕獲設備連接的模式辨識，運算可再生電力預測，在安全服務中使用電力數據等）。在這項工作中，我們設計了一個中間軟體的體系結構，該體系結構具有兩個主要層，這些層基於嵌入式設備、IoT 通信協議和硬體支援，來開發人工智慧算法（圖1）。

為了實現這一目標，我們在建築物的設施中添加了兩個概念等級：邊緣節點和霧節點。每個等級都有不同種類的設備和功能。我們佈署並實現了基於層的中間軟體的體系結構，以對模式進行實驗。

本文的組織結構如下：第 2 節回顧了智慧建築技術，建築物中的 IoT 佈署以及邊緣運算範例。第 3 節提出了一種在建築物（自動與否）中佈署邊緣和霧運算範例的方法。第 4 節介紹了進行的實驗。最後，第 5 節介紹了結論和未來的工作。

2. 相關工作

本節介紹與這項工作相關的主要研究領域。首先，我們在分析雲端運算層之後，回顧了基於邊緣運算範例的資源和服務供應。最後，我們研究了實現智慧建築的技術，並在最後的小節中，總結了先前研究的貢獻。

2.1. 邊緣運算資源和服務供應

最近，網路在兩端被標記為「邊緣」和「核心」，以查明處理發生的位置。邊緣端靠近數據源和使用者，核心端由雲端伺服器組成。透過這種方式，邊緣運算範例將運算推送到 IoT 網路的邊緣，以減少數據處理延遲，和發送到雲端的數據數量。基於雲端的後端，可以處理對時間不太敏感，或源設備本身不需要結果的處理請求（例如，物聯網網路狀態下的大數據分析）。

在邊緣運算資源供應方面，正在進行的 Horizo​​n 2020 RECAP 項目，提出了一種整合的雲端 - 邊緣 - 霧端架構，目的在解決應用放置、基礎架構管理和容量供應。雲端/邊緣基礎架構監控功能豐富了應用，基礎架構和工作負載模型，這些模型又被回饋到優化系統中，該系統可以協調應用並持續配置基礎架構。

徐等人進行的研究。 提出了一種用於邊緣運算的實用感知資源分配方法，稱為 Zenith。借助 Zenith，服務提供商可以與邊緣基礎設施提供商，建立資源共享合同，從而允許延遲感知資源調配算法，以滿足其延遲需求的方式，來調度邊緣任務。

邊緣節點資源管理（簡稱 ENORM），是管理邊緣/霧節點資源的框架，可透過監控應用需求，來自動擴展邊緣節點。可以透過靜態優先等級分配，來確定特定應用的優先等級。供應和自動縮放機制，是基於線性搜索的相對簡單的實現。

當源本身是可行動的時，邊緣雲範例也是可行的。 Chen 等人研究了行動設備向邊緣節點（特別是在無線電接入網路邊緣）的智慧運算分流。在這項工作中，作者提供了任務卸載算法，將分佈式運算卸載決策表述，為多使用者運算卸載功能。在同一項工作中，Wang 等人研究了聯合協調卸載任務，到多個邊緣節點的問題，並提出在邊緣等級引入及准入控制，以及兩階段調度方法，與傳統的最近邊緣選擇方法相比，改進了卸載性能。

2.2. 雲端運算服務配置

就社會和行業採用資訊技術而言，雲端運算範例是最具創新性的策略之一。提供的優勢提高了效率，並降低了成本，同時提供了可透過 Internet，普遍存取訪問的按需 IT 資源和服務。

當前，雲端運算服務種類繁多，甚至如何提供，這是一個受到廣泛研究的主題，正在提出許多的方案。甚至有評論總結了雲端運算範例的相關研究。

本小節介紹了有關以下問題的先前工作，這些問題與本手稿的主題有關：（i）安全性； （ii）服務品質（QoS）； （iii）提供邊緣服務。

（i）安全是雲端運算中一個具有挑戰性的問題。雲端服務位於應用環境之外，並且超出了防火牆的保護範圍，因此，需要附加的安全層。另外，邊緣和霧運算應用的行動性和異構性，使得難以定義單個過程。因此，需要一種分佈式安全策略。

此外，必須有一個標準化的環境，才能正確解決此問題，並指定霧運算和邊緣設備，如何相互協作。網路邊緣上的多個霧節點之間的敏感數據通信，需要資源受限的事物的輕量級解決方案。另一個與安全性相關的問題是數據位置。在雲端中運行數據分析是很常見的。因此，關於數據安全或隱私的公有雲與私有雲的爭論就出現了。

（ii）分配給雲端應用的資源，通常是根據合同規定的服務水準協議（SLA）所設置的。但是，實際上，由於偶爾執行大量事務，而導致分配的基礎結構飽和，可能會出現瓶頸。為了解決此問題，可以在資源可用時，動態擴展雲端基礎架構。當前，最具創新性的趨勢，目的在建構自動 SLA 合同合規系統。在 Faniyi 和 Bahsoon，以及 Singh 和 Chana 進行的研究中，可以找到與品質服務管理相關建議的詳盡綜述。考慮到這一點，提出了幾種策略來預測，應用的資源需求和 QoS 的要求。最近的工作試圖將安全性和 QoS 問題結合起來，以提供全面的性能指標。

（iii）最後，濫用雲端服務，是該領域的另一個問題。物聯網環境是霧和邊緣設備不斷加入或離開，動態的執行前後關聯。因此必須在網路邊緣提供彈性的服務。為此，在網路的可用設備之間，共享應用工作負載，可以為高階運算應用提供靈活性。提出了可靠的服務供應方法，來為系統提供更高的彈性，並提供靈活和優化的雲端服務。

在本主題中，將雲端框架和中間軟體技術，設置為與雲端層，以及具有不同介面操作系統，和體系結構的設備之間，進行通信的平台。

2.3. 物聯網在建築服務工程中

物聯網開發為在建築物上，開發數位服務提供了新資源。建築物中常見的物聯網應用，包括節能的過程環節、維護改進、雜務自動化和增強安全性。由於全球變暖，建築物的節能是一個重要的課題。

物聯網技術引入智慧建築，不僅可以減少本地溫室氣體排放，還可以將減少溫室效應擴大到更大的領域。目前，物聯網還被用於建築領域，以協助設施管理。物聯網使營運系統能夠提供更準確和更有用的資訊，從而改善營運，並為房客租戶提供最佳體驗。有基於物聯網的建議，這些建議顯示建築系統，如何與雲端進行通信，並分析所獲取的數據，以開發新的業務見解，從而能夠推動真正的增值和更高的績效。

實驗研究顯示，物聯網平台不僅可以改善，工業能源管理系統中實體的互連性，而且可以降低工業設施的能源成本。 FacilitiesNet 表示，建築物聯網（BIoT）正在推動我們獲取資訊，彼此互動和做出決策的方式發生重大轉變。BIoT 不僅與連接性或設備數量有關，而且還與交付實際和相關結果有關。當前，有很多基於物聯網的智慧家庭應用的例子。

然而，智慧設備或「物」，僅僅是連接到網路的設備或嵌入式系統。增值來自設計協調系統，和提供智慧服務，以提供實際收益的能力。這些特徵基本上，取決於對不同類型連接事物的異質性，及其互操作性的管理，並取決於數據處理提供的情報潛力。

Tolga 和 Esra 進行的研究得出的結論是，就智慧家庭系統中的軟體和硬體而言，物聯網技術尚未變得穩定。原因之一，有可能是物聯網技術仍處於發展階段。McEIhannon 所撰寫有關物聯網應用的邊緣雲和邊緣運算的未來，其評論得出了類似的結論。這篇評論提到概念和發展，目前還處於早期階段，從學術和行業的角度來看，許多挑戰都需要解決。

物聯網帶來了新的機會，但許多企業仍在尋求了解和分析，其將如何影響，並與現有的 IT 結構和管理策略整合。為此，必須創建專門的使用模式和技術，來彌合這一差距。

2.4. 發現

以下結論闡明了這項研究建議的新穎之處：

雲端運算作為「實用」的一般概念，非常適合智慧家庭應用的常規需求。但是，在某些情況下，將所有運算都移到雲端中，是不切實際的。

邊緣計算作為一種計算範例而出現，可以在物聯網設備生成的數據附近執行計算。這種範例可能有助於滿足最新應用的安全性和 QoS 的要求。

當前，控制子系統的高級建築設施，通常使用 Internet、IoT 協議和 Web 服務。專有系統是使用標準的 Internet 通信協議設計的，用於管制和監控。先前的工作顯示，基於無線感測器網路、Web 介面和工業控制模式，用於氣候控制、電源管理或安全性的控制系統，使用不同的監視和控制技術。監控應用分析，得自監控和數據採集系統中的這些子系統。對於不同的子系統，有不同的解決方案。考慮到上述情況，本工作中提出的模式，引入了以下新穎元素：

A. 介紹了一種分層架構（整合了邊緣和霧端等級），以及提供子系統之間互操作性，以及在建築物控制中開發智慧服務的方法，該方法使用了邊緣和霧端範例，這些範例將 IoT 協議整合在一起，並在本地 Intranet 中操作 AI 技術，讓雲端服務的通信層，完善了該層的架構。

B. 介紹了一種基於使用者為中心的方法，用於在互操作性需求下設計、驗證和改進新服務。

C. 該提案允許使用可以在已建的建築物中，實施的非專有硬體和軟體系統。

3. 計算模式設計

建築物中的設施子系統分為有照明、氣候、能源、安全、警報、電梯等。在自動化建築中，這些子系統由專門的控制技術控制和監控。在非自動化建築物中，不存在這些服務，並且子系統透過電子和電氣方式進行控制。在這兩種情況下，所有子系統都為建築營運，提供必要的服務。

從邏輯上講，每個子系統都在其場景中起作用，並且不能與其他子系統互操作。嵌入式電子控制器和連接的不同感測器，可以使每個子系統自動化。這些服務都是基於直接反應性控制規則。除了嵌入式控制系統和感測器之外，通信技術（基於 Internet 協議）和新的行動設備還為開發管制、監控和數據訪問服務，提供了新的可能性。

在智慧型動設備上開發，並連接到 Web 伺服器的人機介面和專用應用，是近年來已實現的服務的範例。每個子系統中的專家（氣候、安全性、電源等），都具有可以轉換為專家規則的知識。這些規則被轉換為用於管理、維護、控制、優化和其他活動的控制算法。這些規則是可以，在可程式設備上編程和實現的。但是，它們是靜態的，不會在出現新情況時發生變化，並且不能互操作，也無法適應每個安裝的特性。

例如，氣候或安全專家決定，如何使用標準啟動條件，來配置每個子系統。每個控制規則僅在一個子系統（此範例中為氣候或安全性）中工作，因此，這些子系統之間沒有互操作性。考慮到這種情況，提出的模式有助於並允許，基於不同子系統的互操作性，來整合新的數位服務，並將人工智慧（AI）技術的新服務，引入當前設施。

例如，諸如電梯控制的設施，可以用於安全服務或建築能源管理服務。氣候控制設施，可以與安全子系統整合在一起。整合到模式中的天氣預報軟體系統，可以由能源管理服務，或建築物空調服務使用。

目的是讓每個子系統中的專家，參與設計整合服務，並將所有子系統轉換為可互操作的系統。該模式會開發自動規則，並允許在考慮安裝行為本身的情況下進行決策。該模式基於一個過程，該過程包括四個開發階段（圖2）和分為不同級別的硬體 - 軟體體系結構（圖3）。該體系結構的主要等級，是邊緣等級和霧等級。這兩個層次介紹了在建築物中，應用物聯網技術的新穎性。下面介紹了模式的各個階段（分析、設計、實施和啟動）。

．分析：在此階段確定了不同的專家使用者（氣候、安全、電力、水、能源、管理人員，以及資訊和通信技術（ICT）技術人員）。諮詢專家使用者，以指定需要控制的主要過程。資訊通信技術專家作為整合環節，參與了這一過程。第一種方法產生了設計控制規則，和潛在服務所需的事物（對象）。在此階段，使用以使用者為中心的方法，並捕獲子系統的需求。

．設計：我們提出了一個三層架構（邊緣、霧端和雲端），如圖 3 所示。

．實施和數據分析：在此階段中已安裝和整合了子系統。服務基於每個子系統中的規則，分析事物（對象）生成的數據，以設計基於機器學習的服務。

．啟動：最初，在每個子系統的監督下制訂專家規則。然後，使用回饋過程安裝規則。最後，透過人工智慧技術，可以推斷出自動的和經過調整的規則。

3.1. 分析與設計

專家使用者對此過程，進行不同的審查。以使用者為中心的技術，用於設計整合流程。目的是獲得所需的所有事物（對象），它們之間的關係，以及潛在的服務。一旦指定了事物（對象）和服務，就必須關聯通信協議和控制技術。選擇了物聯網協議和嵌入式控制器；提出了人機介面；指定了邊緣層和霧層及其功能；分析專家規則和智慧服務。最後，提出了維護和操作方法。所有這些任務在專家技術人員，和資訊技術專家之間共享。

結果是事物的定義，它們之間的關係，以及與邊緣和霧層的交互作用。該過程中代表了建築物的所有子系統，數據感測器、執行器、控制器、規則和過程經過設計，可以整合所有子系統。數據集、對象和設備，由物聯網概念表示。事物由具有狀態和配置數據的實體，和前後關聯組成。事物數據位於霧和邊緣節點中，儲存的不同配置中的關聯性。

事物以數據向量表示：[ID、類型、節點、前後關聯情境]。

– ID是辨識碼。

– 類型可以是感測器、執行器、變量、過程、設備、介面、數據儲存，或可以在 IoT 生態系統中寫入、處理、通信、儲存或讀取數據的任何對象。

– 節點指定建築物子系統、功能描述、層類型（邊緣、霧端、通信或雲端）、IoT 協議和時程存取訪問。

– 前後關聯表示在 IoT 生態系統中，用於發布或讀取數據的時間、日期、位置，與其他事物的關係、狀態和訪問頻率。

表 1 是由事物（[ID、類型、節點]）。所有事物都可以訪問配置文件（CF），以了解如何使用可用數據，以及如何使用適當的訪問權限配置新數據。前後關聯數據位於內建記憶體，或是靜態儲存。使用定義的事物，設計不同的控制規則。這些控制規則是分佈在連接到網路的不同嵌入式系統中，控制過程的一部分。事物表示佈署在安裝的不同子系統中，所有的可用資源。在此等級上，設計師對所有事物進行分析、指定和關聯。基本控制算法是使用此資訊實現的。配置關聯性允許層和設備之間，所有事物的互操作性。

在此階段的另一級設計，必須提出物聯網管理中，使用的節點要求和規範。設計的流程和服務，將在邊緣或模糊節點中實施。必須指定每個節點，以確定其內部功能、通信及其服務。在獲取數據的地方，開發了智慧和處理能力。邊緣和霧層的節點，位於數據感測器、執行器和控制器附近。本文提出的方法，使用具有兩個功能的兩層（邊緣和霧端）。每一層都可以佈署互連節點的網路，以促進互操作性。

邊緣和霧層的功能是：

邊緣層功能：在連接感測器/執行器的嵌入式設備上，開發的控制軟體。某些 AI 算法可以安裝在邊緣節點上。中央處理器（CPU）和計算資源有限。安裝了通信介面，以允許在本地網路中進行整合。

霧層功能：局域網級別的通信、AI 範例、儲存、配置關聯性和監控活動。霧節點透過處理、通信和儲存，來處理 IoT 的Gateway、伺服器設備，或其他設備中的數據。在此等級實施本地、全球的整合服務。利用這些節點的硬體、軟體和通信功能，開發了基於機器學習範例的算法。霧層設備還可以在很少單位的設施或服務中，執行邊緣節點功能。

透過這兩個等級，可以優化建築設施，以獲得不同子系統之間的整合和互操作性。

表 1 顯示了每件事與關聯性配置，和節點規範的關係。節點標識其所屬的子系統（控制、能源、氣候等），層（霧端、邊緣、通信和雲端）及其執行的功能。

3.2. 架構設計

在分析和設計階段，獲得對象（事物）及其關係。規範和要求用於實現每個層。實施取決於提供所需功能的設計，和現有技術（硬體、通信和軟體）。在此階段，開發了一種適合現有設施的體系結構。物聯網協議提供互操作性，而 AI 範例則提供了適應性和優化性。邊緣運算節點用於控制設備，霧運算節點安裝在本地網路節點上。這些等級為配置、安裝和運行新流程，提供了強大的資源。

物聯網協議，傳達所有子系統數據。每個子系統由對象/事物（虛擬等級）組成，安裝為可連接的感測器/執行器/控制器設備（硬體等級）。

物聯網通信中，針對建築場景建立的要求是：標準協議、低功耗、易於存取訪問和維護、支援整合新模組，非專有硬體或軟體，以及低成本設備。

MQTT 協議，是目的在用於提供整合和互操作性資源，異構通信場景的主要物聯網協議之一。該協議被提議作為感測器、執行器、控制器、通信設備，和子系統之間的通信範例。

MQTT 協議的一些主要功能，在不同的著作中有所顯示，這使其特別適合於這項研究。他們之中有一些是：

．它是針對資源受限的場景開發的發布 - 訂閱消息協議。

．它具有低頻寬要求。

．這是一個非常節能的協議。

．編程資源非常簡單，使其特別適合於嵌入式設備。

．具有三個 QoS 等級，它提供了可靠和安全的通信。

MQTT 開發了無所不在的網路，該網路支持 n-m 節點通信模式。任何節點都可以查詢其他節點，並對其進行查詢。在這些情況下，任何節點都可以充當基地台的角色，能夠將其資訊傳輸到遠端處理位置。無處不在的感測器網路（USN）中的節點，可以處理本地數據。如果使用 Gateway，則它們具有全局可訪問性；他們可以提供擴展服務。

節點（邊緣或霧），可以具有本地和全局存取訪問權限。這些設施具有不同的可能性和益處。本地數據處理，對於基本過程控制是必需的，而全局處理則可用於模式檢測和資訊生成。從這個意義上講，擬議的平台使用了組合功能：連接到 IoT 雲端服務，本地網路區域上不同的 USN。在這種情況下，運算層（邊緣或模糊等級）將用作控制流程和雲端服務之間的介面。該層可以在與雲端進行通信之前，進行處理數據。

實現邊緣和霧端運算節點需要執行三個操作：

．連接和通信服務：所有設備必須在同一網路中，並且可以互操作。所有感測器和執行器都可用於開發服務。此活動的一個示例，是在 Internet 上遠端讀取建築物的電源參數、環境條件和開放的天氣預報數據。此活動中應實現其他功能，例如連接的安全性、可靠性和互操作性。

．嵌入式設備（邊緣運算層）中的控制算法和數據處理：在此活動中，這些設備中實現的基本控制規則和數據分析服務，可以開發新功能。此階段可以應用於數據過濾、運算氣候數據或分析功耗、直接反應控製，或使用模式辨識技術檢測事件。

．Gateway 節點（霧運算層）上的高階服務：此等級使用和管理 AI 範例，和 IoT 通信協議。霧運算節點對數據執行智慧分析，對其進行儲存，過濾並將其傳遞到不同等級，以糾正較低級別的新控制措施，或者生成雲端中服務感興趣的資訊。此階段的應用示例，包括分析新模式、預測用水量，或功耗、智慧檢測和其他預測服務。

3.3. 測試與回饋

在測試階段使用標準方法，邊緣和霧層提供不同的功能。提出了針對不同子系統的機器學習模式，並且可以將其安裝在邊緣或霧節點上。必須執行以下操作，來測試機器學習應用：

A. 定義和捕獲數據集：必須辨識、捕獲和儲存主要變量。在不同的建築子系統中，過程數據集是由連接到邊緣層的感測器捕獲的數據。使用通信協議監控和儲存數據集。一個案例是電表，該電表在配電盤中連接到嵌入式設備（邊緣節點），該嵌入式設備傳送電力數據，以在霧節點設備中儲存和處理。

B. 訓練數據集和形式辨識模式。先前數據集的一個子集，用於訓練不同的模式。評估針對從未用於訓練的數據測試模式，此過程的結果已由專家使用者驗證。目的是獲得一組代表性的結果，以了解模式在現實世界中的表現。

C. 實際場景中的驗證：必須在邊緣和霧節點上，實施新的服務和控制算法。這些模式具有用於分析數據，實施特定模式，並使用結果開發最佳參數的算法。在此階段，可以修改或進行改善模式。

D. 用統計術語和模式演變，得出測試結果：基於 AI 算法的模式而將產生近似值，而不是精確的結果。分析應用結果以確定置信度，並允許模式演化。該活動支持開發新的 AI 服務，或對已實現的算法進行修改。有監督的自動更改，是維護和改進系統的過程。此階段的過程，包括所有模式層。

建議對使用邊緣和霧，任何的安裝進行這些活動。如前所述，該模式既可以安裝在既有舊的建築物中，也可以安裝在新建築物中。對於新建築設計，基於建議模式的安裝更易於整合。此外，可以提供的服務的潛力，也使其對於既有建築物具有吸引力。

4.在建築子系統中，實施智慧服務

該模式在預先存在的住宅建築物上，進行了測試。設計和實施電源管理、管制和監控服務。物聯網協議（MQTT 和 HTTP）和 ML 範例，用於建議的層體系結構。基於 KNN 的機器學習方法，和樹決策算法用於管理功耗（家用電器），和可再生能源發電（風能和太陽能）。使用房屋中的霧節點，在雲端平台上實現監控和統計數據。該節點連接到控制可再生，和家用電器子系統的不同邊緣節點。

在圖 6 中，邊緣節點，整合在先前安裝的可再生子系統中。透過邊緣層上的這種新設備、電源管理、安全控制和操作流程得以整合，並且可以與其他子系統互操作。可以設計新的智慧服務。邊緣節點將數據傳輸到霧節點 Gateway，該 Gateway 管理功耗和發電，並控製家用電器。該節點中的輸入，是可再生能源發電的數據。輸出控件是 ON-OFF 開關，用於優化發電、安全性和操作。

4.1. 分析與設計

分析了住宅建築，以設計電源管理，安全和控制服務。 在第一種方法中，所需的主要事物（對象），它們之間的關係和不同的服務，如表 2 所示。

4.2. 執行

分析房屋中的建築子系統，以整合這個執行模式層：邊緣控制、霧服務，與雲端的通信和雲端服務。 選擇了本實驗工作中使用的感測器、執行器和控制過程（事物）。 表 3 列出了使用的嵌入式設備。

家庭服務中的控制過程，需要反應時間和互操作性。人機介面、數據存取訪問和分析服務，是本地和雲端運算上的服務。上面提到的兩個需求，都使用不同的協議處理：控制/通信上的 MQTT，和雲端服務上的 HTTP（RESTful API）是用於整合，並使所有子系統互操作的 IoT 協議。在提出的該層模式中，還使用 MQTT 協議、控制、數據處理，以及使用 RESTful 協議，到雲端的數據通信，來開發機器對機器（M2M）應用。

MQTT 使用開放的消息協議，該協議可以將遙測樣式的數據（即在遠端位置收集的測量結果），以消息的形式，從設備和感測器，沿著不可靠或受約束的網路傳輸，到伺服器（BROKER）。消息是簡單、緊湊的二進制數據包，有效載荷（壓縮的標頭，比超連結傳輸協議（HTTP）少得多的詳細資訊），並且非常適合推送簡單的消息傳遞方案，例如溫度更新或移動通知。例如，消息也可以很好地用於，將受約束的或更小的設備，和感測器連接到 Web 服務。

MQTT 通信協議，使所有對象可以互操作。透過此協議實現的發布者和訂閱者模式，可以互連所有設備和事物。該通信層由安裝在霧節點上的代理設備管理。不同的發布者和訂閱者，在不同的節點上實現。安裝了一個 Gateway 設備（霧節點）和兩個嵌入式控制器（邊緣節點），來控製家用電器和電源管理。事物和流程佈署在所有節點上。

邊緣節點控制子系統，霧節點根據決策樹，以及專家定義的規則，實現 AI 範例。霧設備將數據傳輸到雲端平台，以開發儀表板螢幕，來監看子系統的狀態。

可以開發新的雲端平台服務：事件檢測、機器學習處理、統計分析等。專家使用者設計基本的控制算法。在學習和訓練過程之後，將根據專家系統的結果，對這些算法進行調整和修改。在這項工作中，目標是在不損失生產力的情況下優化資源（控制和能源）。在邊緣或霧節點中，執行不同的控製過程；分類過程和決策樹在霧節點中實現。算法以 Python 語言實現。此語言的開源庫用於不同的應用。

4.3. 佈署與測試

對於現有建築物，邊緣節點交錯插入已安裝的控制器、配電板，以及感測器和執行器中。如果在分析階段指定了新的東西（電錶、氣候和控制器），則會安裝一些新的感測器/執行器。這項工作中佈署的邊緣節點具有以下優點：

．請勿干擾先前的安裝操作。

．他們使用新的專家規則和自動規則，引入新控件。

．他們測試和重新配置，在分析、學習和測試驗證中，設計更新的專家規則。


圖 7. 佈署在配電盤中的節點。 使用 IoT 協議通信，在不同節點中開發數據捕獲、控制算法、數據分析、儲存和通信服務

在電力管理過程中，專家使用者根據電力消耗、發電量、消耗負荷曲線、氣候數據和氣候預測數據，對具有選定流程的時間表，進行可程式處理。邊緣節點捕獲數據，並將其發送到霧節點。

霧節點處理室內和室外環境的日記數據，以及天氣狀況。霧節點還可以捕獲其他感測器數據。對房屋中的這些數據消耗和生成方式，進行檢測和分類。消費和發電結果，作為數據添加，以便與儲存的數據一起進行分析。可以使用機器學習方法開發，作為家用電器或人類活動檢測的智慧服務（圖8）。

4.3.1. 機器學習：數據捕獲過程（邊緣節點）和家用電器分類（霧節點）

連接在主配電盤中的電表，用於捕獲數據，並使用標準的 K 近似值，最近鄰（KNN）分類算法，來開發形式辨識模式。 KNN 是機器學習系統中最常見的方法之一。電表捕獲電流；如果連接了新的家用電器，則電流數據會更改。不同的家用電器具有不同的變化等級。

用於辨識家用電器的不同模式的主要變量，是連接時的電流水準差異。數據捕獲過程流程圖（圖9），顯示了在邊緣節點中實現的算法，以捕獲預處理並傳遞電力數據。

在此過程中，監督階段使用訓練數據集。接下來，真實場景中的驗證，將測試分類模式。家用分類設備將用於不同的服務：人類活動的辨識、負載控制、可再生能源管理、空調、安全性等。在訓練階段，已捕獲了不同的家用電器開機，以獲得一組形式。每個家庭都有一個矩心向量，將用於分類過程中的檢測。如上面所示的算法所示，分類器處理將產生連接時的電流數據作為輸入。KNN 分類過程流程圖（圖10）描述了 KNN 方法，它在霧節點中實現。

4.3.2. 可再生電源管理。控制電力自耗的決策樹

每個建築物都有不同的需求曲線，以及在接入電網方面的特定情況。為此，整合和可互操作的設施，可以實施適用於每種情況的不同解決方案，從而提供對太陽風資源的最佳管理，優化電源效率，簡化管理流程，並實現最高的成本節省。當可再生能源超過消耗的能源時，在使用 AC 耦合到電網的設施中，會出現問題。

在實驗工作中，太陽能在一天的中央時段的能量，大於所消耗的能量（圖11）。但是，在分析了消耗曲線之後，可以在這段時間內連接負載，以避免注入電網。可以透過設計一種算法，來滿足這一要求，該算法可以預測，何時發生此事件，以自動連接不同的負載。利用所有感測器和執行器的整合，和互操作通信，已經開發了在不同節點中，所實現的算法（圖12）。

13. 在電源管理子系統上開發的決策樹。 它由專業使用者設計，並整合在邊緣節點上。該決策樹的目的，在優化可再生能源的使用。

4.3.3. 基於 Edge 和 Fog 節點的 Control Home

圖 14 顯示了安裝在住宅房間中的邊緣節點。 該節點可以控制四個設備（設備），並捕獲感測器數據（功耗、發電量、溫度、濕度等）。該設備可以使用 MQTT 協議進行通信。該協議允許設備之間，進行其他類型的通信：智慧手機、新邊緣節點等。圖 7 和圖 14 顯示了可以在其他建築物中，佈署的標準實現。在所有系統中，都有配電板，這些配電盤佈署了霧節點和邊緣節點，如圖所示。

4.3.4. 使用物聯網協議的雲端服務

雲端服務可以監控，透過霧節點或人機介面（HMI）訪問的數據。 IoT 協議（MQTT）從任何已連接 Internet 的設備推送數據。事件檢測、儲存統計分析等其他服務，完善了該資源的功能。提供類似服務的不同平台，顯示了商用物聯網技術的狀態：Amazon IoT、Microsoft Azure、Ubidots 和 Thingspeak，是提供 IoT 平台的公司一些案例。提供了資源以及客戶端，和 IoT 平台之間的應用程式介面（API）通信，以便可以使用它們。

用於設計儀表板監控和管制的 HMI 資源，是這些平台上的主要實用功能之一。霧節點使用雲端 API 傳達數據和資訊，可以實施其他控制服務。在這些雲端平台上，預先建構了用於監控數據的儀表板設計。使用 API​​ 實用功能，霧節點中的過程處理，會將數據發送到每個儀表板。API 文件指定了在設備、IoT 平台和 Mobile-Alerts Cloud 之間，交換數據的結構，以及用於加速項目的代碼案例和形成資料庫。

圖 15 顯示了在 Ubidots 雲平台上，設計的儀表板。Ubidots是本實驗工作中使用的物聯網平台。該模式可以在實現這些協議的層，和平台中使用不同的標準協議。圖 16 顯示了在雲端平台中，IF 變量 THEN 動作的事件配置。大多數物聯網平台，都提供此功能。

5. 結論

為了設計物聯網系統，越來越多地提出邊緣霧模式。但是，每個範例都提供特定應用領域的解決方案。不同子系統之間的整合和互操作性，可以改善這種情況，並提供更好的服務。這項工作的主要目的，是透過提出一種基於邊緣層和霧層，兩層體系結構的運算模式，來解決這個問題。透過這兩層，可以基於使用邊緣或霧節點中，嵌入式的設備捕獲數據所產生的新型有用資訊，來設計和開發新服務。這些節點使用雲端平台和 IoT 協議（例如 MQTT）。

MQTT 是作為不同層（霧 – 邊緣 – 雲）之間提出的通信協議，並進行實驗的。雲端平台用於開發儀表板的面板資訊和 Internet 上的新服務，例如控制、儲存和通信事件。該平台可用於透過 API，交付不同的服務。

該模式可以在現有建築物和新建築物中，開發這些服務。在這種情況下，要求每個子系統中的專家和專業人員，參與新服務的設計。

為了測試該模式的功能，並顯示如何在實際設施中，實現該模式，在住宅中進行了一項實驗性工作。在此霧和邊緣節點前後關聯中，描述了實現的幾個範例。開發了模式辨識和決策樹方法，以展示人工智慧在設計 IoT 解決方案中的潛力。已安裝服務的結果顯示，邊緣和霧節點佈署，產生了預期中整合和互操作性的好處。

提出的工作演示了，如何將邊緣和霧範例，整合到可以增強其優勢的新架構中，從而擴展了應用領域。該體系結構的主要科學貢獻，是整合、技術的互操作性，及其為開發 AI 服務提供的設施的範例。所有這些改進，都在已開發的實驗的不同示例中顯示。具體的優化和改進，將在以後的工作中進行。此外，使用機器學習平台，和 AI 範例的新控制規則，將確保可以創建和改進新的智慧服務。

附圖：圖1.自動建構子系統和資訊技術環境。
圖2.基於使用者為中心關係的模式。
圖3.通信架構。 每個等級都有不同的功能。 提出了兩個通信等級：IoT（使用消息隊列遙測傳輸（MQTT））和 Web（使用代表性狀態傳輸（REST）協議）。這些協議的層，涵蓋了已建立的整合和互操作性要求。
圖4. 在建築物的現有設施上實施的邊緣霧架構示例：邊緣節點是較低的層次，必須與安裝的設備進行新連接。互連所有子系統的霧節點，是透過整合連接到邊緣節點的新設備來實現的。邊緣和霧節點，可以佈署在所有建築物子系統中。
圖5. 住宅建築中的第一個實驗工作。
圖6. 整合在先前安裝的可再生子系統中，邊緣節點的示例。 該節點可以使用新算法控制 ON-OFF 開關，以管理發電過程，以及通信和監控電源數據。
表1.事物示例描述。寫入 ID、類型和節點數據，以配置 XML 文件。配置關聯性儲存在霧節點中。
表 2. 實驗工作中的分析和設計要求。
表 3. 實驗室內使用的嵌入式設備。
圖 7 顯示了分佈在配電板上的節點（邊緣和霧狀）。在此節點中，設計並安裝了功率計、ON-OFF 開關控件和 AI 服務。
圖 8. 佈署的智慧電源功能。在霧節點中實施的分類過程，可用於檢測電連接和人類活動。可以使用 IoT 通信實現其他服務
圖9. 邊緣節點中捕獲，並預處理的用電量數據；MQTT 協議用於通信數據。另外，其他節點可以使用捕獲的數據，來提供其他智慧服務，佈署了整合和互操作性。
圖10. 分類過程。處理捕獲的電數據以檢測家用電器連接。可以使用 IoT 協議整合，來設計其他智慧服務。
圖11. 該圖顯示了實驗工作中的消耗和生產數據。 在自儲存的電力自備設施中，沒有儲存並且沒有注入電網，所產生的能量必須即時使用，並且不得超過所消耗的能量。 能源經理必須預測此事件，並提前連接電荷。
圖 12. 用電自耗設施中的可再生電源管理。
圖 13 是在電源管理子系統中，開發的算法的示例。 可以在邊緣節點上安裝此過程。該節點獲取氣候數據預測，並預測系統是否可以在不儲存的情況下，使用可再生能源。
圖14. 佈署的邊緣節點。該節點可以使用新算法，控制 ON-OFF 開關，並可以在每個房間或建築物中，通信和監控感測器數據。
圖 15. 在雲平台上配置的儀表板。顯示了風力發電數據和預測風力。
圖 16. 在雲端平台上配置事件的儀表板：IF 事件 THEN 動作。 該服務顯示了，如何使用雲端訪問來控制設施。與霧節點的 Internet 通信，可以控制建築物中的不同子系統，並使用電子郵件，SMS 或其他 Internet 服務來通報事件。

資料來源：https://3smarket-info.blogspot.com/2021/02/iot-edge.html?m=1&fbclid=IwAR0uijX5WdNrfzmGjVsakFGaEsWivPgyH1zumxVr7fwvvgqtdFFTI6jJXS8

汽車軟體深度報告：汽車軟體產業鏈及未來趨勢分析

北京新浪網 10-01 20:00
來源：未來智庫

關鍵結論

電動智能趨勢下，汽車逐步由機械驅動向軟體驅動過渡。近年 SDV（軟體定義汽車）概念逐步被行業認知，根源在於「汽車如何體現差異化」問題的變遷，隨著電 動化帶來的汽車電子構架革新，汽車硬體體系將逐漸趨於一致，軟體成為定義 汽車的關鍵，行業更具想像空間。即造車壁壘已經由從前的上萬個零部件拼合 能力演變成將上億行代碼組合運行的能力。本文通過對汽車軟體行業的系統性 梳理，幫助讀者把握行業成長中的投資機會。

我們提出零部件賽道三維篩選框架，基於起點（單車價值量）-持續時間（產品生 命周期）-斜率（產品升級速度）三維體系評價細分零部件的市場空間，軟體平均單車價值量由傳統車的 200 美元，提升至 2025 年新能源汽車的 0.23 萬美元，進 一步至 2025 年新能源汽車的 1.8 萬美元。未來十年軟體市場復合增速為 9%，2030 年 500 億美元空間，57%的增量來自於 ADAS 及 AD 軟體。

軟體如何定義汽車價值？百年汽車工業面臨由機械機器向電子產品過渡的新變 局。汽車「駕駛感」及車機 APP 化的功能實現發生在我們看不到的隱秘角落— —上百的電子控制單元循環執行軟體代碼功能塊，通過高性能的中央計算單元， 與硬體體繫結合以解析駕駛員需求，邏輯運算後向機械部件發送相應響應指令。

汽車軟體成為未來汽車構架重要組成部分。而整車電子電氣構架提供的硬體、 操作系統實現的管理功能、基礎軟體平台構架實現的抽象化為 SDV 不可或缺的 三大關鍵部分，軟硬體的分離（研發分離、功能發佈分離）成為實現 SDV 基礎。

發展史與整車廠戰略。汽車軟體隨產業技術升級持續迭代：1970 年代的簡單發 動機控制演算法→1980 年代中央計算單元創新→1990 年代信息娛樂系統創新→ 2000 年代安全系統→2010 年代開始向全新汽車電子構架及軟體系統演變。不 同於以前依靠多個 ECU 由部件供應商主導的無獨立軟體產品概念時代，主機廠 愈發需具備軟體的管理能力及核心軟體設計能力。整車廠中特斯拉引領車載軟 件行業最高技術，大眾重金重塑軟體架構，整車廠關乎開發周期、賦予附加值、 構架實現、軟體變現模式以及操作系統切入等問題上仍未進行標準化定義，卻 為影響行業發展的關鍵所在。

產業鏈機遇。新科技、軟體公司湧入帶動供應鏈管理的扁平化、邊界模糊化， 帶動供應鏈生態體系變革。供應模式上，預計 Tier1 與整車廠之間將採取兩種合作方式，其一，整車廠主導軟體，Tier1 負責硬體生產；其二，整車廠定義軟 件框架規範標準，Tier1 供應符合標準的相關軟體。盈利模式上，偏向製造業邏 輯的大部分汽車硬體由於堆橋數量將受到限制，終將會進入產業穩態階段，往 介面及功能上的標準化發展，維持較穩定的利潤率水平；軟體由於迭代周期快 且行業特性帶來的標準化程度低，賦予汽車新盈利模式。現階段特斯拉三大付 費模式打開車企軟體變現想像空間，開發基礎平台收許可費、供應功能模塊按 Royalty 收費及定製化的二次開發均為未來軟體供應商主流打法。

推演的 5 大未來趨勢。汽車終將成為搭載「差異化元素」的通用化平台。一方 面，ECU 功能模塊里循環迭代的代碼驅動汽車執行動作反饋；另一方面，車載 娛樂信息系統 APP 化吸引第三方開發者入場。海量數據將在車內流轉，關於賦 能域控制器、定位車機系統的各項軟體性能升級，包括功能中心化、乙太網應 用、整車 OTA 升級、信息交互上雲及深層次的信息安全防禦等，或將帶來汽車 軟體一系列發展機遇。

SDV 新階段：軟體如何定義汽車價值

百年汽車工業面臨由機械機器向電子產品過渡的新變局。跨入駕駛室，安靜的 啟動、柔中帶剛的加速、平穩過渡的剎車等為代表的汽車「駕駛感」逐步由機 械驅動向軟體驅動過渡，這一套功能的實現發生在我們看不到的隱秘角落—— 上百的電子控制單元循環執行軟體代碼功能塊，通過高性能的中央計算單元， 與硬體體繫結合以解析駕駛員需求，邏輯運算後向機械部件發送相應響應指令。近年來，SDV（Software Define Vehicles，即軟體定義汽車）概念逐步被整車 廠認知，根源在於「汽車如何體現差異化」問題的變遷，隨著電動化帶來的汽 車電子構架革新，汽車硬體體系將逐漸趨於一致，整車廠很難在硬體上打造差 異化，此時軟體成為定義汽車的關鍵，即造車壁壘已經由從前的上萬個零部件 拼合能力演變成將上億行代碼組合運行的能力。

汽車軟體為未來汽車構架重要組成部分

汽車軟體與硬體體系發生分化。近幾十年隨汽車構架升級、性能與用戶操作感 需求逐年提升，汽車軟硬體數量爆發，並愈發複雜化。在硬體方面，電控單元 數量迅速增長，於 2010 年面臨增速放緩的拐點（主要受整車成本與控制器數 量平衡的影響），2025 年隨行業集中式電子電氣架構趨勢持續推進，電控單元 邁向集成化從而控制器數量將較為平穩。在軟體方面，各大主機廠軟體功能體 系越做越大，其中「功能函數」作為軟體體系中的最小單元，其單車數量持續 增大，控制器內部的功能函數複雜度提升，疊加智能座艙新增的應用型軟體需 求，軟體重要性愈發凸顯。2010 年（增速放緩的硬體數量 VS. 急劇攀升的軟 件數量）與 2025 年（硬體產業成型 VS.軟體加速迭代塑造汽車差異性）為汽車 軟硬體發展中兩個重要的分水嶺。

汽車複雜的運作需軟硬體結合進行。無論是駕駛艙對汽車電子功能的調用，抑 或汽車與駕駛員和環境互動，均可抽化為軟硬體密切配合的模型，即駕駛員的 需求與汽車功能反應之間存在著複雜的控制鏈條：駕駛員通過機械硬體或部分 虛擬按鈕輸入期望（例如通過車載按鈕、踏板等輸入型機械硬體給出期望）→ 駕駛員動作轉換為電子信號傳入電控單元→執行器控制控制對象達到駕駛員的 需求→感測器向電控系統持續反饋控制達成的具體情況，軟體邏輯持續運算向 執行器發出指令，最終達成駕駛員的期望要求。以剎車輔助駕駛為例，在駕駛 員剎車信號不足或過慢的情況下，內置的一套軟體邏輯將被激活，讓制動系統 自動做出減速相應。在電控單元中快速進行的一次次軟體迭代循環，為汽車正 常運作的基石。

SDV 研發工具鏈仍以 V 流程為主。汽車研發系統過程能拆解為軟體、硬體、執 行器及感測器 4 大部分。與傳統車相同，V 模型為車企主流的開發流程，從產 品設計、子系統設計、控制器驗證及系統驗證等階段均有相對應的工具鏈進行 支撐，涵蓋從系統到軟體以及集成后的一系列測試等內容。SDV 模式下對工具 鏈的應用具部分變化：一方面，硬體愈發通用化，研發會集中在作為功能集群 的 ECU 開發上；另一方面，車的各種功能實現盡量靠軟體實現。

Step 1：產品設計階段。此階段核心為分析和拆解需求。由消費者的需求、車 型安全及性能的剛性需求以及法律法規需求定義出軟體的基礎構架，以及定義 出各大功能模塊。

Step 2：子系統設計階段。步驟為由系統構架需求定義軟硬體構架設計。關乎 軟體系統部分在這一步雛形初顯，能將技術問題具體化，例如定義軟體能實現 的功能、軟體功能模塊的分離、如何跟對應的控制器配合等。

Step 3：控制器驗證階段。完成硬軟體及控制器集成，代碼成型并迭代測試。

Step 4：系統驗證階段。測試軟硬體在整車上的裝載使用情況。

SDV不可或缺的三大關鍵部分——電子電氣架構、操作系統、軟體平台

整車電子電氣構架為硬體基礎。汽車電子電氣架構（Electronic and Electrical Architecture，文中簡稱 EEA）最初由德爾福公司提出，以博世經典的五域分類 拆分整車為動力域（安全）、底盤域（車輛運動）、座艙域/智能信息域（娛樂信 息）、自動駕駛域（輔助駕駛）和車身域（車身電子）等 5 個子系統。後續演變 成車企所定義的一套整合方式，可形象看作人體結構中的骨架部分，後續需要 「器官」、「血液」和「神經」進行填充。具體到汽車上來說，EEA 把汽車中的 各類感測器、ECU（電子控制單元）、線束拓撲和電子電氣分配系統完美地整合 在一起，完成運算、動力和能量的分配，實現整車的各項智能化功能。博世曾 經將汽車電子電氣架構劃分為三個大階段：傳統分散式電子電氣架構-域控制器 電子電氣架構-集中式電子電氣架構：

（1）傳統分散式的電子電氣架構：主要用在 L0-L2 級別車型，此時車輛主要由 硬體定義，採用分散式的控制單元，專用感測器、專用 ECU 及演算法，資源協同 性不高，有一定程度的浪費。產業鏈分工上，車型架構由整車廠定義，實現核 心功能的 ECU 及其軟體開發由 Tier 1 完成。

（2）域控制器電子電氣架構：從 L3 級別開始，通過域控制器的整合，分散的 車輛硬體之間可以實現信息互聯互通和資源共享，軟體可升級，硬體和感測器 可以更換和進行功能擴展。屬於過渡形態，ECU 仍承擔大部分功能實現，整車 廠將參與部分域控制器的開發。

（3）集中式電子電氣架構：以特斯拉 Model 3 領銜開發的集中式電子電氣架構 基本達到了車輛終極理想——也就是車載電腦級別的中央控制架構。此時集成 化趨勢將消減大部分 ECU，主機廠將逐漸主導原本屬於 Tier 1 參與的軟體部分 （預計以直接開發模式或定義規範標準后讓供應商參與），其目標是設計簡單的 軟體插件和實現物理層變化的本地化。

操作系統實現管理功能。車載操作系統（Car-OS)承擔著管理車載電腦硬體與 軟體資源的程序的角色。20 世紀 90 年代伊始，汽車上基於微控制晶元的嵌入 式電子產品的應運興起，需加入相關的軟體架構以實現分層化，即汽車電子產 品均需要搭載嵌入式操作系統。從產品品類上，汽車電子產品可歸納為兩類， 一是以儀錶，娛樂音響、導航系統為代表的車載娛樂信息系統；二是主管車輛 運動和安全防護的電控裝置。兩者對比而言，電控系統更強調安全性和穩定性， 因此應用於電控單元 ECU 的嵌入式操作系統標準更為嚴格。未來操作系統發展 面臨兩大趨勢，一是以 OSEK、AUTOSAR 為典型代表的操作系統標準聯盟將 定義統一的技術規範；二是智能網聯趨勢下數據融合度提升，由於各個部件的 安全標準等級不一從而整車上存在多種操作系統的運用，通常引入虛擬機管理 （可提供同時運行多個獨立操作系統的環境），如在智能座艙 ECU 中同時運行 Android（車載電子操作系統）和 QNX（電控操作系統）。

基礎軟體平台構架是實現抽象化的關鍵所在。從定義上，軟體架構為軟體系統 定義了一個高級抽象（軟體表達行為、屬性、相互作用、集成方式及約束均在 此架構上體現）。而 SDV 核心內涵是能夠通過軟體作用，動態地改變構架網路 節點之間的聯結或分離狀態，從而定義汽車不同的功能組成。基礎軟體平台需 具備三方面要求：一是可靠性，能保證汽車功能實現的實時和安全；二是通用 性，適用於不同車型和不同的操作系統上；三是網構架節點易於更換聯結方式。AUTOSAR 是全球各大整車廠、供應商聯合擬定開放式標準化的軟體架構，其 使得不同結構的電子控制單元的介面特徵標準化，從而軟體具更優的可擴展性 及可移植性，降低重複性工作，縮短開發周期。

汽車軟硬體分離為 SDV 基礎

軟硬體的分離涵蓋研發分離、功能發佈分離兩方面。軟硬體分離為實現 SDV 基 礎，電動化趨勢簡化造車流程，未來汽車硬體的研發、製造更偏向於流水線過 程，而軟體發展逐步具互聯網的快速迭代趨勢傾向。汽車軟硬體分離概念由此 而生，其包含兩方面內容，一方面，由於開發周期（汽車硬體 5-7 年的開發周 期 vs. 軟體 2-3 年的開發周期）及技術領域（偏向製造業 vs.偏向互聯網）的 差別，汽車軟硬體在開發上、供應上逐漸分開。另一方面，軟體的功能發佈可 以與車型完成分離，新軟體不僅適用於新車，仍可快速發佈到已量產車型上， 增強車型硬體的使用長尾期。

軟硬體分離在功能升級及工藝裝配上具優勢。基於軟硬體分離的新構架體系在 車型功能升級及製造模式上發生變化。功能升級上，新的擴充功能由軟體定義 通過雲端直接升級，無需再在硬體層面進行驗證；工藝製造上，與軟體分離后 的電子電氣構架不同於現階段「八爪魚」式的複雜構造，更易於自動化裝配。

當前車企實現更新的方式——硬體冗餘，後續依靠更新升級。

（1）硬體預置：傳統汽車定價由硬體及性能決定。而 SDV 模式下，相同硬體 的車型通過不同的軟體配置決定車與車之間不同的功能與體驗。車企在車型設 計之初需提前定義軟硬體，SOP 時將具備擴展功能的冗餘硬體預裝，後續將通 過付費型軟體升級或者功能開放回收成本。以特斯拉的 AutoPilot 為例，冗餘的 預設硬體將通過後期持續的軟體升級調動功能，為新創收模式。

（2）性能預置：性能預置分為兩個方面，控制器算力預留，為更多的軟體功能 和演算法預留空間。隨智能駕駛趨勢，車載算力大幅提升，由於無法預估後續所 需算力的極限，通常在實際情況中會預留算力空間。性能預留，通常在各性能 硬體上做事先預留，以應付如加速性能提升，續航里程提升，圖像的清晰度提 升，音響效果提升等升級事項。例如 2018 年 6 月，美國權威雜誌《消費者報 告》發現， Model3 剎車距離比皮卡福特 F-150 要長。ElonMusk 接受了《消 費者報告》的批評並承諾通過 OTA 儘快解決此問題。此後在不到一周時間， 特斯拉通過一次 OTA 升級解決了該個問題，《消費者報告》重新測試后發現， 升級后的 Model3 剎車距離縮短了 5.8 米。

追溯發展史：汽車軟體的前世

汽車軟體隨產業技術升級持續迭代：1970 年代的簡單發動機控制演算法（軟體嵌 入應用模式）→1980 年代中央計算單元創新（顯示車輛基本信息）→1990 年 代信息娛樂系統創新（GPS、自適應巡航控制出現）→2000 年代安全系統（出 現高級駕駛員輔助駕駛概念）→2010 年代開始向全新汽車電子構架及軟體系統 演變（電子化和軟體化，出現無人駕駛概念）。

1980 年代之前，汽車僅搭載車燈、啟動機、火花塞等簡易電子設備，並未運用 任何軟體部分。整車電子設備通信及電能供給依靠銅導線傳輸。部分豪華車裝 置僅由收音機為核心部件的車載娛樂系統。

1970 年代，發動機系統具備演算法功能。出現點火系統、電子燃油噴射等裝置， 軟體直接嵌入應用使用，軟體之間無關聯具獨立性。

1980 年代隨 IT 技術起步，電子電氣化革命在傳統機械部件上進行創新。油耗 及行駛距離等信息可在車內做電子化顯示，搭載軟體的電控單元開始出現，如 防抱死系統 ABS、車輛穩定系統 ESP、電子變速箱等電子系統誕生，新功能由 嵌入式軟體的演算法控制，CAN 及 LIN 匯流排解決不同控制器之間的通信問題。

1990 年代，信息娛樂系統持續創新，軟體成為汽車重要部分。汽車軟體構架愈 發分散，出現 GPS 及自適應巡航控制等較高階的電子組件及軟體。同時，不同 控制器間持續延長的通信匯流排成為車企後續進行成本管控的重要一環。

2000 年代，安全系統推出，軟體開始主導汽車創新。「高級輔助駕駛概念」在 此階段興起，例如駕駛員未及時反應的障礙物可以系統運算下汽車自發停車規 避。此時的軟體系統更為高階，行業引入 AUTOSAR 標準軟體構架。車型方面， 電子化特徵明顯，賓士 S 級轎車車型電控單元超 80 個，通信匯流排近 2000 條。

2010 年開始，汽車電動化帶來電子電氣構架、汽車軟體新變局。智能駕駛、車 聯網概念引入，造車新勢力、互聯網企業等多玩家參與進造車環節，以特斯拉 為代表的整車廠重新定義軟體系統，新創 OTA 新升級模式。

產業鏈機遇：SDV重塑市場格局

新科技、軟體公司的湧入帶動了供應鏈管理的扁平化、邊界模糊化，推動產業 競爭要素髮生本質變化，帶動供應鏈生態體系變革。在傳統封閉式供應鏈的汽 車製造商在整條供應鏈中只負責一個環節，主要擔任汽車研發製造的角色。而 在新生態體系中，汽車軟硬體分離重塑產業格局，主機廠、供應商以及互聯網 企業均參與進汽車新生態體系，從汽車全生命周期覆蓋整個產業鏈條。

供應模式轉變，主機廠、供應商及互聯網企業入局

SDV 軟體開發模式下，不同於以前依靠多個 ECU 由部件供應商主導的無獨立 軟體產品概念時代，主機廠愈發需具備軟體的管理能力及核心軟體設計能力， 並引入供應商及互聯網企業參與此環節。在軟體領域，預計未來 Tier1 與整車 廠之間將採取兩種合作方式：

其一，整車廠主導整車軟體部分，Tier1 負責硬體生產。在傳統車企巨頭入場燃 油車領域 100 多年的歷史里，造車流水線仍以機械製造為主，Tier1 以分擔主機 廠重資產角色存在，通常與整車廠車型生產周期形成相應配套。而在智能化時 代，軟體主要以輕資產模式運轉，出於掌握核心技術考量通常為主機廠所主導。其二，整車廠定義軟體框架規範標準，Tier1 供應符合此標準的相關軟體。瞬息 萬變的技術導致車企研發容錯率下降。尤其對新入場的造車勢力而言，若在前 1~2 款車連續失敗，大概率將面臨淘汰。因此對部分在技術儲備、研發及資金 實力較弱的主機廠而言，可在其定義軟體標準後由 Tier1 進行對應的開發配套。

盈利模式轉換，將逐漸由硬體逐漸向軟體傾斜

硬體發展具天花板效應，軟體持續賦予車型新附加值。以經過 15 年發展的手機 產業鏈為例，硬體體系隨處理器性能持續提升、攝像頭像素及攝像頭個數持續 增加、屏幕材質與大小升級，其產業增速趨緩，硬體盈利模式逐漸固化。而隨 蘋果 iPhone 產品橫空出世定義軟體附加值新模式，小米做低手機硬體利潤並將 其定位於功能載體，至此軟體與服務成為手機產業鏈盈利模式的重要來源。對 標至汽車，偏向造業模式的傳統車具較固定的盈利模式，從而車企具較穩定的 利潤率，而目前在汽車電子電氣化架構趨勢下，軟體有多樣性應用的空間，無 論硬體抑或軟體體系均包含升級或新生環節，盈利模式尚未定型。而長遠來看， 偏向製造業邏輯的大部分汽車硬體由於堆橋數量將受到限制，終將會進入產業 穩態階段，往介面及功能上的標準化發展，維持較穩定的利潤率水平；軟體由 於迭代周期快且行業特性帶來的標準化程度低，賦予汽車新盈利模式。

特斯拉已構築初階車企軟體盈利模式。矽谷出身的特斯拉已證實一條軟體大規 模變現的可行性路徑，分為 FSD 付費、軟體應用商城及訂閱服務三種模式：

（1）FSD 付費模式：特斯拉車型在售出后標配 Autopilot 輔助駕駛功能，而實 現自動泊車、智能召喚的 FSD 全自動駕駛功能需付費使用。FSD 單價並未固 定，過去一年內特斯拉 FSD 售價經過三次提價（國外 8000 美元，國內 6.4 萬 元），成為特斯拉利潤的重要來源。以 2019 年 36.7 萬輛的交付量計算（30 萬 輛 Model3，6.7 萬輛 ModelS/X），假定 35%的 FSD 裝載率，6500 美元的 ASP， 則軟體收入近 8.3 億美元（其毛利率大概率高於 80%）。

（2）軟體應用商城：類似手機應用商城，可即時購買性能升級軟體包（包括輔 助駕駛功能、FSD 及各類性能升級包），通過 OTA 進行升級。

（3）訂閱服務：2019Q4 推出定價 9.9 美元/月的車聯網高級連接服務，包括流 媒體、卡拉 OK、影院模式等功能。2020Q2，特斯拉宣布計劃在年底推出定價 100 美元/月的 FSD 套件訂閱服務，為 FSD 的使用提供另一選擇。

對於第三方汽車軟體供應商，盈利模式仍不明晰，參考手機產業模式及目前行 業發展情況，預計其未來有望採用以下 3 種主流盈利模式：

（1）受主機廠委託，開發基礎平台並收取許可費用。

（2）供應功能模塊按汽車出貨量 Royalty收費（按銷售量和單價一定比例分成）。

（3）基於車企平台為其做定製化的二次開發，並收取費用。

市場空間：未來十年軟體市場復合增速為 9%，2030 年 500 億美元空間

軟體市場進入快速擴張期。包括系統軟體和應用軟體在內的軟體系統將在智能 化趨勢中，由低基數實現快速擴張，據麥肯錫預計，軟體在 D 級車整車價值中 所佔的比例有望在 2030 年達到 30%，將成為未來汽車行業最重要的領域。

市場規模方面：電動智能化趨勢下硬體發展周期領先於軟體，增量市場彈性小 於軟體。據麥肯錫，2020-2030 年汽車軟體和 E / E 架構市場預計復合年增長 7％， 從目前的 2380 億美元增長至 2030 年的 4690 億美元。拆分來看，2020-2030 年軟體市場規模（操作系統、中間件及功能軟體）復合增速為 9%（由 2020 年 的 200 億美元，增長至 2025 年的 370 億美元，進一步增長至 2030 年的 500 億美元）。2020-2030 年動力系統市場規模復合增速為 15%，主要受動力源更 迭拉動。在硬體方面，ECU/DCU、感測器以及其他電子元件的復合增速分別為 5%、8%及 3%。軟體的應用帶動汽車集成及驗證環節革新，2020-2030 年集成 及驗證市場規模復合增速為 10%。

單車價值量方面：汽車軟硬體實現分離后兩者的發展模式將出現分化。其中硬 件體系的價值量隨模塊化、集成化發展，在規模化降本過程中其單車價值量增 長將較為平緩或略下降態勢；而軟體體系迭代速度快，在其對附加值模式的持 續探索下，價值量將持續上行。據麥肯錫預計，汽車中軟體單車價值量增速最 大，純電動車型將由 2025 年的 0.23 萬美元增長 7倍至 2030 年的 1.82 萬美元。同期 ECU/DCU、感測器、動力系統（除電池）及其他電子器件增速分別為 37%、 27%、-7%、5%。此外，在豪華車及主打智能化車型上，軟體的價值量佔比及絕對值將處較高水平。

汽車結構方面：全球汽車軟體與硬體內容結構正發生著重大變化，軟體驅動逐 漸成為主導。據麥肯錫預測，2016年軟體驅動佔比從 2010年的 7%增長到 10%， 預計 2030 年軟體驅動的佔比將達到 30%，屆時硬體驅動佔比僅為 41%。

軟體內容方面：應用型軟體為汽車軟體發展主力，ADAS 及 AD 軟體為主要增 量。據麥肯錫預測，2020-2030 年一體化軟體、驗證型軟體及功能性軟體市場 規模復合增速分別為 9%、10%、10%，其中功能性型軟體佔據汽車軟體半壁江 山（結構上佔比 6 成）。2020-2030 年按軟體功能劃分的市場規模中，最大增量 為 ADAS 及 AD 軟體，佔市場規模增量的 57%；信息娛樂、安全及聯網相關軟 件次之，占 20%；操作系統和中間件、車身和動力系統相關軟體、動力總成和 底盤相關軟體分別佔據 10%、10%、2%。

整車廠戰略思路：軟體為必爭之地

在汽車構架三步走過程中——傳統分散式電子電氣架構-域控制器電子電氣架 構-集中式電子電氣架構，主機廠將逐漸主導原本由 Tier 1 包攬的定製軟體部分， 軟硬體進行拆分發包的趨勢近年來愈發明顯。車企和互聯網軟體企業紛紛入局， 特斯拉引領車載軟體行業最高技術，大眾計劃緊跟，組建 5 千名軟體工程師開 發旗下所有車型統一的操作系統「vw.OS」，汽車屬性已然將逐漸由代步工具轉換 為移動的第三空間（例如未來的娛樂、辦公場所）。現階段整車廠與 Tier 1 的合 作模式仍在探索中，關乎開發周期、賦予附加值、構架實現、軟體變現模式以 及操作系統切入等問題上仍未進行標準化定義，卻為影響行業發展的關鍵所在。

特斯拉在軟體層面最大亮點是OTA 升級模式

特斯拉創整車 OTA 升級先河。其升級主要在兩個方面：一方面，將軟體升級發 送到車輛內的車載通訊單元，更新車載信息娛樂系統內的地圖和應用程序以及 其他車機類軟體。例如升級車機的運算速度、屏幕操作流暢度，運行高畫質游 戲以及增強可視化效果等，屬於駕駛艙內「看得見」的升級。另一方面，以直 接將軟體增補程序傳送至有關的電子控制單元（ECU），為 Autopilot 持續引入 及優化新功能。例如提升時速、修復駕駛漏洞等。軟硬體分離開發、硬體性能 冗餘的設計思路是實現 OTA 的必要條件，隨法規放開、演算法逐漸完善，特斯拉 以 OTA 升級軟體模式逐步解鎖新運用功能。此外，特斯拉顛覆車載軟體盈利模 式，以 6.4 萬元的 FSD 選裝軟體包定價、2000 美元的「 Acceleration Boost」 動力性能加速升級包獨創軟體付費的商業模式。

集中式電子電氣架構提供 OTA 基礎。特斯拉的整車 OTA 升級需要其超前的汽 車電子電氣架構做配套配合，傳統車企分散式電子電氣架構中 ECU 數量龐大， 單個 ECU RAM 內存容量有限，同時供應商的底層代碼和嵌入軟體差別較大， 難以完成整車功能的統一更新。而特斯拉採用集中式的電子電氣架構，分為 CCM(中央計算模塊，整合ADAS 及 IVI 域功能)、BCM LH(左車身控制模塊)、 BCM RH(右車身控制模塊)三個部分，2015 款的 Model S 大約有 15 個 ECU， 此後發佈的 Model 3 則直接通過 Hardware3.0 和三個車身控制器執行來控制行 駛、轉向和停止等功能，集中的架構和高算力的控制模塊支撐了特斯拉整車 OTA 升級。目前特斯拉已經可以通過 OTA 的方式實現改善車輛的底盤、信息娛樂、 電池續航、ADAS 乃至自動駕駛等多項功能，讓車的功能迭代更加靈活和便捷， 最終變成一台可以不斷進化的智能終端。

OTA 升級過程需數據網路配合，其安全性尤為重要。特斯拉 OTA 升級即指將程序從主機廠伺服器更新到指定 ECU，主要步驟為：車輛與伺服器通過蜂窩網 絡進行安全連接，將待更新的固件傳輸至車輛遠程信息處理系統及 OTA Manager，OTA Manager 將固件分發至需更新的 ECU 並管理更新過程，更新 完畢後向伺服器發送確認信息。整個 OTA 升級過程面臨安全考驗，騰訊科恩實 驗室曾實現對特斯拉的無物理接觸遠程攻擊，並將漏洞情況報告給特斯拉以做 修復。OTA 模式的信息安全（信息包加密及隔離）及功能安全（車輛狀態信息 傳輸）需得到足夠保障。

特斯拉 OTA 依然屬於行業標杆，傳統車企追趕特斯拉在研發 OTA 過程中仍面 臨困境。具先發優勢的特斯拉在 OTA 對動力和底盤系統有效升級層面、用戶體 驗、系統成熟和穩定性方面均處於行業領先地位，引領傳統車企和造車新勢力 跟隨布局，但仍面臨較多困難，體現在三個方面：其一，需投入較大的人力、 物力、財力，考驗主機廠研發實力；其二，OTA 打破固有的經銷商提供增值服 務的模式，利潤蛋糕重新切分具一定阻力；其三，OTA 安全性和穩定性上要求 較高，主機廠需理解部分互聯網領域技術。

大眾重塑軟體架構，推行 vw.OS 規劃

曾囿於軟體問題車型延遲交付。在特斯拉軟體技術快速迭代壓力下，大眾加緊 開發基礎架構，或因為開發過於倉促等因素，曾多次發生軟體問題，如新一代 純電動汽車 ID.3 因為軟體開發延遲造成交付時間推遲，新款高爾夫也曾因為倉 促上馬新技術（全數字座艙）於車輛中發現軟體問題而臨時停售。

大眾已著手構建軟體架構體系。為抗衡特斯拉及科技巨頭等新勢力的布局，大 眾愈發重視汽車軟體開發業務。2020 年 1 月 1 日起，大眾集團所有軟體開發工 作被集中至獨立新部門——Car.Software（2019 年 6 月份成立）。Car.Software 分為「互聯汽車和設備平台」「智能車身和駕駛艙」「自動駕駛」「車輛運動和能源」以 及「數字業務和出行服務」五個業務單元，其所有功能都將用於開發 vw.OS 車機 系統。一系列車型軟體問題出現后，寶馬製造工程高級副總裁 Dirk Hilgenberg 加入成為 Car.Software 負責人。此外大眾也對智能駕駛研發體系進行重組，如 拆分 L4 智能駕駛研發部分、合併各部門自動輔助駕駛研發。

大眾軟體計劃的內在驅動力來源於兩個方面：

其一：汽車軟體代碼愈發複雜。大眾曾做過統計，汽車軟體的行代碼遠大於其 他應用終端（汽車軟體 1 億行代碼 VS. Facebook 8 千萬行代碼 VS. PC 電腦 4 千行代碼 VS. 飛機 2.5 千萬行代碼 VS. 谷歌瀏覽器 1 千萬行代碼），是智能 手機的 10 倍。2020 年整車代碼量有望超 2 億行，達 L5 級智能駕駛代碼量有 望超 10 億行。

其二：汽車成為複雜的聯網設備，軟體將扮演重要角色。在大眾傳統車型上僅 需約 70 個 ECU，功能相對較為分散。而在未來的集成化計算單元體系下，軟 件的重要性將愈發凸顯，與 ECU 配合定義汽車功能，涵蓋操作系統、基礎軟體 以及其他應用軟體的車載軟體大眾均會自主開發。

大眾對研發投入、人員安排及軟體化目標做出規劃：

投入方面，大眾集團將在未來三到五年內投入 90 億美元（約合人民幣 630 億 元）資金進行軟體開發。員工方面，不同於製造環節的裁員情況，數字化部門 員工由 5000 名再次擴編至 1 萬人。軟體化目標方面，內部研發軟體佔比由不 足 10%提升到 60%以上，同時提出「8 合 1 目標」（將現有的 8 個電子平台整 合為一個平台）。2025 年前，所有新車型將使用 vw.OS 操作系統和定製的雲服 務（大眾與微軟合作），軟體在汽車創新中佔據 90%份額。

汽車軟體的未來推演

若考慮對汽車開發的終極假想，汽車最終會成為搭載「差異化元素」的通用化 平台。以目前視角，差異化元素涵蓋智能座艙（人與車互動的生態系統，包括 包括全液晶儀錶、車聯網、車載信息娛樂系統 IVI、ADAS、HUD、AR、AI、全 息、氛圍燈、智能座椅等方面）及智能駕駛（L1~L5 級智能駕駛等級）領域。而差異化元素主要由車型全新的電子電氣架構和軟體兩方面定義，一方面，ECU 里的功能模塊持續循環迭代的代碼驅動汽車執行最適宜的動作反饋；另一方面， 車載娛樂系統越發 APP 化吸引較多第三方開發者入場。海量數據在車內流轉， 其深層次的安全防禦（檢測和防禦網路攻擊）愈發重要。經過產業趨勢推演， 提出以下 5 大汽車軟體趨勢預判。

趨勢 1.往車輛集中式電子電氣架構發展，功能中心化

集中式電子電氣架構為終極構架體系。以域控制器為代表產品的跨域集中式電 子電氣架構再往後走，就是集成化程度更高的車輛集中式電子電氣架構—— Vehicle computer and zone concept（車載電腦），終極階段為 Vehicle cloud computing（車雲計算）。未來車輛通過用高性能的中央計算單元取代現在常用 的分散式計算的架構，將實現「軟體定義車輛」的終極目標。再此過程 ECU 的整合過程持續提升，應用程序完全從硬體中抽象出來，控制單元概念最終被 智能節點計算網路接棒。

趨勢2.更高傳輸性能的乙太網作為主幹網路承擔信息交換任務

乙太網作為車內通信網路大勢所趨。隨車內數據傳輸總量及對傳輸速度要求持 續提升，以及在跨行業的標準協議需求驅動下，支撐更多應用場景、更高速的 乙太網有望取代 CAN（主要用於車載控制數據傳輸，最大帶寬 1MB/s）、LIN（低 成本通用串列匯流排，主要用於車門、天窗及座椅控制）、Most（主要用於發數據 包）等傳統汽車車內通信網路成為車內通信網路。在對同樣的 ECU 的軟體進行 更新時，CAN 模式下的傳輸時間是乙太網的 30 倍。因此，乙太網的運用趨勢 得到主流整車廠（如寶馬、通用等）及半導體公司（如博通、恩智浦等）認可， 均推出符合乙太網的應用元件。未來趨勢上，乙太網並非能一蹴而就完全替代 CAN、LIN，預計多種通信模式將在較長一段時間內共存——CAN、LIN 用於傳 感器和執行器等封閉低級網路間的數據傳輸；乙太網（取代 MOST 等技術）用 於域控制器及子部件間的信息交換。

趨勢3.OTA 空中升級模式普及

OTA 由特斯拉引領，向全行業普及。由特斯拉最先推行的 OTA 升級功能模塊 能持續修復汽車軟體缺陷、解決部分故障、解鎖或引入新功能以滿足用戶需求， 成為汽車軟體發展的主流趨勢。按照升級對象的不同，OTA 可分為 FOTA（硬 件在線升級）、SOTA（軟體在線升級）兩個大類，其中 FOTA 主要針對基礎硬 件和汽車底層安全相關功能的升級需求，例如剎車系統、制動系統及 BMS 等；SOTA 主要對座艙娛樂系統進行升級。對 ECU 而言，其內部為備份軟體準備了 額外區域空間，以備當前運行程序出現故障或升級中發生斷錯誤時自動滾回備 份軟體系統，防止車輛出現安全事故。

趨勢4.汽車在雲端交換信息

更為靈活的雲服務是 SDV 載體。從早期的機械時代過渡到目前的硬體時代，在 進一步進化至未來的軟體時代，汽車的功能實現方式持續演變，隨著客戶的個 性化定製需求日益增加，加之雲計算對智能、靈活和自動化的天然要求，由「軟 件定義」來操控硬體資源成為更合適的解決方案，未來大部分汽車功能在雲端 運行，為車企轉型提供聯接使能、數據使能、生態使能和演進使能。因此，在 雲計算的計算、存儲和網路等各方面的基礎設施上，均呈現出從軟硬體捆綁， 到硬體+閉源軟體，再到白盒硬體+開源軟體的演進趨勢。而雲服務也成為 AI、 智能汽車、大數據等新興科技實現商業化落地的載體（例如特斯拉在雲服務載 體上進行 OTA 升級）。近年來雲服務市場實現爆髮式增長，而車載環節尚處於 發展初期，後續增量空間大。

趨勢5.信息安全領域需深層次防禦

汽車電子的運用及智能網聯化趨勢推進車載信息安全要求提升。汽車脫離孤立 單元后，隨之而來的是攻擊面的新增，一方面車輛聯網后其數據面臨被盜取、 泄露風險，另一方面電控系統普及后存在轉向、剎車等關鍵功能被外部控制的 可能性（例如破解車機、T-Box、網管后，向 CAN 發送惡意指令）。即接入汽車控制終端的 APP、網路系統、ECU 代碼均可能成為新攻擊向量。雲（車聯網 平台）-管（車聯網基礎設施）-端（車載智能及聯網設備）均存在信息安全問 題，將造成車輛功能性安全隱患：

（1）雲端與管端：接送關鍵數據的中央互聯網關直接連接至車企後台，部分第 三方公司被允許數據訪問。目前網聯實現通常會通過 APP 實現應用層功能（例 如解鎖車門、調用空調功能等），此時存在手機端與雲端的通信過程，且應用程 序供應商能直接訪問開放的相關數據介面。通過雲端和對外通信管端能對車機 端直接進行攻擊。

（2）車機端：當功能系統被授權時，黑客能對CAN匯流排發送相關指令控制ECU。騰訊道恩實驗室曾對特斯拉 Model S 進行過無物理破解實驗，以 Wifi 熱點接入 向車載娛樂系統植入軟體取得車機許可權，在破解網關后能控制其多個電控單元。

為抵禦外部攻擊需建立深層次的安全防禦系統，嚴控與功能安全及數據連接。汽車的防護措施隨交互信息增多其力度持續提升。車企安全團隊通常基於雲-管 -端對症建立安全防禦系統以應對外部攻擊：

（1）雲端：車載終端是汽車安全架構的核心，主要注意 T-BOX（用於車端和 外界通信）和 OBD（用於將汽車外部設備連接到 CAN 匯流排）兩大塊的信息防 護。實時進行入侵檢測，防止 DDos 攻擊。

（2）管端：汽車在未來將頻繁接入和退出網路節點，存在被篡改信息的風險。通常需要對通訊過程及傳輸數據進行加密，採用專門的 APN 接入網路。

（3）車機端：加強安全固件驗簽及防 root 機制，管理介面並建立監控體系。此外，可在車輛功能模塊上單設安全晶元對數控進行校驗。

部分第三方供應商能參與至信息安全環節。汽車安全防禦對於以特斯拉、蔚來、 小鵬等為代表的有互聯網基因的造車新勢力來說，擁有一定先天的優勢。包括 特斯拉在成立之初便組建了來自谷歌、微軟等互聯網企業的 40 人的網路安全專 家，小鵬和蔚來與阿里、騰訊等互聯網廠商進行深度合作，未來華為等供應商 是此領域的預備軍。目前網路安全系統仍缺乏標準的信息安全方案，原本的汽 車軟硬體供應商難以以統一標準滿足不同整車廠的信息安全要求，並且在測試 階段很難直接接入車企平台進行網路安全試驗。預計未來行業將有提供信息安 全方案、網路安全模塊以及某一特定領域防禦系統的第三方軟體供應商出現。

投資建議和推薦標的

百年汽車工業面臨由機械機器向電子產品過渡的新變局，在我們看不到的隱秘 角落——上百的電子控制單元循環執行軟體代碼功能塊，通過高性能的中央計 算單元，與硬體體繫結合以解析駕駛員需求，邏輯運算後向機械部件發送相應 響應指令。近年來，SDV（軟體定義汽車）概念逐步被整車廠認知，根源在於 「汽車如何體現差異化」問題的變遷，硬體體系將逐漸趨於一致，軟體成為定 義汽車的關鍵，即造車壁壘已經由從前的上萬個零部件拼合能力演變成將上億 行代碼組合運行的能力。

SDV 趨勢下汽車軟硬體分離重塑市場格局，盈利模式由硬體向持續賦予附加值 的軟體傾斜。主機廠愈發需具備軟體的管理能力及核心軟體設計能力，並引入 供應商及互聯網企業參與此環節，開發基礎平台並收取許可費用、供應功能模 塊按汽車出貨量 Royalty 收費及基於車企平台做定製化的二次開發均為未來主 流的軟體供應商盈利模式。預計 2030 年 500 億美元市場空間，復合增速 9%。

汽車最終會成為搭載「差異化元素」的通用化平台。一方面，ECU 里的功能模 塊持續循環迭代的代碼驅動汽車執行最適宜的動作反饋；另一方面，車載娛樂 信息系統越發 APP 化吸引較多第三方開發者入場。海量數據在車內流轉，其深 層次的安全防禦（檢測和防禦網路攻擊）愈發重要。關於賦能域控制器、定位 車機系統的各項軟體性能升級，包括車內乙太網應用、整車 OTA 升級、信息交 互上雲及深層次的信息安全防禦等，或將帶來一系列發展機遇。

資料來源：https://m.news.sina.com.tw/article/20201001/36497492.html?fbclid=IwAR1zWwTMiTHwfLyqZ7Qx698UjYwI3v0c-hs3gXdy560Rf5BgAS4Ts4QLbOQ