A quick view of active scan result in wpa_cli and iw

It's not easy to find the difference between the scan result of wpa_cli and iw. In some cases, especially a lot of APs operating in the same environment, the difference scan results between each other can be observed.

For instance, I've more than 300 APs in my test environment, but my test always shown there are around 50 APs in wpa_cli scan result but no problems in iw. We know wpa_cli is coming from wpa_supplicant, and both wpa_suuplcant and iw are open source for Linux-based system. In this article I would like to show the difference between how wpa_cli and iw to get scan result.

In wpa_cli before getting scan results you need to perform "SCAN" first and then perform "SCAN_RESULTS". The duration between performing "SCAN" and "SCAN_RESULTS" should be more than 5 seconds. IW is much easier to get scan results, you just need to perform "scan" and the result will output.

In source code of wpa_cli, we can find when an user execute "SCAN_RESULTS" command it will create a buffer as an argument to input wpa_ctrl_request in _wpa_ctrl_command. This buffer will get the scan_results from a Wi-Fi driver through IPC and it is the first size limitation to fetch scan results in wpa_cli.

After enlarged this buffer size it is not enough  to get full scan results, the second point is to adjust bss_max_count in wpa_supplicant.conf. The default setting is 200. If the scan result is larger than bss_max_count, the oldest BSSID will be removed from queue.

In iw it gets scan results by callback (handler), so each results fetched by Wi-Fi driver will be output by iw. A scan command is combined handle_scan_dump and handle_scan. So you can find the scan result is printed out by handle_scan_dump.

Reference:

• wpa_supplicant: https://w1.fi/wpa_supplicant/
• iw: https://wireless.wiki.kernel.org/en/users/Documentation/iw

OTORI

7/25/2022

讀《汽車軟件架構》 (上)

「Automotive Software Architecture」是由瑞典哥德堡大學的Miroslaw Staron撰寫，兩位譯者是王駟通與歐陽紫洲。王駟通畢業於多倫多機械工程學院，現任職於中國大陸某合資汽車零部件供應商；歐陽紫洲畢業於清華大學汽車工程系，現就職於中國大陸某智能聯網汽車研發機構。兩位譯者對於車用電子都有豐富的學經歷背景支撐。雖然本書完成於2017年，但翻譯完成時間是2020年；儘管如此，本書中介紹的汽車軟件架構仍是很完整並且實用。

本圖取自蘇寧易購

OT研究所時攻讀軟體工程，在業界則接受不少車用軟體及車用品質體系的薰陶，書中介紹的知識與OT實作經驗相輔相成；書中許多實作經驗作者會帶到Volvo XC90的開發，因此特別推薦給剛進入此領域的朋友們閱讀。

本書的1.6節及第十章「總結」，快速地帶領讀者介紹每章節的重點。本書OT會分兩篇介紹，本篇先將1.6節及第十章「總結」合併介紹給正在閱讀本篇的朋友們，下一篇則是介紹OT覺得印象深刻的內容。

第1章：軟件架構及其在汽車軟件工業的發展概述

軟件架構是一種軟件的高層設計和結構。它為軟件及組建的詳細設計以及軟件的部屬提供了指導。軟件架構文檔中通常包含一系列的視圖，例如功能視圖、邏輯視圖或部署視圖等。

軟件架構還提供了軟件系統高層建構的原則，因此他也包含不同的架構風格。

本書中匯總了汽車軟件設計中最重要的方法及工具。這些方法不僅侷限在架構層面，也涵蓋了詳細設計的範疇。在第1章中提供了每章的內容提要並總結了架構設計之所以對未來的汽車軟件工程意義非凡的原因。

第2章：軟件架構

本章中介紹了軟件架構的概述，向不熟悉軟件架構學科的讀者回顧軟件架構的基礎知識，在最後描述了汽車軟件架構的特殊性。本章開頭回覆軟件架構的含義，定義汽車軟件設計中使用的視圖類型，並將它們與軟件工程中經典的4+1架構視圖模型進行映射。接著將逐步介紹汽車軟件架構中的重要元素，如ECU、邏輯和物理組件、功能架構，以及整車架構的拓樸結構(物理和邏輯架構)等。在介紹過程中，將與中強調汽車嵌入式軟件系統對安全性和可靠性的高要求。

在汽車軟件系統設計中常用的結構視圖：

• 功能視圖：描述車輛功能的架構以及他們之間依賴關係。
• 物理視圖：描述物理節點(ECU)以及節點之間的連接。
• 邏輯視圖：描述軟件組建和架構。
• 部署視圖：描述軟件組建在ECU中的部署。

汽車中出現的主要架構風格

• 分層架構風格。
• 基於組件的架構風格。
• 單體架構風格。
• 微內核架構風格。
• 管道與過濾器架構風格。
• 事件驅動架構風格。
• 中間件架構風格等。

第3章：汽車軟件開發

本章詳細介紹汽車軟件的開流程。首先是整車開發的V模型，並進一步引入現代敏捷軟件開發的方法來描述軟件開發團隊的工作過程。本章也簡要介紹一款用於保持研發數據一致性的工具—由SystemIte開發的SystemWeaver。內容也涉及諸多研發工作及方法，例如變體管理、不同的軟件集成階段、測試策略等。結合實例來審視這些方法並解釋它們是如何被應用的。

汽車軟件工程中的實踐先從需求開始，這部分內容某種程度上是汽車行業獨有的。本章討論了如下的需求模型：

• 文本需求：以文本和表格形式呈現的規格說明。
• 用例需求：基於UML用力和相應的序列圖來呈現的規格說明。
• 基於模型的需求：以模型的形式呈現的規格說明，這些模型後續將由供應商實現。

理解了制定軟件需求的方法，還需要進一步理解軟件驗證和確認的方法。軟件的驗證和確認以測試的形式完成，它們包括：

• 單元測試：單一軟件模塊的功能驗證。
• 組件測試：一組軟件模塊(即組件)的驗證。
• 系統測試：完整系統的驗證(包括開發完成後的完整功能以及開發中的某單一功能)
• 功能測試：對照規格說明，對終端用戶功能的確認。

介紹了不同的測試方法以及汽車軟件集成的不同階段後，探討了這些元素是如何在「產品數據庫」中儲存。

第4章：AUTOSAR標準

本章中討論了標準化的話題，概述業界在標準化方面所做的努力。特別介紹了AUTOSAR這一目前在歐洲乃至世界範圍內最受關注的汽車軟件標準。AUTOSAR標準中的主要構建塊，例如軟件組件和通信總線等。將AUTOSAR核心思想以及對汽車工業的影響兩個角度來回顧汽車軟件架構標準化的演變歷程。本章最後介紹AUTOSAR標準中提供的參考架構，並討論它的演變方式。

本書認為AUTOSAR標準的引入是當今汽車軟件領域的主要趨勢之一。該標準定義了汽車軟件是如何被建構以及它的組件部分之間是如何交互的。某種意義上，AUTOSAR標準也被視為汽車的「操作系統」。

本章內容由Darko Durisic撰寫，他是AUTOSAR聯盟中瑞典汽車製造商的領軍人物之一，具備豐富的實踐經驗，因此也能從軟件設計者的角度對AUTOSRAR系統進行精彩的介紹。本章內容關注的是AUTOSAR參考架構及其應用。

從AUTOSAR中「概念」的角度探討了AUTOSAR標準的演化，分析了AUTOSAR規範中的哪些內容發生了變化、標準中「概念」的數量是如何演化的，以及這些演化對汽車軟件的設計意味著什麼。最後本書也給出了一些基於AUTOSAR進行汽車軟件組件設計的實例。

第5章：汽車軟件的詳細設計

本章將繼續從技術的角度深入研究汽車軟件架構，我們將描述在特定軟件組件中進行軟件設計的方式。

• Simulink建模：汽車軟件算法的詳細設計最常用的方法，通常用於動力總成域、主動安全域或底盤域。
• SysML：一種基於UML語言的方法，關注軟件定義中的編程語言方面的概念。
• EAST-ADL：另一種基於UML語言的方法，專門用於汽車軟件的設計，將問題領域的概念和編程層面的概念相結合。
• GENIVI：一種專用於信息娛樂系統的編成標準，目前在市場上正受到愈來越多越好的關注。

知道這些術語和真正理解安全關鍵系統的設計原則是不一樣的。因此本書還介紹了設計安全關鍵系統的原則，這些原則來自對NASA及其空間項目的研究。

第6章：汽車軟件架構的評估

在本章中介紹評估軟件架構質量的方法，並重點討論了軟件行業經典的架構權衡分析方法(Architecure Tradeoff Analaysis Method, ATAM)。討論了汽車軟件的非功能屬性，如可靠性和穩定性等，並進一步回顧了評估這些屬性的方法。在討論過程中本章參考了ISO/ICE 25000系列標準。

本章還提出軟件、硬件集成過程中的挑戰及其影響。討論了汽車軟件和商用計算機應用乳間之間的差異，並給出了具體實例。最後，討論了這些軟件屬性進行量測的必要性。

第7章：軟件設計和架構的度量

本章中介紹一般軟件工程和汽車軟件工程中最常用的度量，例如：總代碼行數、模型大小、複雜性，以及架構穩定性或耦合性等。具體給出了這些度量的解釋—基於這些度量的具體數值大小，應該做什麼，為什麼要這麼做。還討論了基於ISO/IEC 15939的度量標準的使用。

本章為架構工程師提供了一系列的度量組合以及它們的可視化表達。也同樣為汽車軟件的詳細設計提供了一系列的測度。

最後，本章展示了一份關於汽車測量的公開工業數據。在測量結果的基礎上，討論了諸如軟件規格和圈複雜度等軟件屬性，並分析了它們對軟件驗證和車輛安全的影響。

本章內容由作者和來自愛立信公司的Wilhelm Meding合著完成。Wilhelm Meding在軟件測量領域以及深耕十餘年，是資深的研究員。

第8章：汽車軟件功能安全

本章中詳細闡述功能安全這一話題，這是現代汽車軟件中最重要的話題之一。本章介紹國際標準ISO/IEC 26262中與安全相關的概念，並說明如何在軟件研發流程中應用這些標準。國際標準中提到的功能安全驗證和確認技術，並將其與汽車安全完整性等級(Automotive Safety Integration Level, ASIL)關聯，討論其在實踐中的效果。為使讀者清晰理解功能安全這一標準，本章在介紹過程中穿插了一個簡單的功能開發實例—包含了不同ASIL等級的微控制器架構的實例。

本章作者是來自Volvo AB公司的Per Johannessen，他曾成功地在某乘用車製造商建立了該標準，目前正在重型車輛和公交車領域從事相關的工作。

第9章：汽車軟件架構的當前趨勢

在本書的最後介紹汽車軟件開發的當前趨勢。市場上一些新興的、具有顛覆性的技術，這些技術被認為可能讓傳統的汽車工業變得更加以軟件為導向：

• 自動駕駛：需要以更複雜的軟件和更高層級的連接為支撐。
• 自修復、自適應、自組織系統：可以讓軟件更可靠、更智能；但在軟件安全性評估上面臨著挑戰。
• 大數據：基於外部資源的可用信息，讓汽車軟件做出更智能的決策；但與此同時，對軟件系統的處理能力、儲存以及一些其他特性提出了更高的要求。
• 軟件開發流程的新趨勢：例如軟件持續集成技術，可以讓軟件持續改進，但也對軟件的安全性評估以及快速驗證提出了討戰。

OTORI

民國111年2月21日

讀《自動駕駛汽車平台技術基礎》

 「自動駕駛汽車平台技術基礎」在2020年6月由大陸的清華大學出版，作者是楊世春、肖贇、夏黎明、蔣曉琳、華暘等人編著。根據作者簡介，本書的作者含括北京航空航天大學與百度公司，其中百度公司編寫者大多是參與Apollo平台的開發者。因此本書從第四章起深入的介紹Apollo的架構，包括從第一代開始的演變。扣除Apollo的部分，第1~3章介紹了許多車用電子在自動駕駛上的應用及發展，不過技術含量不少，可能需要先對這個產業有些了解才比較容易入手。所以本書經本可以粗略分成兩部分：自動駕駛的相關技術介紹，以及百度Apollo平台的介紹。

圖片取自清華大學出版社

下圖為本書中以總線的觀念，將自動駕駛的架構劃分為「環境感知系統」、「定位導航系統」、「路徑規劃系統」、「運動控制系統」、「輔助駕駛系統」；其中「環境感知系統」、「定位導航系統」、「路徑規劃系統」這三個是基礎於CPU(中央處理器)處理。各自系統中負責的功能讀者可以按圖索驥。

自動駕駛汽車技術架構

而對應的關鍵技術可以分為三大塊：「車輛/設施」、「信息交互」、「基礎支撐」；而這三塊又同時需要車載平台及基礎設施一起實作，互相支持。由於沒有一家公司有能力同時實現這麼東的技術，因此根據每間公司的核心領域，又可以分出更多的廠商來完成這個生態系。

自動駕駛汽車關鍵技術框架

第三章有簡略的介紹到AUTOSAR架構，雖然篇幅不多，但是OT覺得很值得細讀。AUTOSAR是Automotive Open System Architecture的縮寫，這個聯盟由主要車廠：BMW、Daimler、Ford、GM、PSA、Volkswagen，以及主要一階供應商Bosch、Continentals發起，並訂定許多車用電子的開發規範，在歐美體系的車用電子市場極具影響力；事實上現在大陸也不少車廠也開始導入AUTOSAR的架構。

AUTOSAR的Core Partner，本圖取自AUTOSAR

本書歸納AUTOSAR的架構如下圖，分別為應用層(Application Layer)、運行時環境(Run Time Environment, RTE)、基礎軟件層(Basic Software, BSW)以及微控制器(Microcontroller)。AUTOSAR架構的好處是應用層可以完全獨立於硬件，只有基礎軟件層與硬件相關，而RTE實現這兩者的隔離。這樣供應商可以專注於開發自己專長的應用層軟件，而不必關心基礎層軟件的標準化。

AUTOSAR層面圖

上圖應該是作者們歸納了AUTOSAR的Classic Platform，方便讀者理解；原架構如下，提供有興趣的朋友對比。

AUTOSAR的Classic Platform(取自AUTOSAR)

本書對於AUTOSAR的說明，除了架構層面，也對每一層中AUTOSAR模塊(台灣稱為「模組」)的構成，也做了深度的介紹。對於想了解AUTOSAR的朋友是很好入門的一個章節。

第三章的後半段開始介紹Apollo架構、自動駕駛系統會用到的軟件。這邊不多做說明。第四章開始正式介紹Apollo。Apollo的Source code可以到GitHub下載，網址是https://github.com/ApolloAuto/apollo。OT依照GitHub的說明確實可以下載，並且在Ubuntu 20.04上編譯。

本書出版時，Apollo架構為3.5，但是目前已經進版到6.0。因此本書可以讓得主對於Apollo的設計概念以及演進做概念性的介紹。實作的部分建議各位朋友直接下載GitHub。

百度Apollo 6.0，取自GitHub

OTORI

民國110年11月23日