當我們開始支援不同 Streaming Source，真正麻煩的已經不是「Model 能不能跑」，而是 Data、Security 與 Runtime 怎麼走。

前面 14 天，我一直用一個很直覺的案例在講 Edge AI：

Camera → AI Model → Detection → Rule → Event

因為這是最容易理解的 Edge AI Use Case。

但做到這裡，我開始發現一件事情：

如果我們把 Edge AI Product 定義成「IP Camera AI」，產品很快就把自己限制住了。

因為客戶的 Video Source 不一定只有 IPCam。

可能是：

• RTSP Camera
• USB Camera
• MIPI / CSI Camera
• 本地 Video File
• Video Stream
• Network Stream
• 甚至是其他設備產生的影像資料

Qualcomm 的 Multimedia / Video 架構本身就是為了處理不同的 video source、decode / encode、processing 與 streaming pipeline，而不是只為一種 Camera Application 設計。
所以我開始問：

如果未來 Edge AI Application 不只吃 IPCam，它的 Input Architecture 應該怎麼設計？

1. 不要把「Camera」當成 Input

這是我覺得 Product Architecture 很重要的一個轉變。

一開始我們可能會設計：

IP Camera
    ↓
AI Application

但如果產品要擴展，我會更傾向：

                ┌─ RTSP
                ├─ MIPI / CSI
Video Source ───┼─ USB
                ├─ Local File
                └─ Other Stream
                      ↓
                 Video Pipeline
                      ↓
                   AI Model

也就是：

AI Application 不應該綁死在 Camera。

Camera 只是其中一種 Source。

2. Streaming 其實會影響整個 AI Pipeline

假設今天進來的是一個 RTSP Stream：

RTSP
 ↓
Network
 ↓
Decode
 ↓
Video Frame
 ↓
Pre-processing
 ↓
HTP
 ↓
Detection

如果換成另一種 Source：

MIPI / CSI
 ↓
Camera
 ↓
ISP / Video Pipeline
 ↓
Video Frame
 ↓
Pre-processing
 ↓
HTP

雖然最後都要進：

AI Model

但前面的 pipeline 已經完全不一樣。

所以我們真正要抽象的是：

Video Source → Standardized Frame → AI Pipeline

而不是：

IPCam → AI Model

3. Qualcomm 的 Streaming Architecture 值得 AI PM 看懂

為什麼 Edge AI Application 的架構不能只畫一條 Camera → AI。

Qualcomm 的 Video / Multimedia stack 裡，Video Source、memory、processing、encode/decode、streaming 等元件可以組成不同 pipeline。官方文件也提供 single-stream、multi-stream，以及同時輸出到 file 與 RTSP 等實際 pipeline 範例。

所以你的 Product Architecture 可以開始抽象成：

                Video Sources
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
       RTSP        MIPI/CSI       USB
        │            │            │
        └────────────┼────────────┘
                     ↓
              Video Abstraction
                     ↓
              Pre-processing
                     ↓
                  AI Model
                     ↓
                    HTP
                     ↓
                Detection
                     ↓
                   Rule
                     ↓
                  Event

4. 但這時候會出現另一個問題：Security

如果今天只是：

Camera → Person Detection

Security 可能不是第一個想到的事情。

但如果這個 Edge Device 是部署在工廠、醫療、交通或其他敏感環境：

影像資料本身可能就是敏感資料。

例如：

Camera
 ↓
Video
 ↓
AI
 ↓
Event

中間每一層都可能涉及：

• Video Data
• Model
• AI Result
• Credential
• Key
• Device Identity
• Customer Data

這時候就不能只問：

AI 跑多快？

還要問：

資料在哪裡跑？誰可以存取？

5. 這時候 TEE 就出現了

TEE：

Trusted Execution Environment

你可以先把它想成：

在一般 Linux / Normal World 之外，提供一個隔離的 Trusted Environment。

Qualcomm Linux 官方安全文件把架構區分成：

Normal World
Linux / Application
       │
       │ TEE Client API
       ↓
Trusted Execution Environment
       │
       ↓
Trusted Application

Trusted Application 可以在 TEE 中處理需要較高安全保證的工作；Normal World application 則透過 TEE Client API 與 Trusted Application 溝通。([Qualcomm Docs][2])

6. 但 TEE 不是「把整個 AI Application 丟進去」

這個地方非常重要。

我不會在產品架構裡寫：

AI Application
      ↓
TEE
      ↓
Everything runs securely

因為這樣太粗略。

更合理的思考是：

Normal World
──────────────────────────────
Video Pipeline
GStreamer
AI Application
QNN / Runtime
Rule Engine
Event
Docker
        │
        │ Secure API
        ↓
TEE
──────────────────────────────
Trusted Application
Secure Key
Credential
Sensitive Operation
Device Identity

也就是：

只有真正需要 Trust 的部分，才交給 TEE。

而不是為了「Security」把所有東西都塞進 TEE。

7. 那 AI Model 要不要放 TEE？

這就是一個很好的產品問題。

例如：

Model
 ↓
QNN
 ↓
HTP

到底要不要全部放進 Secure World？

不一定。

因為你要考慮：

• Performance
• Memory
• API availability
• Driver support
• TEE capability
• Development complexity
• Security requirement

所以真正的問題不是：

「TEE 比較安全，所以全部放 TEE。」

而是：

「哪些 Asset / Operation 真的需要 Trusted Execution？」

這是一個 Architecture Decision。

8. 例如 Model 本身可能不是最敏感的東西

假設：

YOLO Person Detection

這是一個公開 Pre-trained Model。

那你可能真正需要保護的不是 Model：

而是：

Customer Video
+
Device Credential
+
Private Key
+
Secure Configuration

這時候 Security Architecture 就可能變成：

Camera
   ↓
Video Pipeline
   ↓
AI Model / HTP
   ↓
Detection
   ↓
Rule
   ↓
Event
   │
   ├── Normal Application
   │
   └── Sensitive Operation
            ↓
           TEE

這比「所有 AI 都跑 TEE」更符合實際產品設計的思考方式。

9. 這也讓我重新思考 Edge AI Product 的 Architecture

前面我們一直在講：

Camera
 ↓
AI
 ↓
Event

現在開始變成：

                 Video Sources
                      ↓
               Streaming Layer
                      ↓
              Video Processing
                      ↓
                 AI Runtime
                      ↓
                   HTP
                      ↓
                 Detection
                      ↓
                   Rule
                      ↓
                   Event
                      ↓
          ┌───────────┴───────────┐
          ↓                       ↓
       Normal                  Trusted
      Operation                Operation
          ↓                       ↓
       Linux                    TEE

這時候才開始有一點真正 Edge AI Platform 的味道。

10. 而且這不只是 IPCam

這是我最想在 Day 15 帶出來的概念。

如果我們把 Product 定義成：

IPCam AI Platform

那我們的世界大概只有：

IPCam
 ↓
Detection

但如果定義成：

Edge AI Application Platform

那 Input 可以是：

RTSP
MIPI
USB
Video File
Other Streaming Source

Output 也不只是：

Bounding Box

而可以是：

Detection
 ↓
Rule
 ↓
Event
 ↓
Alert
 ↓
Recording
 ↓
Upload
 ↓
Edge Management

這個 Product Scope 就完全不一樣了。

11. 對AI PM 來說，真正要管理的是「邊界」

做到這裡，我覺得 AI PM 最重要的能力之一不是：

「知道每一個 Qualcomm API。」

而是：

知道每一層的責任邊界。

例如：

這樣當 Engineer 告訴我：

「這個功能需要改 Video Pipeline。」

我至少知道：

它不是 Model 問題。

如果說：

「這個 Credential 不能放在 Container 裡。」

我也知道：

這可能已經進入 Secure / TEE 的問題。

這就是 AI PM 跟純 Feature Owner 的差別。

Day 15 最後可以收這句

Edge AI 不只是把 AI Model 放到 Edge Device。

真正的 Edge AI Product，要同時處理：

Data 怎麼進來、Stream 怎麼走、AI 在哪個 Accelerator 執行、Detection 怎麼變成 Event，以及敏感資料怎麼被保護。

最後架構變成：

Video Source
     ↓
Streaming
     ↓
Video Pipeline
     ↓
AI Runtime
     ↓
HTP
     ↓
Detection
     ↓
Rule
     ↓
Event
     ↓
Action

        +
        
Security / TEE

而這也是我開始理解：

當 Edge AI 從一個 PoC 走向真正產品，效能只是其中一個問題。Architecture、Security、Deployment 和 Lifecycle，最後都會變成 Product Requirement。