Kiến trúc · Quản lý thiết bị · 20/7/2026

Quản lý thiết bị — mô hình 3 tầng MỚI

Trả lời: thiết bị DAT nên nằm ở module nào? Khi SUNS bán cả thiết bị DAT lẫn thiết bị sân bãi thì có gộp về một module quản lý thiết bị chung không? Kết luận ngắn: có gộp — nhưng không phải một module trong WS đào tạo, mà là một tầng riêng. Liên quan: Phương pháp chia module · module dat · Thiết bị phần cứng.

0

Dữ kiện làm đổi bản chất câu hỏi

Khi SUNS trở thành nhà cung cấp thiết bị (DAT + thiết bị sân bãi), thiết bị không còn thuộc về workspace khách hàng nữa — nó thuộc về SUNS và được cấp phát cho workspace. Theo dấu vòng đời một thiết bị sẽ thấy ngay:

nhập kho ─▶ gán seri ─▶ bán cho Vĩnh An ─▶ lắp lên xe 29A-xxx ─▶ chạy 2 năm ─▶ hỏng, RMA │ └──── đoạn DUY NHẤT nằm trong WS khách ────┘ │ └──────────────── tài sản của SUNS, ngoài mọi workspace khách hàng ──────────────────────┘ ▼ thay bo ─▶ tái xuất cho trung tâm khác
⚠️ Không module nào trong WS Vĩnh An chứa nổi chuỗi này: bảo hành, RMA, firmware, lịch sử chuyển chủ là tài sản dữ liệu của SUNS, không phải của Vĩnh An. Đây là lý do bài toán phải giải ở tầng, không phải ở chỗ đặt module.
1

Ba tầng — ai giữ dữ liệu gì

TầngỞ đâuQuản gì
① Nhà cung cấpWS riêng của SUNS
(đã có chỗ: "WS admin-console — vận hành nền tảng")
Sản xuất/nhập kho · seri · đời máy · hợp đồng bán–thuê · bảo hành / RMA · firmware & OTA · telemetry sức khỏe toàn fleet · hồ sơ hợp quy & kiểm chuẩn · lịch sử chuyển chủ
② Control PlaneCP (đã quản workspace, license, store) Cấp phát thiết bị → workspace · credential để thiết bị nói chuyện với hệ. Cùng bản chất với license — CP đã làm việc này rồi, chỉ thêm loại tài nguyên
③ Khách hàngWS đào tạo / WS sát hạch Thiết bị đang có tại trung tâm: gắn ở đâu · còn chạy không · bảo hành còn hạn không · gọi ai — cộng dữ liệu nghiệp vụ mà nó sinh ra
SUNS chạy chính hệ của mình trên OpenGate — ăn thức ăn mình nấu. Phần bán hàng/bảo hành tái dùng crm + finance built-in; chỉ phải tự viết phần fleet phần cứng (firmware, OTA, telemetry).
2

Trong WS khách hàng — cắt ranh giới ở đâu

Ở tầng ③, module device dùng chung xứng đáng tồn tại khi SUNS bán nhiều họ thiết bị cho cùng một trung tâm — nhưng phải cắt đúng chỗ, nếu không sẽ tái phạm đúng lỗi của student/course.

LớpChủ sở hữuNội dung & lý do
Danh tính · tài sản · sức khỏedevice Seri · đời máy · SIM · hạn bảo hành/hợp quy · trạng thái kết nối · firmware. Chung cho mọi họ thiết bị → đây là phần gộp được
Gắn vào đối tượng nghiệp vụdat · yard (v2) dat_gan_xe (thiết bị × xe × khoảng thời gian) ở lại module nghiệp vụ — dữ liệu tuân thủ có tính thời điểm, nằm trên đường nóng nhất: mọi phiên học đều phải quy về đúng xe
Payload (dữ liệu sinh ra)dat · yard · lms Phiên học DAT · kết quả chấm sa hình · log điểm danh — tuyệt đối không gộp
⚠️ Bẫy cần tránh — generic hóa payload. Phiên học DAT và kết quả chấm sa hình không có gì chung ngoài việc cùng do một cục phần cứng sinh ra. Chỉ tầng danh tính – tài sản – sức khỏe dùng chung được; xuống dưới nữa mỗi domain một mô hình riêng.

Màn hình tổng của kỹ thuật viên nằm ở device, đọc các view dat_v_gan_thiet_bi, yard_v_gan_thiet_bi (P1) — module nào chưa cài thì ẩn phần đó (quy tắc degrade).

3

Chấm lại 4 điều kiện tách — trước và sau khi SUNS bán thiết bị

Điều kiện §0TrướcSauVì sao đổi
① Bán riêng đượcSUNS bán thiết bị kèm gói "quản lý thiết bị & bảo hành"; trung tâm mua bộ sân bãi mà chưa mua module đối soát DAT vẫn cần sổ thiết bị
② Vòng đời nâng cấp riêngNhịp nâng cấp đi theo lịch phát hành phần cứng của SUNS, không theo thông tư đào tạo nữa
③ Người dùng chính khácKỹ thuật — nhưng đây là điều kiện yếu nhất, tầng feature đã lo tách quyền rồi
④ Cài/gỡ độc lập✅ một chiềuSổ thiết bị đứng một mình có nghĩa; dat phụ thuộc nó. Phụ thuộc một chiều lành — giống catalog

Trước dữ kiện mới: 1/4 → không tách. Sau: 3,5/4 → xứng đáng một module ở tầng ③ (nhưng chưa phải bây giờ — xem mục 4).

4

Lộ trình — làm gì, khi nào

MốcViệc
MVP (nay)Chưa xây module device — không phải vì sai, mà vì hình dạng của nó do nghiệp vụ nhà cung cấp quyết định, mà nghiệp vụ đó chưa tồn tại. Xây trước là đoán mò. Thay vào đó làm 3 việc rẻ ở mục 5
v2 — bộ xe chipHọ thiết bị thứ hai xuất hiện trong WS khách → tách module device (sổ thiết bị của trung tâm). Đổi prefix dat_thiet_bidevice_thiet_bi — thao tác cơ học nếu đã giữ sạch
Khi SUNS bán thiết bị thậtDựng WS của SUNS (tầng ①) + CP provisioning (tầng ②). Đây là sản phẩm riêng, không nhét vào WS khách
Nguyên tắc bất đối xứng (áp cho mọi quyết định kiểu này): gộp sớm rẻ và an toàn — tách sớm là đánh cược. Gộp student+course là bỏ một ranh giới chưa từng kiếm được chỗ đứng, sai thì tách lại trong cùng module rất rẻ. Tạo module device bây giờ là dựng ranh giới cho nhu cầu chưa xuất hiện — trả chi phí ngay để đổi lấy lợi ích còn là dự đoán. Lý lẽ "chưa go-live nên sửa thoải mái" biện minh mạnh cho vế đầu, yếu hơn nhiều cho vế sau.
5

3 việc làm ngay ở MVP (rẻ hôm nay, đắt nếu sửa sau)

① Giữ dat_thiet_bi sạch

  • Chỉ thuộc tính chung của một thiết bị: seri, loại, SIM, hạn, trạng thái, nhật ký kết nối
  • Tuyệt đối không để cột nghiệp vụ phiên học/đối soát lẫn vào
  • Bài học từ training: cái đắt khi tách muộn là logic quấn vào nhau, không phải tên bảng

② Seri là khóa toàn cục

  • Do SUNS cấp phát, duy nhất trên toàn bộ khách hàng — không phải duy nhất trong một WS
  • Đây là thứ cho phép thiết bị chuyển từ trung tâm A sang B mà vẫn truy được lịch sử
  • Dữ liệu kỳ A thuộc về A — mỗi WS chỉ giữ đoạn của mình, chuỗi đầy đủ ở tầng ①

③ Chuyển binding về dat

  • Bỏ feature device-bind + cột seri_dat/dat_device_id khỏi vehicle
  • Đúng bất kể sau này có module device hay không — và dọn sẵn chỗ
  • Chi tiết lý do: mục 6
6

Vì sao binding chuyển từ vehicle về dat

Hiện thiết bị DAT bị xẻ làm ba nơi: dat.device (sổ thiết bị) · vehicle.device-bind (lịch sử gắn/tháo + cột seri_dat, dat_device_id) · fleet.asset v1.5 (tài sản, khấu hao). Ba mặt của một vật thể là bình thường trong DDD — vấn đề là cắt sai chỗ.

Lý doGiải thích
Chiều phụ thuộc đang ngượcvehicle đang phải biết DAT tồn tại. Đúng ra vehicle là danh mục tài sản nền, phải sống được khi dat chưa cài; còn dat là module tuân thủ chuyên biệt, phụ thuộc vehicle mới hợp lý. Chuyển binding = sửa đúng chiều mũi tên, đồng thời xóa mâu thuẫn dat_device_id vs seri_datreview §2.3 ghi nợ từ 6/7
Vật thể di động sở hữu quan hệThiết bị là thứ tháo ra lắp vào, xe đứng yên. Quan trọng hơn: mô hình đặt ở phía vehicle không biểu diễn được thiết bị chưa gắn xe nào — hàng dự phòng trong kho, thiết bị đang gửi bảo hành, thiết bị vừa nhập chưa lắp
Đường nóng thành nội bộImport phiên → resolve seri → xe tại thời điểm phiên chạy: chạy trên mọi bản ghi phiên. Để nó thành join nội bộ trong dat thay vì đọc chéo module
Một chỗ làm một việcKỹ thuật viên hiện phải vào vehicle để gắn, vào dat để xem tình trạng
Chiều ngược lại vẫn giữ nguyên: quy tắc "xe đủ điều kiện dạy = giấy phép xe tập + đăng kiểm + DAT hợp quy" thì vehicle đọc dat_v_thiet_bi_theo_xe (P1, chỉ-đọc); theo quy tắc degrade, dat chưa cài thì bỏ qua điều kiện DAT chứ không crash.
7

Hệ quả: SUNS thành nơi nhận dữ liệu

Nếu SUNS làm thiết bị thì SUNS cũng là nơi thiết bị gửi dữ liệu về, thay vì kéo từ vendor thứ ba.

TRƯỚC — vendor thứ ba: thiết bị ─▶ cloud vendor ─▶ connector kéo theo lịch ─▶ dat.session SAU — SUNS là vendor: thiết bị ─▶ hệ SUNS ─────▶ push gần thời gian thực ─▶ dat.session └─▶ Cục Đường bộ (nghĩa vụ truyền)
⚠️ Việc phải chốt sớm: format sự kiện chuẩn nội bộ. Đây là hợp đồng giữa phần cứng và phần mềm — sửa sau thì phải cập nhật firmware ngoài hiện trường, đắt hơn mọi refactor phần mềm. Rẻ hơn nhiều: bỏ mấy ngày định nghĩa cho chuẩn ngay từ giờ.