중요한 아키텍처 결정 사항 중 하나는 머신 로직이 실행되는 위치, 즉 헤드리스(클라우드/엣지) 방식인지 앱 기반(터미널) 방식인지입니다.
상호 절충점 매트릭스
아래 표는 다양한 로직 실행 방식을 설명합니다.
| 방법 | 헤드리스 | 비용 | 이상적인 사용 사례 | 제한 사항 |
|---|---|---|---|---|
| 시스템 트리거 | 예 | Tulip 기계 라이선스에 포함됨 | OEE 추적, 상태 관리, 간단한 부품 개수 집계 | 제한된 작업(상태 변경, 활동 필드만 가능), 표현식 편집기 없음, 커넥터 함수 호출 불가 |
| 자동화 | 예 | 작업별 가격 책정 | 복잡한 워크플로, 테이블 쓰기, 커넥터 함수, 외부 시스템 통합 | 사용량에 따라 비용이 달라지며, 완료 기록 없음 |
| 앱 트리거 | 아니요 | 포함 | 인간-기계 워크플로우, 풍부한 UI 상호작용, 표현식을 활용한 복잡한 논리 | 터미널에서 앱이 실행되어야 하며, 24시간 연중무휴 모니터링에는 적합하지 않음 |
| DataOps 플랫폼 (예: Litmus, High Byte) | 예 | DataOps 공급업체에 문의 | 고급 데이터 정규화, 시계열 데이터베이스, 다중 프로토콜 집계 | 관리해야 할 플랫폼이 추가되며, 총 비용 증가 및 통합 복잡성 증가 |
| 엣지 디바이스 + Node-RED | 예 | 일회성 하드웨어 비용 | 고도로 맞춤화된 로직, 고객 소유 인프라 | 신뢰성 낮음(페일오버/멀티스레딩 없음), 확장성 저하, 유지보수 부담 |
결정 기준
머신 트리거
다음과 같은 경우 기계 트리거를 사용하십시오:
- 기본적인 OEE 추적(상태, 부품 수, 불량)이 필요한 경우
- 논리가 단순한 조건부 확인인 경우(예: "속성이 10보다 크면 상태를 '실행 중'으로 설정")
- 비용 최적화가 중요한 경우 (Tulip에 포함됨)
자동화
다음과 같은 경우 자동화를 사용하십시오:
- 기계 데이터를 Tulip 테이블에 기록해야 할 때
- 커넥터 함수를 통해 외부 시스템과 연동해야 할 때
- 헤드리스 운영이 필수이며, 예산상 작업별 과금 방식이 가능한 경우
예시: "기계 5에서 불량 코드를 출력하면, Quality Issue 테이블에 레코드를 생성하고 Slack 알림을 전송합니다"
앱 트리거
다음과 같은 경우 앱 트리거를 사용하십시오:
- 워크플로우에 운영자가 직접 관여하는 경우
- 복잡한 계산을 위해 표현식 편집기가 필요한 경우
- 워크플로우에 UI 상호작용(버튼, 양식, 스캔)이 포함된 경우
예시: "운영자가 '실행 완료'를 누르면, 앱이 기계 데이터로부터 OEE를 계산하여 화면에 결과를 표시합니다"
DataOps 플랫폼
다음과 같은 경우 DataOps 플랫폼을 사용하십시오:
- 1초 미만의 데이터 해상도(<1 Hz)가 필요한 경우
- Tulip에서 지원하지 않는 프로토콜의 데이터를 집계해야 할 때
- 고급 분석을 위해 시계열 데이터베이스가 필요한 경우
- 고객이 해당 플랫폼에 이미 투자한 경우
엣지 디바이스
다음과 같은 경우 에지 디바이스 + Node-RED를 사용하십시오:
- 개념 검증(PoC) 또는 시범 프로젝트를 진행 중인 경우
- 고객사가 임베디드 시스템에 대한 전문 지식이 풍부한 경우
- 규제 요건으로 인해 클라우드 기반 로직 실행이 불가능한 경우
- 예산 제약으로 인해 구독형 소프트웨어 도입이 불가능한 경우
추가 자료
{{snippet.원하는 정보를 찾으셨나요?}}