Datasource đầu ra

🤖 Bản dịch này do máy tạo và đang chờ người kiểm duyệt. Trang tiếng Anh là bản chuẩn.

Một datasource đầu ra ghi dữ liệu ra một hệ thống bên ngoài — một PLC, broker, hoặc ứng dụng điều khiển. Dùng Output Mapping để ánh xạ các kênh dự đoán tới một tag hoặc cột đích; bạn cũng có thể gửi trực tiếp một payload bằng một lần ghi thử theo yêu cầu.

Hai cách để ghi

Một đầu ra đã bật với ít nhất một Output Mapping sẽ tự động chuyển mọi dự đoán tới đích trong khi suy luận đang chạy (gửi rồi quên — một lần ghi thất bại được báo qua NotificationCenter chứ không được thử lại). Test Write là một cơ chế khác — một lần ghi đơn lẻ, theo yêu cầu mà bạn kích hoạt bằng tay để xác minh kết nối và địa chỉ.

Các đầu ra được hỗ trợ

Giao thức	Khả năng
OPC-UA	Ghi vào một node (đồng bộ)
MQTT	Publish tới một topic ở QoS 1, retain tắt theo mặc định
CSV	Thêm dòng vào một tệp xoay vòng — một cột cho mỗi tag đã ánh xạ, cộng với timestamp_utc

Cấu hình một đầu ra

1. Tạo đầu ra

   Vào Datasources → Output, bấm + Create, và chọn giao thức.

2. Điền cấu hình kết nối

   Mỗi giao thức có các trường riêng. Các trường bí mật bị che thành *** sau khi lưu.

   OPC-UA

   {
     "endpoint": "opc.tcp://your-plc-host:4840",
     "securityPolicy": "None",
     "authentication": "Anonymous"
   }

   MQTT

   {
     "broker": "mqtt://your-broker-host:1883",
     "port": 1883,
     "clientId": "plc-sink",
     "userName": "your-username",
     "password": "your-password"
   }

   Ở đây không có trường Base Topic hay QoS cho việc đăng ký — những trường đó mô tả những gì một đầu vào MQTT đăng ký, và biểu mẫu chỉ hiển thị các trường mà chiều này sử dụng. Topic mà một dự đoán publish tới đến từ tag Output Mapping của nó, không phải từ một trường kết nối. Publish dự đoán luôn dùng QoS 1 (xem bên dưới); một payload Test Write vẫn có thể đặt qos riêng (0–2, mặc định 0 — xem bên dưới).

   CSV

   {
     "outputDirectory": "/data/output",
     "baseFilename": "predictions",
     "rotationMaxSizeMb": 500
   }

   Ghi các tệp xoay vòng trong thư mục đã cấu hình — một cột cho mỗi tag đầu ra đã ánh xạ, cộng với một cột timestamp_utc.

3. Ánh xạ kênh đầu ra

   Mở Output Mapping trên hàng và ánh xạ ít nhất một kênh dự đoán tới một tag đích — một topic MQTT, một cột CSV, hoặc một địa chỉ node OPC-UA. Tag đã ánh xạ chính là địa chỉ gốc của sink, giữ nguyên: một tag MQTT là test sẽ publish tới topic test, không thêm tiền tố nào.

   Một đầu ra không ánh xạ gì thì không thể kích hoạt

   Việc kích hoạt sẽ thất bại với no_output_tags_mapped — một đầu ra không có kênh nào được ánh xạ sẽ chạy mà không chuyển đi bất kỳ dữ liệu nào, không lỗi, không ghi log, nên nó bị từ chối ngay từ đầu.

4. Lưu và bật

   Lưu đầu ra, rồi bật nó. Một đầu ra phải được bật trước khi nó chuyển dự đoán hoặc chấp nhận một lần ghi thử.

Publish MQTT: QoS 1 và thông lượng

Sink MQTT publish ở QoS 1, không phải QoS 0. Ở QoS 0, broker không xác nhận gì cả, nên một tin nhắn bị rớt — thường gặp nhất là một topic bị ACL từ chối — vẫn trả về một lần ghi thành công mà không có thông báo nào; QoS 1 nhận được một xác nhận thật (hoặc một mã lý do) từ broker.

Đánh đổi về thông lượng

Độ tin cậy phải trả giá bằng việc thông lượng publish giảm khoảng mười lần. Đo trên broker phòng lab: khoảng 3.000 msg/s cho mỗi sink qua TLS. Tải là SamplingHz × số tag đã ánh xạ — một datasource 10 Hz với vài tag sẽ không nhận ra khác biệt, nhưng một datasource tốc độ rất cao có thể yêu cầu nhiều hơn mức một sink có thể hấp thụ; kênh đầu ra áp dụng backpressure theo thiết kế, nên vòng lặp suy luận sẽ chậm lại theo tốc độ sink có thể tiêu thụ. Hãy đo ở tốc độ mục tiêu của bạn trước khi giả định có dư địa.

retain vẫn giữ false: một tin nhắn được retain sẽ phát lại cho mọi subscriber trong tương lai, nên một dashboard được mở sau nhiều giờ sẽ đọc một giá trị cũ như thể là giá trị hiện tại — đây là một lựa chọn có chủ đích theo từng lần triển khai, chứ không phải một giá trị mặc định có thể đoán được.

MQTT: kết nối lại, client id, và chẩn đoán Test Connection

Sink MQTT kết nối lại theo backoff sau khi broker ngắt kết nối — một kết nối chỉ để publish không có gì để đăng ký lại, nên việc khôi phục chỉ đơn giản là kết nối lại. Nếu không có cơ chế này, một sự cố tạm thời trước đây từng trở thành vĩnh viễn.

Một Client ID tường minh giờ đây có hậu tố theo vai trò (<id>-in cho một đầu vào, <id>-out cho một đầu ra) tại thời điểm kết nối. Điều này áp dụng cho mọi cấu hình đã lưu, kể cả một cấu hình vẫn còn lưu mặc định aiboard chia sẻ cũ — nên một đầu vào và đầu ra được xây từ cùng một cấu hình không còn trục xuất lẫn nhau khỏi broker nữa, và không cần chỉnh sửa cho cặp đó. Một id để trống vẫn tự sinh một id duy nhất.

Việc trục xuất (SessionTakenOver) vẫn xảy ra nếu bạn tường minh dùng lại một Client ID giữa hai datasource cùng vai trò (hai đầu vào, hoặc hai đầu ra), hoặc nếu một client MQTT bên ngoài kết nối với cùng id như một trong các datasource của bạn — trong trường hợp đó, hãy đặt mỗi bên một giá trị khác biệt, hoặc xóa trống trường.

Test Connection phân loại lỗi ở tầng socket thay vì hiển thị tên exception thô: lỗi không thể kết nối/bị từ chối/DNS được ánh xạ thành connect_failed, còn một lần kết nối bị hủy được ánh xạ thành timeout. Trong Docker, localhost là container backend, không phải máy của bạn — đây là nguyên nhân phổ biến nhất khiến một broker có thể kết nối được từ client trên desktop nhưng không kết nối được từ AIBOARD. Hãy dùng tên service của broker thay thế (ví dụ mqtt://mosquitto:1883 trong phòng lab).

Chế độ bảo mật

Các kết nối đầu ra dùng cùng các trường bảo mật và thang bậc như đầu vào — Insecure cho bàn thử, TLS kèm thông tin đăng nhập cho staging, và xác thực bằng chứng chỉ lẫn nhau cho sản xuất. Các chứng chỉ được đọc từ mount /certs. Xem Chế độ bảo mật: Insecure, TLS và Secure để biết các bảng trường theo từng giao thức; chúng áp dụng nguyên văn cho đầu ra.

Hai lưu ý riêng cho đầu ra:

• MQTT publish ở QoS 1 trên đường sản xuất để một broker làm rớt một tin nhắn (trường hợp kinh điển là một topic bị ACL từ chối) hiện ra thành lỗi thay vì một thành công âm thầm. Hãy cấp cho tài khoản của sink quyền publish đúng vào các topic đã ánh xạ.
• Đầu ra CSV chỉ ghi bên trong thư mục đầu ra đã cách ly; giới hạn xoay vòng khống chế dung lượng đĩa. Hãy bảo vệ volume, chứ không phải giao thức.

Gửi một lần ghi thử

Lệnh ghi thử được gửi qua API — POST /api/datasources/output/{id}/test-write, chỉ dành cho quản trị viên. Giao diện không còn nút Test Write. Mỗi sink xác thực khuôn dạng payload riêng: MQTT cần một topic, CSV cần columns/values, còn OPC-UA cần một mảng writes. Hãy dùng ví dụ tương ứng bên dưới.

OPC-UA

{
  "writes": [
    { "nodeId": "ns=2;s=Temperature", "value": 42.5 }
  ]
}

MQTT

{
  "topic": "devices/plc/setpoint",
  "setpoint": 65.0,
  "mode": "heating"
}

CSV

{
  "columns": ["setpoint", "mode"],
  "values": [65.0, "heating"]
}

Một lần ghi thành công trả về kết quả thành công; một lỗi giao thức trả về một thông báo như OPC UA: node not found hoặc MQTT: publish refused.

Nếu có gì đó sai

Triệu chứng	Nguyên nhân khả dĩ
connect_failed khi Test Connection	Broker/endpoint không thể truy cập được, bị từ chối, hoặc lỗi DNS — kiểm tra đường mạng, host, và cổng (MQTT 1883, OPC-UA 4840). Trong Docker, localhost nghĩa là container backend, không phải máy của bạn.
timeout khi Test Connection	Lần thử kết nối bị hủy trước khi hoàn tất — kiểm tra đường mạng và cổng.
Kích hoạt thất bại với no_output_tags_mapped	Hãy ánh xạ ít nhất một kênh đầu ra tới một tag trước, qua Output Mapping.
Lỗi datasource bị tắt	Bật đầu ra trước khi gửi một lần ghi thử.
Node not found (OPC-UA)	Kiểm tra định dạng NodeId và rằng node tồn tại trên máy chủ.
Admin only (403)	Lệnh ghi thử cần một tài khoản admin.
Hai đầu vào MQTT (hoặc hai đầu ra) liên tục ngắt kết nối lẫn nhau	Cả hai dùng chung một Client ID tường minh — hãy xóa trống một bên hoặc đặt giá trị khác nhau cho mỗi bên. Một đầu vào và đầu ra MQTT trên cùng một cấu hình không bị ảnh hưởng: mỗi bên tự động có hậu tố (-in/-out) tại thời điểm kết nối, kể cả trên một mặc định aiboard cũ.

Xem runbook Khắc phục sự cố để biết thêm.

Bước tiếp theo

Kết nối một đầu vào Truyền dữ liệu cảm biến vào để dẫn động suy luận.

Giám sát runtime Độ trễ, thông lượng và các KPI.