출력 데이터소스

🤖 이 번역은 기계 초벌 번역이며 사람 검수 대기 중입니다. 영어 페이지가 기준입니다.

출력 데이터소스는 데이터를 외부 시스템 — PLC, 브로커 또는 제어 애플리케이션 —으로 내보냅니다. Output Mapping을 사용해 예측 채널을 대상 태그나 컬럼에 매핑하세요. 온디맨드 테스트 쓰기로 페이로드를 직접 전송할 수도 있습니다.

두 가지 쓰기 방식

Output Mapping이 하나 이상 있는 활성화된 출력은 추론이 실행되는 동안 모든 예측값을 대상으로 자동 전달합니다(발사 후 망각 방식 — 쓰기 실패는 재시도되지 않고 NotificationCenter를 통해 보고됩니다). Test Write는 별개입니다 — 연결성과 주소 지정을 검증하기 위해 직접 트리거하는 온디맨드 개별 쓰기입니다.

지원되는 출력

프로토콜	기능
OPC-UA	노드에 쓰기 (동기)
MQTT	QoS 1로 토픽에 게시, 기본값은 retain 꺼짐
CSV	회전되는 파일에 행 추가 — 매핑된 태그당 한 컬럼, 그리고 timestamp_utc

출력 구성

1. 출력 생성

   Datasources → Output 으로 이동하여 + Create 를 클릭하고 프로토콜을 선택합니다.

2. 연결 구성 입력

   각 프로토콜에는 고유한 필드가 있습니다. 시크릿 필드는 저장 후 *** 로 마스킹됩니다.

   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"
   }

   여기에는 Base Topic이나 구독용 QoS 필드가 없습니다 — 이 필드들은 MQTT 입력이 구독하는 대상을 설명하는 것이며, 폼은 이 방향에서 사용하는 필드만 표시합니다. 예측값이 게시되는 토픽은 연결 필드가 아니라 Output Mapping 태그에서 정해집니다. 예측값 게시는 항상 QoS 1을 사용합니다(아래 참조); Test Write 페이로드는 여전히 자체 qos(0–2, 기본값 0 — 아래 참조)를 지정할 수 있습니다.

   CSV

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

   구성된 디렉터리 아래에 회전되는 파일을 씁니다 — 매핑된 출력 태그당 한 컬럼, 그리고 timestamp_utc 컬럼이 추가됩니다.

3. 출력 채널 매핑

   행에서 Output Mapping을 열고 예측 채널 하나 이상을 대상 태그 — MQTT 토픽, CSV 컬럼, 또는 OPC-UA 노드 주소 — 에 매핑하세요. 매핑된 태그는 싱크 고유 주소 그대로 사용됩니다: test라는 MQTT 태그는 접두사 없이 test 토픽에 그대로 게시됩니다.

   아무것도 매핑되지 않은 출력은 활성화할 수 없습니다

   활성화가 no_output_tags_mapped로 실패합니다 — 매핑된 채널이 없는 출력은 실행되어도 아무것도 전달하지 않으면서 오류나 로그 항목도 남기지 않으므로, 미리 거부됩니다.

4. 저장 및 활성화

   출력을 저장한 다음 활성화합니다. 출력은 예측값을 전달하거나 테스트 쓰기를 받기 전에 반드시 활성화되어 있어야 합니다.

MQTT 게시: QoS 1과 처리량

MQTT 싱크는 QoS 0이 아니라 QoS 1로 게시합니다. QoS 0에서는 브로커가 아무것도 확인하지 않으므로, 누락된 메시지(가장 흔하게는 ACL이 거부한 토픽)도 알림 없이 성공한 쓰기로 반환됩니다. QoS 1은 브로커로부터 실제 확인 응답(또는 사유 코드)을 받습니다.

처리량 트레이드오프

신뢰성을 확보하는 대가로 게시 처리량이 대략 10분의 1로 떨어집니다. 랩 브로커 기준 측정치는 TLS 상에서 싱크당 약 3,000 msg/s입니다. 부하는 SamplingHz × 매핑된 태그 수입니다 — 태그가 몇 개뿐인 10 Hz 데이터소스는 영향이 없지만, 매우 높은 속도의 데이터소스는 싱크가 감당할 수 있는 것보다 많은 양을 요구할 수 있습니다. 출력 채널은 설계상 백프레셔를 적용하므로 추론 루프는 싱크가 소화할 수 있는 속도로 느려집니다. 여유가 있다고 가정하기 전에 목표 속도에서 직접 측정하세요.

retain은 false로 유지됩니다: 유지된 메시지는 이후 모든 구독자에게 재생되므로, 몇 시간 뒤 열린 대시보드가 오래된 값을 현재 값으로 읽게 됩니다 — 추측 가능한 기본값이 아니라 배포마다 의도적으로 선택하는 값입니다.

MQTT: 재연결, 클라이언트 ID, Test Connection 진단

브로커가 연결을 끊으면 MQTT 싱크는 백오프로 재연결합니다 — 게시 전용 연결은 다시 구독할 것이 없으므로 복구는 재연결 자체로 끝납니다. 이 기능이 없었을 때는 일시적인 장애가 영구 장애가 되곤 했습니다.

명시적으로 지정한 Client ID는 이제 연결 시점에 역할 접미사가 붙습니다(입력은 <id>-in, 출력은 <id>-out). 이는 예전에 공유 기본값이던 aiboard를 그대로 저장하고 있는 구성을 포함해 저장된 모든 구성에 적용됩니다 — 따라서 동일한 구성으로 만들어진 입력과 출력은 더 이상 브로커에서 서로를 축출하지 않으며, 이 조합에는 편집이 필요 없습니다. id를 비워두면 여전히 고유 id를 자동 생성합니다.

축출(SessionTakenOver)은 다음과 같은 경우에 여전히 발생합니다: 하나의 Client ID를 동일한 역할의 데이터소스 두 개(입력 두 개, 또는 출력 두 개)에서 명시적으로 재사용하거나, 외부 MQTT 클라이언트가 여러분의 데이터소스 중 하나와 동일한 id로 연결하는 경우 — 이런 경우에는 각각에 서로 다른 값을 부여하거나 필드를 비워두세요.

Test Connection은 원시 예외 이름을 보여주는 대신 소켓 수준 실패를 분류합니다: 연결 불가/거부/DNS 실패는 connect_failed로, 취소된 연결 시도는 timeout으로 매핑됩니다. Docker에서는 localhost가 여러분의 머신이 아니라 백엔드 컨테이너를 가리킵니다 — 데스크톱 클라이언트에서는 연결되지만 AIBOARD에서는 연결되지 않는 브로커의 가장 흔한 원인입니다. 대신 브로커의 서비스 이름을 사용하세요(예: 랩에서는 mqtt://mosquitto:1883).

보안 모드

출력 연결은 입력과 동일한 보안 필드 및 단계를 사용합니다 — 벤치에는 Insecure, 스테이징에는 자격 증명을 갖춘 TLS, 프로덕션에는 상호 인증서 인증. 인증서는 /certs 마운트에서 읽습니다. 프로토콜별 필드 표는 보안 모드: Insecure, TLS, Secure를 참조하세요; 출력에도 그대로 적용됩니다.

출력에만 해당하는 두 가지 참고 사항:

• MQTT는 프로덕션 경로에서 QoS 1로 게시하므로, 브로커가 메시지를 드롭하는 경우(ACL이 거부한 토픽이 대표적인 사례) 조용한 성공이 아니라 실패로 드러납니다. 싱크 계정에 매핑된 토픽에 대해서만 정확히 게시 권한을 부여하세요.
• CSV 출력은 격리된 출력 디렉터리 안에만 기록하며, 회전 상한이 디스크 사용량을 제한합니다. 프로토콜이 아니라 볼륨을 보호하세요.

테스트 쓰기 전송

테스트 쓰기는 API로 전송합니다 — POST /api/datasources/output/{id}/test-write, 관리자 전용입니다. UI에는 Test Write 버튼이 없습니다. 각 싱크는 고유한 페이로드 형식을 검증합니다 — MQTT는 topic을, CSV는 columns/values를, OPC-UA는 writes 배열을 요구합니다. 아래의 해당 예시를 사용하세요.

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"]
}

쓰기에 성공하면 성공 결과가 반환되고, 프로토콜 오류 시 OPC UA: node not found 또는 MQTT: publish refused 같은 메시지가 반환됩니다.

문제가 발생하면

증상	가능한 원인
Test Connection에서 connect_failed	브로커/엔드포인트에 연결할 수 없거나, 거부되었거나, DNS 실패입니다 — 네트워크 경로, 호스트, 포트(MQTT 1883, OPC-UA 4840)를 확인하세요. Docker에서는 localhost가 여러분의 머신이 아니라 백엔드 컨테이너를 의미합니다.
Test Connection에서 timeout	연결 시도가 끝나기 전에 취소되었습니다 — 네트워크 경로와 포트를 확인하세요.
no_output_tags_mapped로 활성화 실패	먼저 Output Mapping을 통해 최소 하나의 출력 채널을 태그에 매핑하세요.
데이터소스 비활성화 오류	테스트 쓰기를 보내기 전에 출력을 활성화하세요.
Node not found (OPC-UA)	NodeId 형식과 해당 노드가 서버에 존재하는지 확인하세요.
Admin only (403)	테스트 쓰기에는 관리자 계정이 필요합니다.
MQTT 입력 두 개(또는 출력 두 개)가 계속 서로 연결을 끊음	둘이 동일한 명시적 Client ID를 공유하고 있습니다 — 하나를 비우거나 서로 다른 값을 지정하세요. MQTT 입력과 출력이 동일한 구성일 때는 영향이 없습니다: 연결 시점에 예전 aiboard 기본값을 포함해 각각 자동으로 접미사(-in/-out)가 붙습니다.

자세한 내용은 문제 해결 런북을 참조하세요.

다음 단계

입력 연결하기 센서 데이터를 스트리밍 수집하여 추론을 구동합니다.

런타임 모니터링 지연 시간, 처리량 및 KPI.