Analytics trên server trung tâm và thiết bị edge Jetson cho cảnh báo camera

Bài toán thực tế

Đội vận hành cần nhận thông báo tức thì khi có người hoặc phương tiện đi vào vùng giới hạn hoặc vượt qua vạch ranh giới trên hàng loạt camera hoạt động 24/7. Một số site nghiêm cấm đưa luồng video ra khỏi khuôn viên; các site khác cho phép gửi luồng về xử lý tại server trung tâm.

Kiến trúc hệ thống

Mô hình A — Chạy analytics trên server trung tâm

Áp dụng khi chính sách an ninh cho phép truyền luồng video về server trung tâm để xử lý detection tập trung. Đây là một mô hình triển khai độc lập và hoàn chỉnh — không phải bước trung gian trước khi chuyển sang mô hình thiết bị edge ở lựa chọn B.

flowchart LR
  subgraph cameras ["Tại site"]
    cameras_0(["Cameras at the site"])
  end
  subgraph server ["Analytics server"]
    server_0["RTSP ingest"]
    server_1[["Bounded queue · drop-oldest"]]
    server_2["YOLO detect and track"]
    server_3["Zone and line rules"]
  end
  subgraph messaging ["Event paths"]
    messaging_0[["Alert queue"]]
    messaging_1[["Metric queue"]]
    messaging_2[["Archival queue"]]
    messaging_3["Redis alert dedup"]
  end
  subgraph control ["Control plane"]
    control_0["NestJS camera admin and APIs"]
    control_1["OIDC identity service"]
  end
  subgraph persist ["Stores"]
    persist_0[("PostgreSQL alerts")]
    persist_1[("TimescaleDB metrics")]
    persist_2[("Object storage clips")]
  end
  cameras_0 -->|"video streams"| server_0
  server_0 --> server_1
  server_1 --> server_2
  server_2 --> server_3
  server_3 --> messaging_0
  server_3 --> messaging_1
  server_3 --> messaging_2
  messaging_0 --> messaging_3
  messaging_3 --> persist_0
  messaging_1 --> persist_1
  messaging_2 --> persist_2
  control_0 -->|"config"| server_0
  control_1 --> control_0

Mô hình B — Thiết bị Jetson đặt tại site (thay thế cho A, không chạy nối tiếp sau A)

Áp dụng khi video tuyệt đối không được rời khỏi khuôn viên (site). Quá trình detection diễn ra ngay trên thiết bị Jetson tại chỗ; chỉ có metadata của cảnh báo được gửi ra ngoài. Mỗi site chỉ vận hành theo mô hình A hoặc B — không bao giờ ghép nối cả hai.

flowchart LR
  subgraph site ["Tại site"]
    site_0(["Cameras at the site"])
    site_1(["Orin NX appliance"])
  end
  subgraph appliance ["Trên appliance"]
    appliance_0["DeepStream and TensorRT engine"]
    appliance_1["Python appliance control software"]
    appliance_2["Signed USB or OTA update"]
  end
  subgraph leaving ["Dữ liệu rời khỏi site"]
    leaving_0[["Alert queue"]]
    leaving_1["Redis alert dedup"]
    leaving_2[("PostgreSQL alerts")]
  end
  site_0 -->|"local video only"| site_1
  site_1 --> appliance_0
  appliance_1 -->|"manages the appliance"| appliance_0
  appliance_2 -->|"verified update"| appliance_1
  appliance_0 -->|"alert metadata only — no video"| leaving_0
  leaving_0 --> leaving_1
  leaving_1 --> leaving_2

Sơ đồ minh họa tương tác

Các quyết định kiến trúc then chốt

Quy mô vận hành

• Technical Lead dẫn dắt đội ngũ tối đa 10 kỹ sư; trực tiếp viết code phần inference và API
• Nền tảng control-plane cốt lõi được tái sử dụng cho 3 sản phẩm enterprise
• Hai mô hình triển khai độc lập: xử lý tập trung trên server và xử lý tại chỗ trên thiết bị Jetson Orin NX

Các chỉ số giám sát khi vận hành

Nguyên tắc bất di bất dịch trong thiết kế

• Một stream bị quá tải hoặc đứt kết nối không bao giờ được làm gián đoạn các stream khác.
• Cảnh báo phải đến tay vận hành viên trong vài giây ngay cả khi tải cao, không được phép trễ hàng chục giây.
• Mọi truy vấn đều phải cô lập theo tenant; một tenant tuyệt đối không thể đọc được camera hay sự kiện của tenant khác.

Phạm vi ứng dụng rộng hơn

• Hệ thống camera giám sát cố định quy mô lớn hoạt động trên đường truyền mạng không ổn định.
• Các khu vực yêu cầu giữ toàn bộ dữ liệu hình ảnh tại chỗ nhưng vẫn cần quản trị tập trung.
• Trung tâm điều hành cần cảnh báo xâm nhập vùng/vạch có độ tin cậy cao và ít báo giả.