# Polaris RFP Requirements Document Chap3
## 3.1.1 需始終顯示的專用資訊需求分析

這項需求定義了車輛儀表板上 LCD 螢幕必須持續顯示的關鍵車輛資訊，確保駕駛隨時都能掌握重要的車輛狀態。

**條款內容：**

* 3.1 使用者介面 (R.2): 本節定義了使用者介面的整體需求。
* 3.1.1 專用資訊顯示 (R.7): LCD 螢幕必須持續顯示以下資訊：
* 車速
* 發動機轉速
* 油量
* 傳動系統
* 檔位
* 時鐘

### 條款分析：

* **重要資訊持續顯示:** 此需求強調了持續顯示關鍵車輛資訊的重要性，讓駕駛可以隨時監控車輛狀態，提升行車安全。
* **資訊清晰易懂:** 螢幕上顯示的資訊必須簡潔易懂，讓駕駛可以快速理解。

### 與其他條款的關聯性：

* **3.9 警示燈 (R.4):** 警示燈條款詳細說明了各種警示燈的軟體需求，包括其圖像、顏色、預設狀態、輸入訊號 (離散或 SPN)，以及 CAN 超時設定。警示燈與 3.1.1 中提到的車速、發動機轉速和油量等資訊密切相關，可以提醒駕駛注意潛在的車輛問題。
* **3.21 傳動系統 (R.1):** 傳動系統條款定義了如何根據車輛狀態顯示不同的傳動系統圖示，例如前輪驅動、後輪驅動或四輪驅動。此條款與 3.1.1 中的傳動系統資訊顯示需求直接相關。
* **3.33 檔位 (R.3):** 檔位條款定義了如何在 LCD 上顯示當前檔位資訊，以及在檔位資訊不可用時如何處理。此條款與 3.1.1 中的檔位資訊顯示需求直接相關。
* **3.17 時鐘 (R.3):** 時鐘條款定義了時鐘功能的詳細需求，例如時間來源、時間格式、時區設定和時間校正等。此條款與 3.1.1 中的時鐘資訊顯示需求直接相關。
* **4.5 LCD (R.5):** LCD 條款定義了 LCD 螢幕的規格需求，例如尺寸、解析度和亮度等。這些規格會影響 3.1.1 中提到的資訊顯示效果。

### 對供應商的影響：

* **硬體設計:** 供應商需要選擇符合解析度和亮度要求的 LCD 螢幕，確保可以清晰顯示所有必要的資訊。
* **軟體開發:** 供應商需要開發軟體，從車輛感測器獲取車速、發動機轉速、油量、傳動系統、檔位和時鐘等資訊，並在 LCD 螢幕上以易於理解的方式呈現。
* **使用者介面設計:** 供應商需要設計一個直觀易用的使用者介面，讓駕駛可以輕鬆地查看和理解所有顯示的資訊。

### 總結：

3.1.1 專用資訊顯示條款定義了車輛儀表板上 LCD 螢幕必須持續顯示的關鍵資訊。供應商需要仔細理解這些需求，並在硬體設計、軟體開發和使用者介面設計等方面予以充分考慮，以確保最終產品可以提供清晰、易懂且符合法规的車輛資訊顯示。

## 3.1.2 可選資訊顯示需求分析

此需求列出了 LCD 螢幕上 **可能顯示** 的資訊或功能，這些資訊並非必須始終顯示，而是根據車輛狀態、使用者設定或其他因素動態顯示。

**條款內容：**

* 3.1.2 可選資訊顯示 (R.3): 以下資訊/功能可以顯示在 LCD 上（即並非始終需要）：
* 發動機工作時數
* 發動機溫度
* 系統電壓
* 里程表
* 行程表
* 警示燈
* 通知
* 背光亮度
* 背景主題
* 診斷碼
* 駕駛模式
* 環境氣溫
* 省電模式
* 皮帶溫度
* 加熱握把
* 渦輪增壓
* 變速箱溫度
* 限速
* 保養資訊
* 工廠重置

### 條款分析：

* **資訊豐富性與靈活性：** 此條款列出的資訊涵蓋了車輛狀態、性能參數、使用者設定、診斷資訊等多個方面，為使用者提供了豐富的資訊選擇。同時，並非所有資訊都需要始終顯示，這賦予了系統更大的靈活性，可以根據不同的使用場景和需求動態調整顯示內容。
* **提升使用者體驗：** 通過提供這些可選資訊，使用者可以更好地了解車輛的運作狀態、性能表現和保養需求，從而提升駕駛體驗。例如，使用者可以通過查看發動機工作時數、里程表等資訊來了解車輛的使用情況，通過查看皮帶溫度、變速箱溫度等資訊來監控車輛的運作狀態。
* **簡化操作流程：** 一些功能的整合，例如背光亮度調整、背景主題切換、省電模式啟用等，可以讓使用者更方便地操作和設定車輛儀表板，提升使用效率。

### 與其他條款的關聯性：

* **3.1.1 專用資訊顯示 (R.7):** 此條款列出了必須始終顯示的關鍵資訊，例如車速、發動機轉速、油量等。可選資訊可以作為對這些關鍵資訊的補充，提供更全面的車輛狀態資訊。
* **3.3 診斷 (R.3):** 此條款定義了車輛儀表板支援的診斷協議和功能，包括診斷選單、J1939 協議、UDS 協議和 J2012 3 位元組 DTC 協議。可選資訊中的診斷碼顯示功能與此條款密切相關，可以讓使用者直接在儀表板上查看車輛故障碼。
* **3.9 警示燈 (R.4):** 此條款詳細說明了各種警示燈的軟體需求，包括圖像、顏色、預設狀態、輸入訊號 (離散或 SPN)，以及 CAN 超時設定。可選資訊中的警示燈顯示功能與此條款相關聯，可以讓使用者在儀表板上查看各種警示燈的狀態。
* **3.8 通知 (R.4):** 此條款定義了車輛儀表板的通知功能，包括通知觸發機制、文字通知外觀、通知列表和未來通知支援等。可選資訊中的通知顯示功能與此條款相關聯，可以讓使用者在儀表板上查看各種通知訊息。
* **其他相關條款：** 可選資訊中的其他功能，例如駕駛模式、環境氣溫、省電模式、皮帶溫度、加熱握把、渦輪增壓、變速箱溫度、限速、保養資訊、工廠重置等，都與相應的功能條款相關聯。

### 對供應商的影響：

* **軟體開發：** 供應商需要開發軟體來處理這些可選資訊的顯示邏輯，包括資訊的獲取、處理、顯示和更新等。
* **使用者介面設計：** 供應商需要設計一個合理的使用者介面來呈現這些可選資訊，確保資訊的清晰易懂，操作的方便快捷。
* **系統資源管理：** 供應商需要考慮這些可選資訊的顯示對系統資源的影響，例如處理器負載、記憶體佔用等，並進行合理的優化和管理。

### 總結：

3.1.2 可選資訊顯示條款為 LCD 螢幕提供了豐富的資訊和功能選擇，提升了車輛儀表板的資訊豐富性和使用者體驗。供應商需要仔細理解這些需求，並在軟體開發、使用者介面設計和系統資源管理等方面予以充分考慮，以確保最終產品可以提供靈活、實用且易於操作的可選資訊顯示功能。

## 3.1.3 儀表設定需求分析

這個需求定義了操作者可以調整的內部儀表設定，允許使用者根據個人喜好定制儀表板的顯示方式。

**條款內容：**

* 3.1.3 儀表設定 (R.7): 可由操作者調整的內部儀表設定：
* 距離/速度 (英里/英里/小時 或 公里 或 公里/小時)
* 溫度 (華氏/攝氏)
* 時鐘小時 (12 小時 / 24 小時)
* 時鐘時間 (操作者可以設定時間)
* 亮度模式 (自動/手動)
* 背景主題 (日/夜/自動)
* 背光亮度
* 行程時間

### 條款分析：

* **個人化設定：** 此條款允許操作者根據自己的喜好和使用習慣調整儀表板的顯示方式，例如選擇不同的單位制、時間格式和亮度模式等，提升使用者體驗。
* **適應不同環境：** 背景主題設定允許操作者根據環境光線條件選擇不同的主題，例如白天使用日间主题，夜間使用夜間主題，或者讓系統自動根據環境光線調整主題，確保螢幕資訊在不同環境下都清晰易讀。
* **滿足不同地區需求：** 距離/速度和溫度單位制設定可以滿足不同地區使用者的需求，例如美國使用者習慣使用英里和華氏度，而歐洲使用者習慣使用公里和攝氏度。
* **操作便捷性：** 這些設定應該易於操作和調整，例如可以使用儀表板上的按鈕或觸控螢幕進行設定，或者通過手機應用程式進行設定。

### 與其他條款的關聯性：

* **3.1 使用者介面 (R.2):** 儀表設定是使用者介面的一部分，這些設定的設計應該與整體使用者介面風格保持一致，並且易於操作和理解。
* **3.17 時鐘 (R.3):** 時鐘時間和時鐘小時設定與時鐘功能相關聯，這些設定可以讓使用者調整時鐘的顯示方式。
* **3.12 背景主題 (R.1):** 背景主題設定可以讓使用者選擇不同的背景主題，例如日间主題、夜間主題或自動模式。
* **3.13 背光亮度 (R.2):** 背光亮度設定可以讓使用者調整螢幕的亮度，並且可以選擇自動模式或手動模式。
* **3.50 行程表 (R.1):** 行程時間設定可以讓使用者調整行程表的顯示方式。
* **其他相關條款：** 其他相關條款包括距離/速度 (例如 3.52 車速 (R.3)) 和溫度 (例如 3.26 引擎溫度 (R.1)) 的顯示方式。

### 對供應商的影響：

* **軟體開發：** 供應商需要開發軟體來實現這些設定功能，包括設定選單、設定儲存、設定應用等。
* **硬體支援：** 某些設定可能需要硬體支援，例如亮度模式設定需要光線感測器支援，背景主題設定需要足夠的儲存空間來儲存不同的主題。
* **測試驗證：** 供應商需要測試和驗證這些設定功能的正確性和穩定性，確保設定可以被正確儲存和應用，並且不會對其他功能造成影響。

### 總結：

3.1.3 儀表設定條款允許操作者根據個人喜好定制儀表板的顯示方式，提升使用者體驗。供應商需要仔細理解這些需求，並在軟體開發、硬體支援和測試驗證等方面予以充分考慮，以確保最終產品可以提供靈活、實用且易於操作的儀表設定功能。

## 3.1.4 車輛功能需求分析

此需求列出了操作者可以與車輛互動的功能，使用戶能夠控制和調整車輛的各種功能。

**條款內容：**

* 3.1.4 車輛功能 (R.6): 操作者可以與車輛互動的車輛功能：
* 安全
* 速度限制
* 行程表
* 診斷選單
* 工廠重置
* 行程時間
* 保養間隔
* 駕駛模式
* 省電模式
* 皮帶溫度
* 加熱/通風座椅
* 等等

### 條款分析：

* **功能廣泛性：** 此條款列舉了多種車輛功能，涵蓋安全、性能、舒適性、保養等多個方面，使用戶能夠全面地控制和調整車輛。
* **安全性：** 安全功能，例如速度限制和安全系統，可以提升行車安全，例如 中提到的影響車輛安全操作的失效模式，其嚴重程度評級為 10。
* **性能與效率：** 駕駛模式和省電模式可以讓使用者根據不同的駕駛需求調整車輛的性能和油耗表現。
* **舒適性：** 加熱/通風座椅等功能可以提升駕駛和乘客的舒適性。
* **保養維護：** 保養間隔和診斷選單可以幫助使用者了解車輛的保養需求，並及時進行維護。
* **可擴展性：** "等等" 的說法表明此列表並不詳盡，未來可以根據需要添加新的功能，例如 中提到的通過顯示器解鎖 VCM 防盜器等功能改進。

### 與其他條款的關聯性：

* **3.1 使用者介面 (R.2):** 車輛功能的設計應該與整體使用者介面風格保持一致，並且易於操作和理解。
* **3.3 診斷 (R.3):** 診斷選單功能與此條款相關聯，可以讓使用者查看車輛故障碼和進行診斷測試。
* **3.42 安全 (R.1):** 安全功能與此條款相關聯，可以讓使用者設定和控制車輛的安全系統，例如防盜系統和速度限制等。
* **其他相關條款：** 其他相關條款包括行程表 (3.50)、保養間隔 (3.43)、駕駛模式 (3.22)、省電模式 (3.14)、皮帶溫度 (3.15)、加熱握把 (3.34)、座椅加熱/通風等功能的具體需求。

### 對供應商的影響：

* **硬體整合：** 供應商需要整合必要的硬體元件來支援這些功能，例如感測器、執行器、控制模組等。
* **軟體開發：** 供應商需要開發軟體來實現這些功能的控制邏輯、使用者介面和與車輛其他系統的通訊。
* **安全性設計：** 對於安全相關的功能，供應商需要考慮安全性設計，例如防止未經授權的訪問和操作。
* **測試驗證：** 供應商需要測試和驗證這些功能的正確性和穩定性，確保功能可以按照預期工作，並且不會對其他功能造成影響。

### 總結：

3.1.4 車輛功能條款定義了操作者可以與車輛互動的功能，涵蓋了多個方面，提升了車輛的功能性和使用者體驗。供應商需要仔細理解這些需求，並在硬體整合、軟體開發、安全性設計和測試驗證等方面予以充分考慮，以確保最終產品可以提供安全、可靠、易於操作的車輛功能。

## 3.2 線上更新 (Reflash) 需求分析

這些需求概述了元件線上更新的功能、方法和效能要求。線上更新是指在不拆卸元件的情況下更新其軟體。

**條款內容：**

* **3.2 線上更新 (R.6):** 元件應具備透過 CAN 匯流排進行線上更新的能力。
* **3.2.1 UDS 線上更新 (R.5):** 軟體應支援 Polaris 通用 UDS 線上更新規範 ENG-SPEC-01337 中定義的重新程式設計。
* **3.2.2 雙映像線上更新 (R.4):** 元件應具備雙映像線上更新能力（即在其中一個映像上運行，在另一個映像分區上進行線上更新，驗證線上更新是否成功，切換到新的映像）。
* **3.2.3 應用軟體線上更新 (R.5):** 模組應具備應用軟體線上更新能力。
* **3.2.4 線上更新失敗 (R.5):** 在任何線上更新失敗/不完整/不正確的情況下（包括選擇錯誤的程式設計檔案），控制器應根據 ENG-SPEC-00377 進行恢復。
* **3.2.5 線上更新服務工具 (R.8):** 元件應能夠使用現有的 Polaris 服務工具（例如 Digital Wrench）透過 CAN 匯流排執行線上更新。
* **3.2.6 OTA 線上更新 (R.1):** 元件應能夠使用 Polaris 連接設備（例如車載資通訊控制單元）透過 CAN 匯流排執行線上更新。
* **3.2.7 線上更新時間 (R.5):** 重新線上更新時間應少於三分鐘。
* **3.2.8 設定保留 (R.1):** 各種設定應在線上更新後保留（例如使用者設定、里程表等）。具體的設定保留要求將在軟體需求部分的詢價單中提供。

### 條款分析：

* **線上更新的必要性:** 線上更新允許 Polaris 在車輛生命週期內更新軟體，以修復錯誤、改進功能或添加新功能。這對於保持車輛的競爭力和提供良好的使用者體驗至關重要。
* **UDS 標準:** 使用 UDS 標準 (ISO 14229) 可以確保線上更新過程的互通性和可靠性。 UDS 規範詳細說明了線上更新的步驟、訊息和狀態。 元件必須能夠處理標準中定義的所有必要請求和響應。 此外，Polaris 使用特定的 DID (資料識別碼) 來識別和管理元件及其軟體版本。
* **安全性:** 安全線上更新流程對於防止未經授權的軟體修改至關重要。 Polaris 使用基於種子和密鑰的安全機制來保護線上更新過程。 元件必須通過安全驗證才能進行線上更新。 Polaris 也使用安全的程式設計策略來確保線上更新的完整性和真實性。 這包括驗證標頭、資料驗證和金鑰管理。
* **雙映像:** 雙映像線上更新可以最大限度地減少線上更新期間的停機時間。元件可以在一個映像上運行，同時在另一個映像上進行線上更新。 成功完成線上更新後，元件可以切換到新的映像。
* **服務工具和 OTA:** 支援使用現有服務工具和 OTA 更新，為 Polaris 提供了靈活的線上更新選項。服務工具可由經銷商用於維護和修復，而 OTA 更新允許 Polaris 遠端更新車輛。
* **效能:** 三分鐘的線上更新時間限制確保了線上更新過程的效率。
* **設定保留:** 保留使用者設定和其他重要資料可以提升使用者體驗並避免資料丟失。

### 與其他條款的關聯性：

* **3.1 使用者介面 (R.2):** 線上更新過程可能會需要使用者介面來顯示進度和狀態。
* **3.3 診斷 (R.3):** 診斷功能可以用於檢查線上更新的結果和識別線上更新過程中發生的任何錯誤。
* **2.6 快閃記憶體/RAM/CPU/非揮發性記憶體 (R.4):** 線上更新過程需要足夠的記憶體資源來儲存新的軟體映像和執行線上更新程式。
* **2.12 即時時鐘 (R.5):** 即時時鐘可以用於記錄線上更新的時間戳。

### 對供應商的影響：

* **軟體開發:** 供應商需要開發符合 Polaris UDS 線上更新規範和安全程式設計策略的軟體。
* **硬體設計:** 硬體需要支援雙映像線上更新和安全的程式設計功能。
* **測試和驗證:** 供應商需要徹底測試和驗證線上更新過程，以確保其可靠性、安全性、效能和設定保留。

### 總結：

3.2 線上更新條款定義了元件線上更新功能的完整需求。供應商需要仔細理解這些需求，並在軟體開發、硬體設計和測試驗證等方面予以充分考慮，以確保最終產品可以提供安全、可靠、高效且易於使用的線上更新功能。

## 3.3 診斷功能需求分析

這些需求定義了元件應支援的診斷協議、診斷選單的功能以及如何顯示和管理診斷故障碼 (DTC)。

**條款內容：**

* **3.3 診斷 (R.3):** 元件應支援以下診斷協議：
* J1939
* UDS (專用)
* J2012 3 位元組 DTC (專用)
* **3.3.1 診斷選單 (R.5):** IVI 應在診斷選單中顯示 DTC 資訊
* **3.3.1.1 診斷資訊保留 (R.6):** IVI 應透過鑰匙循環、斷電和重新刷寫清除診斷選單中的 DTC 資訊
* **3.3.1.2 主動診斷 (R.6):** IVI 應在診斷選單中顯示主動 DTC 的資訊
* **3.3.1.3 先前主動診斷 (R.6):** IVI 應在診斷選單中將該鑰匙循環中先前主動的 DTC 資訊（目前非主動）灰顯
* **3.3.1.4 診斷選單優先順序 (R.6):** 診斷選單中的 DTC 應按照其變為主動狀態的順序顯示（例如，第二個主動 DTC 顯示在診斷選單中的第二個位置）
* **3.3.1.5 已知 DTC 的診斷格式 (R.6):** 已知 DTC 資訊應包含 P 碼、描述和糾正措施
* **3.3.1.6 未知 DTC 的診斷格式 (R.6):** 未知 DTC 資訊應包含 P 碼、來源位址和預設糾正措施

### 條款分析：

* **多種診斷協議支援:** 支援 J1939、UDS 和 J2012 3 位元組 DTC 確保元件可以與各種車輛系統和診斷工具進行通訊。
* J1939 是一種廣泛應用於商用車輛的標準通訊協議，用於診斷和控制。
* UDS 是一種由 ISO 制定的標準化診斷協議，廣泛應用於汽車行業。
* J2012 3 位元組 DTC 是一種特定於 Polaris 的專用診斷協議。
* **使用者友善的診斷介面:** 診斷選單提供了一個集中的位置來顯示 DTC 資訊，使操作員可以輕鬆查看和了解車輛的健康狀況。
* **DTC 管理:** 透過清除鑰匙循環、斷電和重新刷寫後的 DTC 資訊，可以確保診斷選單始終顯示最新的診斷資訊。
* 主動 DTC 資訊的顯示讓操作員可以立即了解車輛的當前問題。
* 將先前主動的 DTC 資訊灰顯有助於操作員追蹤 DTC 的歷史記錄並識別間歇性問題。
* 按照 DTC 變為主動狀態的順序顯示它們可以幫助操作員優先處理需要立即關注的問題。
* **詳細的 DTC 資訊:** 為已知 DTC 提供 P 碼、描述和糾正措施，為操作員提供了解決問題所需的必要資訊。
* 包含未知 DTC 的 P 碼、來源地址和預設糾正措施有助於診斷和排除無法識別的 DTC 問題。

### 與其他條款的關聯性：

* **3.2 線上更新 (R.6):** 線上更新過程可能會清除 DTC 資訊，這與診斷資訊保留需求相關。
* **3.3.2 J1939 (R.5):** 此條款詳細說明了 IVI 應支援的特定 J1939 診斷訊息，例如 DM1、DM2、DM3、DM14、DM15 和 DM16。這些訊息用於請求和傳輸各種診斷資訊，例如主動 DTC、先前主動 DTC、記憶體讀取/寫入等。
* **3.3.3 UDS (R.2):** 此條款定義了 IVI 應支援的特定 UDS 服務，例如 0x19 服務（讀取 DTC 資訊）。
* **3.3.4 J2012 3 位元組 DTC (R.4):** 此條款定義了IVI如何接收和顯示 J2012 3 位元組 DTC。

### 對供應商的影響：

* **軟體開發:** 供應商需要開發軟體來實現所有必要的診斷協議、管理 DTC 資訊、並根據規範設計診斷選單。
* **硬體設計:** 硬體需要支援所有規範的通訊介面和診斷功能。
* **測試和驗證:** 供應商需要徹底測試和驗證診斷功能，以確保其正確性、可靠性和使用者友善性。

### 總結:

3.3 診斷條款定義了元件診斷功能的完整需求。供應商需要仔細理解這些需求，並在軟體開發、硬體設計和測試驗證等方面予以充分考慮，以確保最終產品可以提供全面的診斷功能，並方便操作員識別和解決車輛問題。

## 3.3.2 J1939 需求分析

這些需求定義了元件與車輛 CAN 匯流排通訊時，應遵循的 J1939 標準和 Polaris 專用網路協議。

**條款內容：**

* **3.3.2 J1939 (R.5):** 元件應支援 J1939。
* **3.3.2.1 網路介面合規性 (R.4):** IVI 應符合以下網路介面標準和 Polaris 專用網路協議：
* **3.3.2.1.1 SAE J1939 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939 進行通訊 - 串列控制和通訊車輛網路的建議實務。
* **3.3.2.1.2 SAE J1939-11 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-11 進行通訊 - 實體層，250 Kbps，遮蔽雙絞線 (STP)。
* **3.3.2.1.3 SAE J1939-14 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-14 進行通訊 - 實體層，500 Kbps。
* **3.3.2.1.4 SAE J1939-15 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-15 進行通訊 - 實體層，250 Kbps，非遮蔽雙絞線 (UTP)。
* **3.3.2.1.5 SAE J1939-21 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-21 進行通訊 - 資料鏈路層。
* **3.3.2.1.6 SAE J1939-71 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-71 進行通訊 - 應用層 - 車輛。
* **3.3.2.1.7 SAE J1939-73 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-73 進行通訊 - 應用層 - 診斷。
* **3.3.2.1.8 SAE J1939-81 (R.4):** 模組應透過車輛 CAN 匯流排按照 SAE J1939-81 進行通訊 - 網路管理。
* **3.3.2.1.9 ENG-SPEC-00375 (R.4):** 模組應透過車輛 CAN 匯流排按照 ENG-SPEC-00375 進行通訊：Polaris 通用診斷協議規範。
* **3.3.2.1.10 ENG-SPEC-01337 (R.3):** 模組應透過車輛 CAN 匯流排按照 ENG-SPEC-01337 進行通訊：Polaris 通用 UDS 重新刷寫規範。

### 條款分析：

* **J1939 標準合規性:** 這些需求表明元件必須完全符合一系列 SAE J1939 標準，涵蓋實體層、資料鏈路層、應用層和網路管理。遵守這些標準可確保元件與其他車載系統的互通性和可靠通訊。
* **實體層 (J1939-11, J1939-14, J1939-15):** 這些標準定義了 CAN 匯流排的電氣特性，包括電壓準位、訊號速度和纜線類型。元件必須支援 250 Kbps 和 500 Kbps 的速度，以及遮蔽和非遮蔽雙絞線。
* **資料鏈路層 (J1939-21):** 該標準定義了如何封裝和傳輸資料幀，包括訊息格式、錯誤偵測和流量控制。元件必須能夠正確處理和傳輸 J1939 資料幀。
* **應用層 (J1939-71, J1939-73):** 這些標準定義了特定應用程式使用的訊息格式和通訊協議，例如車輛控制和診斷。元件必須支援車輛相關功能和診斷服務的 J1939 訊息。
* **網路管理 (J1939-81):** 該標準定義了管理 CAN 匯流排上的節點和通訊的機制，包括節點位址分配、錯誤處理和網路狀態監控。元件必須能夠參與 J1939 網路管理功能。
* **Polaris 專用協議:** 除了標準 J1939 協議之外，元件還必須支援 Polaris 的專用協議，例如 ENG-SPEC-00375（通用診斷協議規範）和 ENG-SPEC-01337（通用 UDS 重新刷寫規範）。這些協議定義了特定於 Polaris 車輛的額外功能和服務，例如診斷故障碼處理、記憶體讀取/寫入以及線上更新流程。

### 與其他條款的關聯性：

* **3.2 線上更新 (R.6):** J1939 標準和 ENG-SPEC-01337 提供了線上更新的通訊基礎架構。
* **3.3 診斷 (R.3):** J1939-73 和 ENG-SPEC-00375 定義了元件應支援的診斷功能。

### 對供應商的影響：

* **硬體設計:** 供應商需要選擇符合 J1939 實體層標準的 CAN 收發器，並確保硬體能夠處理 J1939 訊息的傳輸和接收。
* **軟體開發:** 供應商需要開發軟體來實作所有必要的 J1939 協議、服務和 Polaris 專用協議。這包括訊息處理、錯誤偵測和處理，以及網路管理功能。
* **測試和驗證:** 供應商需要徹底測試和驗證 J1939 通訊功能，以確保其符合所有相關標準和 Polaris 規範。這包括一致性測試、互通性測試和壓力測試，以確保在各種操作條件下可靠的通訊效能。

### 總結:

3.3.2 J1939 條款定義了元件與車輛 CAN 匯流排通訊時，應遵循的 J1939 標準和 Polaris 專用網路協議。供應商需要仔細理解這些需求，並在硬體設計、軟體開發和測試驗證等方面予以充分考慮，以確保最終產品可以與其他車載系統進行可靠、安全的通訊。

## 3.3.2.2 車輛 DTC - 協議支援 需求分析

這些需求定義了IVI 應該支援的 J1939 診斷協議訊息，以實現車輛診斷功能。

**條款內容：**

* **3.3.2.2 車輛 DTC - 協議支援 (R.5):** IVI 應支援以下 J1939 診斷協議：
* **3.3.2.2.1 DM1 - 主動診斷故障碼 (R.4):** 設備應支援 Polaris 通用診斷協議規範 ENG-SPEC-00375 中定義的 "主動診斷故障碼" (DM1) 訊息。
* **3.3.2.2.2 DM2 - 先前主動診斷故障碼 (R.4):** 設備應支援 Polaris 通用診斷協議規範 ENG-SPEC-00375 中定義的 "先前主動診斷故障碼 (DM2)" 訊息。
* **3.3.2.2.3 DM3 - 診斷資料清除/重置先前主動 DTC (R.4):** 設備應支援 Polaris 通用診斷協議規範 ENG-SPEC-00375 中定義的 "診斷資料清除/重置先前主動 DTC (DM3)" 訊息。
* **3.3.2.2.4 DM14 - 記憶體存取請求 (R.5):** 設備應支援 Polaris 通用診斷協議規範 ENG-SPEC-00375 中定義的 "記憶體存取請求 (DM14)" 訊息。
* **3.3.2.2.5 DM15 - 記憶體存取回應 (R.5):** 設備應支援 Polaris 通用診斷協議規範 ENG-SPEC-00375 中定義的 "記憶體存取回應 (DM15)" 訊息。
* **3.3.2.2.6 DM16 - 二進制資料傳輸 (R.5):** 設備應支援 Polaris 通用診斷協議規範 ENG-SPEC-00375 中定義的 "二進制資料傳輸 (DM16)" 訊息。
* **3.3.2.2.7 DM13，停止啟動廣播 (R.3):** 控制器應回應 J1939-73 第 5.7.13 節中描述的 DM13 停止/啟動廣播功能，以減少某些操作（例如控制器重新編程）期間的匯流排流量。 控制器應支援來自任何來源地址的 DM13。

### 條款分析：

* **DTC 訊息支援:** 這些需求確保 IVI 可以處理和顯示車輛的診斷故障碼資訊。
* **DM1** 訊息用於傳輸當前存在的 DTC。
* **DM2** 訊息用於傳輸先前存在的 DTC，這些 DTC 可能已被清除但仍儲存在控制器記憶體中。
* **DM3** 訊息用於從控制器記憶體中清除先前存在的 DTC。
* **記憶體存取訊息支援:** 這些需求確保 IVI 可以存取和修改控制器記憶體，這對於診斷和程式設計至關重要。
* **DM14** 訊息用於向控制器發送記憶體讀取或寫入請求。
* **DM15** 訊息包含控制器對 DM14 請求的回應，可能包含請求的資料或錯誤代碼。
* **DM16** 訊息用於在 IVI 和控制器之間傳輸大量資料，例如程式碼更新或校準資料。
* **匯流排流量管理:** DM13 訊息提供了一種在特定操作期間減少 CAN 匯流排流量的方法，例如重新程式設計控制器。 透過暫停非必要訊息的傳輸，可以確保重新程式設計過程的穩定性和效率。
* **與其他規範的一致性:** 所有訊息的定義都參考 Polaris 通用診斷協議規範 ENG-SPEC-00375 和 SAE J1939-73，以確保與 Polaris 車輛架構的一致性。

### 與其他條款的關聯性：

* **3.3 診斷 (R.3):** 此條款定義了 IVI 應支援的診斷協議，包括 J1939。
* **3.3.1 診斷選單 (R.5):** 此條款定義了 IVI 如何在診斷選單中顯示 DTC 資訊，這些資訊是透過上述 J1939 訊息獲取的。
* **3.2 線上更新 (R.6):** 此條款定義了線上更新流程，其中 DM13、DM14、DM15 和 DM16 訊息可能用於傳輸程式碼和資料。

### 對供應商的影響：

* **軟體開發:** 供應商需要開發軟體來處理和解析所有必要的 J1939 診斷訊息。這包括訊息格式解析、錯誤處理、資料解釋以及與 IVI 應用程式邏輯的整合。
* **硬體設計:** 硬體需要支援 J1939 CAN 匯流排通訊，並提供必要的資源來處理訊息傳輸和接收。
* **測試和驗證:** 供應商需要徹底測試和驗證 IVI 的 J1939 診斷功能。這包括訊息格式驗證、錯誤處理測試、資料一致性驗證以及與控制器和其他車輛系統的互通性測試。

### 總結:

3.3.2.2 車輛 DTC - 協議支援條款定義了 IVI 應支援的 J1939 診斷訊息，以實現車輛診斷功能。供應商需要仔細理解這些需求，並在軟體開發、硬體設計和測試驗證等方面予以充分考慮，以確保最終產品可以與車輛系統進行可靠、安全的通訊，並提供準確的診斷資訊。

## 3.3.2.2.8-3.3.2.2.12 需求分析：軟體識別、訊息傳輸和地址管理

這些需求闡述了IVI 必須支援的額外 J1939 訊息，以實現軟體識別、訊息傳輸和地址管理等功能。

**條款內容：**

* **3.3.2.2.8 ECUID - 軟體識別符 (R.5):** 設備應支援 "軟體識別符 (ECUID)" 訊息。 透過協議特定的方法，所有 ECU 都應提供 ECUID 欄位，包括設備/模組及其軟體內容的識別資訊，以供任何請求的有效來源地址使用。 ECUID 可以透過 PGN 65242 (軟體識別) 讀取，並使用標準的 59904 PGN 請求訊息請求，其中請求的 PGN 設定為 65242，PDU 特定欄位指示要識別的控制器地址。 回應格式應使用傳輸協定傳輸 ID 區塊，如控制器的軟體需求規範中所述。 ECUID 欄位包含以下內容：Polaris 型號、供應商硬體零件號、硬體序號、車輛識別碼 (VIN)、Polaris 未程式設計硬體零件號、Polaris 程式設計組件零件號、供應商開機程式碼識別符、軟體版本號、Polaris 軟體零件號、應用程式快閃記憶體校驗和或 CRC-32，以及 Polaris S 編號。
* **3.3.2.2.9 RQST - 請求 (R.5):** 設備應支援 J1939-21 中定義的 "請求 (RQST)" 診斷訊息。
* **3.3.2.2.10 AC - 地址聲明 (R.5):** 設備應支援 "地址聲明 (AC)" 診斷訊息。 當控制器啟動時，它應該從它嘗試聲明的來源地址廣播一個名稱 ID (由 Polaris 定義) 在訊息 ID 0xEEFF 中。 如果沒有其他控制器從相同的聲明地址廣播自己的名稱 ID，則該控制器擁有該地址。 控制器必須能夠回應地址聲明中自身地址的請求。
* **3.3.2.2.11 TPCM - 傳輸協定連接管理器 (R.6):** 設備應支援 J1939-21 中定義的傳輸協定連接管理器 (TPCM)。
* **3.3.2.2.12 TPDT - 傳輸協定資料傳輸 (R.3):** 設備應支援 J1939-21 中定義的傳輸協定資料傳輸 (TPDT)。

### 條款分析：

* **軟體識別:** ECUID 訊息對於識別控制器及其軟體版本至關重要。
* 這些資訊可用於診斷、軟體更新和車輛維護等目的。
* IVI 需要能夠請求和解析 ECUID 訊息，以獲取必要的軟體資訊。
* **訊息請求和地址聲明:** RQST 和 AC 訊息是 J1939 網路管理的一部分，用於控制器之間的通訊和地址分配。
* RQST 訊息用於請求特定資訊，而 AC 訊息用於聲明控制器在網路上的地址。
* IVI 需要支援這些訊息以確保與車輛網路的正確整合。
* **傳輸協定:** TPCM 和 TPDT 訊息用於管理和傳輸大量資料，例如在軟體更新期間。
* TPCM 訊息用於建立和管理資料傳輸連接，而 TPDT 訊息用於傳輸實際資料。
* IVI 需要支援這些訊息以確保軟體更新和其他大型資料傳輸的可靠性和效率。

### 與其他條款的關聯性：

* **3.3 診斷 (R.3):** 這些訊息支援 J1939 診斷功能，允許 IVI 讀取 DTC、存取控制器記憶體和其他診斷操作。
* **3.2 線上更新 (R.6):** TPCM 和 TPDT 訊息對於線上更新過程至關重要，允許 IVI 安全地傳輸新的軟體映像到控制器。
* **3.4 ECUID 請求 (R.4):** 這些訊息與 ECUID 請求相關，提供有關 ECU 軟體和硬體的詳細資訊。

### 對供應商的影響：

* **軟體開發:** 供應商需要開發軟體來處理和解析所有指定的 J1939 訊息，包括 ECUID、RQST、AC、TPCM 和 TPDT。
* 軟體必須正確處理訊息格式、錯誤情況和資料解釋。
* 軟體應與 IVI 應用程式邏輯整合，以便以使用者友好的方式顯示 ECUID 資訊和其他診斷資料。
* **硬體設計:** IVI 硬體必須支援 J1939 CAN 匯流排通訊，並提供必要的資源來處理這些訊息。
* 硬體設計應考慮訊息傳輸和接收的時序要求，以及訊息緩衝和處理的需求。
* **測試和驗證:** 供應商需要徹底測試和驗證 IVI 的 J1939 訊息處理功能。
* 測試應涵蓋所有訊息類型、資料長度和錯誤情況。
* 驗證應確保 IVI 與不同控制器和車輛系統的互通性，並符合 Polaris 的規範。

### 總結:

3.3.2.2.8-3.3.2.2.12 條款定義了 IVI 應支援的額外 J1939 訊息，以實現軟體識別、訊息傳輸和地址管理等功能。 供應商需要仔細理解這些需求，並在軟體開發、硬體設計和測試驗證等方面予以充分考慮，以確保最終產品可以與車輛系統進行可靠、安全的通訊，並提供準確的診斷資訊。

## 3.3.3 UDS 需求分析：讀取 DTC 資訊和視覺化圖表

這些需求定義了IVI對UDS服務0x19（讀取DTC資訊）的支持，並要求提供在車輛啟動期間使用子功能0x02和0x08讀取DTC的視覺化圖表。

**條款內容：**

* **3.3.3 UDS (R.2):** 元件應支援以下 UDS 需求。
* **3.3.3.1 0x19 服務（讀取 DTC 資訊） (R.3):** IVI 應能夠支援服務 0x19（讀取 DTC 資訊）。
* **3.3.3.2 車輛啟動期間使用子功能 0x02 的 DTC (R.3)**
* **3.3.3.2.1 視覺化圖表 (R.2)**
* **3.3.3.3 車輛啟動期間使用子功能 0x08 的 DTC (R.2)**
* **3.3.3.3.1 視覺化圖表 (R.2)**

### 條款分析：

* **0x19 服務支持:** 該需求規定IVI必須支持UDS服務0x19，該服務用於從車輛ECU讀取診斷故障碼（DTC）資訊。 UDS服務是在ISO 14229標準中定義的，0x19服務允許診斷工具讀取DTC的狀態、嚴重程度和其他相關資訊。
* **子功能 0x02 和 0x08:** 這些子功能指定了在車輛啟動期間讀取DTC的特定條件。
* 子功能0x02可能會用於讀取啟動過程中出現的DTC，而子功能0x08可能會用於讀取與特定操作條件相關的DTC。
* 這些子功能的具體行為和用途需要參考IVI和相關ECU的軟體需求規範。
* **視覺化圖表:** 該需求要求提供視覺化圖表來顯示使用子功能0x02和0x08讀取的DTC資訊。
* 這些圖表應該以清晰易懂的方式呈現DTC資訊，例如DTC代碼、描述、狀態和嚴重程度。
* 圖表的設計需要考慮IVI的顯示螢幕尺寸和分辨率，以及操作者的使用習慣。

### 與其他條款的關聯性：

* **3.3 診斷 (R.3):** 這些需求是IVI診斷功能的一部分，允許操作者或技術人員查看車輛的DTC資訊。
* **3.3.1 診斷選單 (R.5):** 視覺化圖表可能在IVI的診斷選單中顯示，以便於操作者查看。
* **3.2 線上更新 (R.6):** 線上更新過程可能會使用UDS服務來讀取DTC資訊，以驗證更新前後車輛的診斷狀態。

### 對供應商的影響：

* **軟體開發:** 供應商需要開發軟體來支持UDS服務0x19以及子功能0x02和0x08。
* 軟體需要處理與相關ECU的通訊，並正確解析和解碼DTC資訊。
* 軟體還需要生成符合需求規範的視覺化圖表。
* **硬體設計:** IVI硬體需要支持CAN匯流排通訊，以便與車輛ECU進行通訊。
* 硬體還需要滿足視覺化圖表顯示的要求，例如螢幕分辨率和色彩深度。
* **測試和驗證:** 供應商需要測試和驗證IVI對UDS服務0x19以及子功能0x02和0x08的支持。
* 測試需要涵蓋不同的DTC類型、狀態和嚴重程度。
* 驗證需要確保視覺化圖表能夠正確顯示DTC資訊，並且易於操作者理解。

### 總結:

3.3.3 UDS 條款定義了IVI對UDS服務0x19的支持，以及在車輛啟動期間使用子功能0x02和0x08讀取DTC的視覺化圖表要求。 供應商需要仔細理解這些需求，並在軟體開發、硬體設計和測試驗證等方面予以充分考慮，以確保最終產品可以與車輛系統進行可靠、安全的通訊，並提供準確、易懂的DTC資訊。