머신 모니터링 앱 기반 아키텍처 패턴

Tulip은 머신을 중심으로 앱을 구성하는 방식에 있어 유연성을 제공합니다. 적합한 패턴은 팀의 기술적 성숙도, 프로세스 표준화 수준, 예산에 따라 달라집니다.

패턴 1: 조합형 기계 앱(1:1 모델)

구조: 기계 1대 → 앱 1개 → 스테이션 1개 → 단말기 1대

아키텍처 다이어그램:

사용 사례

• 첫 번째 머신 모니터링 앱을 개발하는초보 시민 개발자
• 효율성보다 단순성이 더 중요한신속한 개념 검증(PoC) 배포
• 기계 인스턴스별맞춤형 수작업 프로세스 (예: 기계 1에는 기계 2에는 적용되지 않는 고유한 점검 단계가 필요함)
• 개발자가 여러 역할을 맡고 시간이 제한적인운영 주도형 개발

이것이 중요한 이유

이 패턴은 소프트웨어를 하드웨어에 1:1로 물리적으로 매핑하여 추상화를 제거합니다. 개발자는 생산 현장의 특정 기계를 식별하여 해당 기계에 전용 앱을 매핑할 수 있습니다. 이러한 명확성은 인지적 부담을 줄여주고 문제 해결을 직관적으로 만들어 줍니다.

예시

시나리오: 한 식음료 제조업체에 3개의 포장 라인이 있습니다. 각 라인마다 고유한 가동 중단 원인, 부품 구성 및 작업자 워크플로가 있습니다.

구현

• 기계 유형 생성: "포장 라인"
• 기계 3대 생성: “라인 A”, “라인 B”, “라인 C”
• 앱 3개 구축: "라인 A 터미널", "라인 B 터미널", "라인 C 터미널"
• 각 앱을 고정된 터미널이 있는 전용 스테이션에 할당

장점

• 명확한 데이터 격리로 인해 기계 간 데이터 손상을 방지합니다
• 머신별 워크플로우를 쉽게 맞춤 설정할 수 있습니다
• 간편한 문제 해결 (문제는 항상 하나의 독립적인 앱 내에서 발생)

제한 사항

• 기기당 물리적 단말기 1대가 필요합니다(하드웨어 비용)
• 전역 앱 변경 시 3개의 별도 앱을 업데이트해야 함
• 약 10대의 기기를 초과하면 확장성이 떨어짐

패턴 2: 스테이션 앱에 대한 머신 할당

구조: 단일 기계 유형 → 단일 앱 → 여러 스테이션(스테이션 매핑을 통해 기계가 동적으로 할당됨)

아키텍처 다이어그램:

사용 사례

• 동일한 기계 유형 전반에 걸친표준화된 프로세스
• 추상화 및 트리거 로직에 익숙한상근 시민 개발자
• 수평 확장 필요 (동일 유형의 기계 10대 이상)
• 중앙집중식 앱 유지 관리가 최우선 과제

작동 방식

1. 'Shop Floor > Machines' (구성 탭)에서 각 기계를 스테이션에 할당합니다
2. 앱에서 “이 스테이션에서” 트리거 조건을 사용하여 할당된 기계를 동적으로 참조합니다
3. 앱이 스테이션 1에서 실행되면 기계 1과 연동되며, 스테이션 2에서 실행되면 기계 2와 연동됩니다

앱 트리거 예시

언제: 이 스테이션의 기계가 상태변경을 출력할때,만약: 기계 출력 / 상태 변경 =다운, 그렇다면: '상태 이력' 테이블에 테이블 레코드를 생성합니다.

예시

시나리오: 자동차 1차 공급업체에는 동일한 생산 공정을 수행하는 15대의 동일한 CNC 밀링 머신이 있습니다.

구현

• 기계 유형 생성: "CNC 밀링 머신 5축"
• 15대의 기계(CNC-001부터 CNC-015까지) 생성
• 앱 하나 구축: "CNC 운영자 터미널"
• 15개의 스테이션 생성, 각 스테이션에 기계 1대씩 할당
• 단일 앱을 15개 스테이션 모두에 배포

장점

• 유지 관리해야 할 앱이 하나뿐입니다(전사적 업데이트가 즉시 반영됨)
• 다수 장비 배포 시 앱 개발 시간 단축
• "이 워크스테이션에서" 트리거 로직 사용(내장된 동적 머신 참조)

제한 사항

• 여전히 스테이션당 터미널 1대가 필요함(하드웨어 비용 발생)
• 모든 머신은 동일한 유형이며 속성이 일치해야 함
• 기기별 맞춤형 로직에는 조건부 분기가 필요합니다(복잡성 증가)

패턴 3: 기계 변수 앱(유동 터미널)

구조: 단일 앱 → 여러 기기 유형 → 가변 기반 기기 선택 → 공유/유동 터미널

아키텍처 다이어그램:

사용 사례

• 예산 제약: 사용 가능한 단말기 수 제한
• 유동적 운영자 모델: 한 명의 운영자가 공유 iPad를 가지고 기기 간을 이동
• 기기에 대한 지속적인 모니터링이 필요 없음: 앱은 작업이 진행 중일 때만 실행되면 됨

중요한 제한 사항: 헤드리스 모드 미지원

이 패턴은 백그라운드/헤드리스 모니터링을 지원하지 않습니다. 앱이 닫혀 있으면 어떤 기계에서도 알림이 발생하지 않습니다. 이 패턴은 다음의 경우에만 적합합니다:

• 사람이 직접 데이터를 입력하는 경우(운영자가 결함 기록, 부품 수량 집계)
• 임시 기계 점검
• 앱이 실행 중이지 않을 때 기계가 데이터를 생성하지 않는 시나리오

작동 방식

1. 앱 내에 기계 변수를 생성합니다(예: selectedMachine)
2. 실행 시점에 selectedMachine 값을 채우기 위해 드롭다운 위젯 또는 QR 코드 스캔 기능 추가
3. 모든 트리거 참조에서 selectedMachine을 사용합니다

앱 트리거 예시

조건: 머신 변수 'Selected Machine'이 {Attribute}를 출력할때,다음 작업: 마지막 머신 출력값을 변수에 저장

예시

시나리오: 제약 연구소에는 예정된 테스트 중에만 작동하는 5대의 분석 기기가 있습니다. 기술자들은 공유 iPad를 사용하여 테스트 매개변수와 결과를 기록합니다.

구현

• 5대의 기기(HPLC-1, GC-MS-2 등) 생성
• 앱 하나 구축: "실험실 장비 기록"
• 드롭다운 메뉴 추가: “기기 선택” → selectedMachine 변수에 값을 할당
• 기술자는 아이패드를 들고 기기 사이를 이동하며, 작동 중인 기기를 선택하고 데이터를 기록합니다

장점

• 최소한의 하드웨어 비용(공유 단말기 1대)
• 실행 시 유연한 기기 선택
• 임시/간헐적인 워크플로우에 이상적

제한 사항

• 헤드리스 방식이 아님 - 로직을 실행하려면 앱이 활성화된 상태여야 함
• 앱이 종료된 상태에서는 백그라운드 모니터링이 불가능함
• 복잡한 상태 관리 (현재 어떤 머신이 활성화되어 있는가?)
• 24시간 연중무휴 OEE 추적에는 적합하지 않음

아키텍처 패턴 결정 트리

이 결정 트리를 사용하여 필요에 가장 적합한 패턴을 선택하세요:

추가 자료

• 기계 모니터링 - 헤드리스 아키텍처 대 앱 기반 아키텍처
• 변수

{{snippet.원하는 정보를 찾으셨나요?}}