Demo Stage 시연 가이드

고객 앞에서 Caffeine 플랫폼의 전체 데이터 파이프라인을 "제로에서 라이브"로 시연하는 가이드입니다. Admin 대시보드의 Demo Stage 페이지를 사용하여 장비 연결 → 데이터 수집 → 알람 → 시나리오 전환까지 단계별로 진행합니다.

📋 개요

Demo Stage는 고객 시연 전용 대시보드입니다. 실시간 SVG 아키텍처 맵으로 시스템 구성을 시각화하고, 8단계 가이드 패널로 시연자를 안내합니다.

왜 Demo Stage인가?

기존 방식	Demo Stage
노트북 1대에서 미리 준비된 데모	PC 3대로 고객 앞에서 실시간 구성
"미리 맞춰온 것 아닌가?" 의심	제로에서 라이브 데이터까지 투명하게
정적 스크린샷	SVG 노드가 실시간으로 활성화

아키텍처

구성 요소	역할	포트
Caffeine Engine	데이터 수집·처리 코어	HTTP `:5001`, gRPC `:5050`
DemoHub	ICaffeineEventBus → SignalR 실시간 브릿지	`/hubs/demo`
Admin (Demo Stage)	시연용 대시보드 UI	Docker: `:8080`, 소스 실행: `:5233`
Simulator	MQTT 센서 데이터 생성 (Docker)	MQTT `:1883`

📋 사전 요구사항

항목	확인 방법	비고
Docker	`docker --version`	모든 PC 필수
Caffeine CLI	`cafe --version`	`dotnet tool install -g NEXCODE.Caffeine.Cli`
네트워크	`ping` 상호 확인	Host↔Edge 같은 서브넷 (mDNS 검색용)
.NET 10 SDK	`dotnet --version`	조합 2(소스 기반)만 필요

🚀 데모 구성 조합

데모 환경은 3가지 조합 중 상황에 맞게 선택합니다. 비교표에서 적합한 조합을 클릭하세요.

	조합 1: Docker 배포	조합 2: 단일 PC	조합 3: Edge Runtime
용도	고객 시연 (권장)	빠른 확인/온라인 미팅	운영 신뢰성 시연
PC 수	2~3대	1대	2대
Host PC	`cafe setup` → Server	`cafe setup` → Server	`cafe setup` → Server
Edge PC	`cafe setup` → Edge Docker	— (내장)	`cafe edge install`
시뮬레이터	`cafe demo simulator`	— (내장)	`cafe demo simulator`
mDNS 검색	❌ (Docker bridge 격리)	—	✅ mDNS + 자동 재연결
자동 복구	Docker restart	Docker restart	systemd + heartbeat
인터넷 필요	❌ (오프라인 팩)	❌ (오프라인 팩)	❌ (오프라인 팩)
시연 임팩트	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐

권장 조합

첫 데모 / 빠른 셋업 → 조합 1 (Docker 배포) (mDNS 불가, Engine URL 수동 설정)
운영 안정성 시연 / 현장 PoC → 조합 3 (Edge Runtime) (mDNS 자동 검색)
완전 Zero-Config → 조합 4 (전체 네이티브) (양방향 mDNS)

조합 1: Docker 배포 — 고객 시연 (권장)

오프라인 팩으로 준비하면 인터넷 없이도 시연 가능. **"제로에서 라이브"**를 보여주는 최적 구성.

실행 순서

1단계: Host PC — 중앙 서버 기동

# 오프라인 팩 설치 (최초 1회)
cafe setup --source caffeine-pack-3.2.0.tar.gz
# 프로파일 선택: "Server (중앙 서버 배포)"

Engine 준비 확인:

docker logs caffeine-engine
# 🌐 [Kestrel] Configuring Port 5001 (HTTP/1, IPv4)
# 🌐 [Kestrel] Configuring Port 5050 (HTTP/2 ONLY - gRPC/h2c)

Admin 대시보드 접속: http://<Host-IP>:8080 (Docker 배포 시)

2단계: Edge PC — 엣지 게이트웨이 기동

# 오프라인 팩 설치 (최초 1회)
cafe setup --source caffeine-pack-3.2.0.tar.gz
# 프로파일 선택: "Edge (엣지 게이트웨이)"

.env 설정 (설치 전 또는 후에 편집):

# Edge PC의 .env
Engine__Url=http://<Host-PC-IP>:5050    # 중앙 Engine gRPC 주소 (포트 5050)
Driver__Id=Edge-01                      # 엣지 디바이스 식별자

Docker bridge 환경에서는 mDNS 불가

조합 1은 Docker bridge 네트워크를 사용하므로 mDNS 자동 검색이 불가능합니다. 반드시 Engine__Url을 수동으로 설정해야 합니다. mDNS 자동 검색이 필요하면 조합 3 또는 조합 4를 사용하세요.

Case 2(공장 엔지니어) 시나리오에서는 Edge PC 2대를 EDGE_DEVICE_ID=Edge-02로 추가 기동합니다.

3단계: Host PC Admin에서 Bridge 검색

Admin → 드라이버 및 통신 → Bridge Discovery → 스캔 클릭

Bridge.Host가 mDNS/DNS-SD로 자신을 광고하므로, 같은 서브넷의 Edge가 자동 발견됩니다. "스캔" 버튼 한 번이면 시연 하이라이트!

정리

# Host PC
cafe setup down

# Edge PC
cafe setup down

# 완전 초기화 (필요 시)
cafe setup clean --all

조합 2: 단일 PC — 빠른 데모/내부 확인

노트북 1대에서 전체 환경을 Docker로 기동. 빠른 확인이나 온라인 미팅용.

# 한 줄로 전체 기동
cafe setup
# 프로파일 선택: "Server (중앙 서버 배포)"

Server 프로파일은 Engine + Admin + Bridge + Simulator + 인프라 전체를 포함하므로 추가 작업이 필요 없습니다.

Admin 접속: http://localhost:8080

조합 3: Edge Runtime — 현장 배포 시뮬레이션

실제 현장 배포와 동일한 구성으로 시연합니다. Bridge.Host를 systemd 서비스로 설치하고, mDNS 자동 검색 + 자동 복구를 시연하는 고급 데모입니다.

실행 순서

1단계: Host PC — 중앙 서버 기동 (조합 1과 동일)

cafe setup --source caffeine-pack-3.2.0.tar.gz
# 프로파일: "Server (중앙 서버 배포)"

2단계: Edge PC — cafe edge install로 서비스 설치

# 팩 전송 후 설치 (한 줄로 완료)
cafe edge install --source caffeine-pack-3.2.0.tar.gz

대화형 설정에서:

Driver ID: Edge-01 (기본값)
Engine URL: 비워두면 → mDNS 자동 검색 (Engine이 같은 서브넷 + 네이티브 실행 시에만 동작)
Driver Type: Simulation (기본값)

Host PC의 Engine이 Docker로 실행되는 경우

조합 3에서 Host PC의 Engine이 cafe setup(Docker)으로 실행되면, Engine의 mDNS 광고가 불가능합니다. 이 경우 Bridge의 Engine URL을 수동으로 설정해야 합니다: Engine__Url=http://<Host-PC-IP>:5050 Engine도 네이티브로 실행하려면 조합 4를 사용하세요.

설치 완료 후 자동으로:

MQTT + Redis Docker 컨테이너 시작 (restart: always)
Bridge.Host systemd 서비스 시작 (Restart=always)
mDNS 광고 시작 (_caffeine-bridge._tcp, avahi-publish 사용)

3단계: 시뮬레이터 실행

cafe demo simulator

4단계: Host PC Admin에서 Bridge 검색

Admin → 드라이버 및 통신 → Bridge Discovery → 스캔 클릭

복원력 시연 시나리오

이 구성의 핵심 차별점은 자동 복구 시연입니다. 고객 앞에서 장애를 일으키고, 자동으로 복구되는 것을 보여줄 수 있습니다.

시나리오 A: Bridge 크래시 복구

# Edge PC에서 Bridge.Host 프로세스를 강제 종료
sudo systemctl kill -s SIGKILL caffeine-bridge

# 5초 후 자동 재시작 확인
cafe edge status
# → ● 실행 중 (PID: 새로운 PID)

고객에게: "프로세스가 죽어도 5초 내에 자동으로 되살아납니다."

시나리오 B: Engine 재시작 자동 재연결

# Host PC에서 Engine 컨테이너 재시작
docker restart caffeine-engine

# Edge PC의 Bridge.Host가 heartbeat 실패 → mDNS 재스캔 → 자동 재연결
# Edge PC 로그 확인
cafe edge logs -f
# → [EngineDiscovery] Engine heartbeat 실패 (1/3)
# → [EngineDiscovery] Engine heartbeat 실패 (2/3)
# → [EngineDiscovery] Engine heartbeat 실패 (3/3)
# → [EngineDiscovery] Engine 연결 끊김 감지 — mDNS 재스캔 시작
# → [EngineDiscovery] ✅ Engine 재발견: Engine-01 @ http://192.168.1.100:5000

고객에게: "Engine이 재시작되어도 엣지가 자동으로 다시 찾아서 연결합니다. 관리자 개입이 필요 없습니다."

시나리오 C: 서비스 상태 모니터링

# Edge 상태 확인
cafe edge status

# Health endpoint 직접 조회
curl http://edge-pc:5100/health

고객에게: "원격에서 엣지 상태를 실시간으로 확인할 수 있습니다."

정리

# Edge PC
cafe edge uninstall

# Host PC
cafe setup down

조합 3 vs 조합 1 비교

	조합 1: Docker 배포	조합 3: Edge Runtime
Bridge 관리	Docker `restart: always`	systemd `Restart=always`
mDNS	❌ (Docker 격리)	✅ (네이티브 네트워크)
Engine 연결	`Engine__Url` 수동 설정	mDNS 자동 검색 + 자동 재연결
크래시 복구	Docker 자동 재시작	systemd 5초 복구
헬스 모니터링	—	`/health` (포트 5100) + heartbeat
시연 포인트	Zero-Config Discovery	자동 복구 + 운영 신뢰성
적합 대상	첫 데모, 빠른 셋업	현장 운영 데모, 신뢰성 시연

언제 조합 3를 사용하나?

고객이 "현장에서 장비가 죽으면 어떻게 되나?"라고 질문할 때
운영 안정성이 핵심 관심사인 공장장/설비 담당자 대상 시연
PoC 이후 실제 배포 계획을 논의하는 미팅

조합 4: 전체 네이티브 — 양쪽 모두 systemd

Engine과 Bridge 모두 systemd 서비스로 배포하여 완전한 mDNS Zero-Config를 실현합니다.

# Host PC (Linux)
cafe engine install --source caffeine-pack-3.2.0.tar.gz

# Edge PC (Linux)
cafe edge install --source caffeine-pack-3.2.0.tar.gz
# Engine URL은 비워두면 → mDNS 자동 검색

	조합 3	조합 4
Host PC	`cafe setup` (Docker)	`cafe engine install` (systemd)
Edge PC	`cafe edge install` (systemd)	`cafe edge install` (systemd)
Engine mDNS 광고	❌ (Docker bridge 격리)	✅ (네이티브 네트워크)
Bridge mDNS 광고	✅	✅
Bridge → Engine 검색	Engine URL 수동 설정	mDNS 자동 검색
Admin Bridge Discovery	✅ (dns-sd fallback)	✅

📡 mDNS 네트워크 검색 상세

mDNS란?

mDNS(Multicast DNS)는 같은 서브넷(LAN) 내에서 서비스를 자동으로 발견하는 Zero-Configuration 프로토콜입니다. DNS 서버 없이 _caffeine-bridge._tcp, _caffeine-engine._tcp 서비스 타입으로 상호 검색합니다.

mDNS 동작 조건

조건	필수 여부	설명
같은 서브넷 (LAN)	필수	mDNS는 멀티캐스트 UDP (224.0.0.251:5353). 라우터를 넘지 못함
네이티브 네트워크	필수	Docker bridge/overlay 네트워크에서는 불가
avahi-daemon (Linux)	필수	mDNS 광고에 avahi-publish-service 사용
avahi-utils (Linux)	권장	디버깅용 avahi-browse. `cafe edge install` 시 자동 설치
방화벽 개방	필수	UDP 5353 포트 (mDNS 멀티캐스트)

배포 방식별 mDNS 지원

배포 방식	Engine mDNS 광고	Bridge mDNS 광고	Bridge → Engine 자동 검색	Admin Bridge Discovery
Engine: Docker bridge	❌	—	❌	❌ (Zeroconf 제한)
Engine: Docker `--network host`	✅	—	✅	✅
Engine: `cafe engine install` (systemd)	✅	—	✅	✅
Engine: `dotnet run` (소스 실행)	✅	—	✅	✅
—	—	—	—	—
Bridge: Docker bridge	—	❌	—	❌
Bridge: `cafe edge install` (systemd)	—	✅ (avahi-publish)	—	✅
Bridge: `dotnet run` (소스 실행, macOS)	—	✅ (Bonjour)	—	✅

Docker bridge 네트워크와 mDNS

Docker의 기본 bridge 네트워크는 컨테이너를 격리된 가상 네트워크에 배치합니다. mDNS 멀티캐스트 패킷이 호스트 네트워크로 전달되지 않으므로, Docker bridge 안에서 실행되는 서비스는 mDNS 광고/검색이 불가능합니다.

해결 방법:

systemd 네이티브 배포 (cafe engine install, cafe edge install) — 권장
--network host — Docker를 쓰되 호스트 네트워크 공유 (포트 충돌 주의)
macvlan 네트워크 — 컨테이너에 별도 MAC/IP 할당 (고급 설정)

mDNS 없이 수동 연결 설정

mDNS를 사용할 수 없는 환경(서로 다른 서브넷, VPN, WAN, Docker bridge)에서는 IP 주소를 직접 지정합니다.

Bridge → Engine 연결 (수동)

# 방법 1: cafe edge install 시 대화형 설정
cafe edge install --source caffeine-pack-3.2.0.tar.gz
# "Engine URL" 입력: http://<Engine-IP>:5050

# 방법 2: .env 파일 직접 편집
sudo vi /opt/caffeine/bridge-host/.env
# Engine__Url=http://192.168.1.100:5050

# 방법 3: driver_settings.json 편집
sudo vi /opt/caffeine/bridge-host/driver_settings.json
# "Engine": { "Url": "http://192.168.1.100:5050" }

# 변경 후 서비스 재시작
sudo systemctl restart caffeine-bridge

Engine URL 설정 우선순위

우선순위	소스	예시
1 (최우선)	mDNS 자동 검색	`_caffeine-engine._tcp` 서비스 발견
2	환경변수 `Engine__Url`	`.env` 파일 또는 systemd EnvironmentFile
3	`driver_settings.json`	`"Engine": { "Url": "http://..." }`
4 (기본값)	코드 하드코딩	`http://localhost:5001`

mDNS가 성공하면 환경변수/설정 파일의 URL보다 우선합니다. mDNS 검색이 실패하면 자동으로 설정값으로 fallback합니다.

포트 번호 안내

포트	프로토콜	용도	서비스
5001	HTTP/1.1	REST API, Provisioning	Engine
5050	HTTP/2 (h2c)	gRPC 데이터 스트림	Engine
5100	HTTP/1.1	Bridge Config UI, Health	Bridge.Host
1883	TCP	MQTT 브로커	Mosquitto
6379	TCP	Redis 캐시	Redis
8086	HTTP	InfluxDB 시계열 DB	InfluxDB

Bridge → Engine 연결 시 포트 주의

gRPC Transport (데이터 전송): 5050 포트 사용
Provisioning (등록/heartbeat): 5001 포트 사용
.env의 Engine__Url은 gRPC 포트(5050)를 지정합니다
Provisioning URL은 Provisioning__EngineUrl로 별도 지정 (기본: 5001)

mDNS 디버깅

# macOS에서 mDNS 서비스 검색
dns-sd -B _caffeine-bridge._tcp .
dns-sd -B _caffeine-engine._tcp .

# Linux에서 mDNS 서비스 검색
avahi-browse -t -r _caffeine-bridge._tcp
avahi-browse -t -r _caffeine-engine._tcp

# avahi-daemon 상태 확인 (Linux)
systemctl status avahi-daemon

# 방화벽에서 mDNS 허용 (Linux)
sudo ufw allow 5353/udp

# Bridge.Host mDNS 광고 상태 확인
cafe edge logs | grep -i "mdns\|avahi\|advertis"

# Engine mDNS 광고 상태 확인
cafe engine logs | grep -i "mdns\|avahi\|advertis"

🔧 cafe demo simulator 옵션

옵션	기본값	설명
`--host`	`mqtt-broker`	MQTT 호스트 (Docker 네트워크에서 서비스명 자동 사용)
`--device-id`	`Edge-01`	장치 ID prefix
`--device-count`	`5`	시뮬레이션 장치 수
`--scenario`	`Normal`	초기 시나리오 (`Normal`, `Overheat`, `PressureDrop`, `RandomSpike`)
`--image`	`nexcode/caffeine-simulator:latest`	시뮬레이터 Docker 이미지
`--detach`	`false`	백그라운드 실행

🏗️ 시나리오 선택

Demo Stage에 처음 진입하면 시나리오 선택 오버레이가 표시됩니다. 고객 유형에 맞는 시나리오를 선택하세요.

Case 1: 설비 업체 (NexMind)

대상: 설비를 만들어 납품하는 업체 (OEM)

AAS (IEC 63278) 디지털 트윈 자동 생성
원격 장비 모니터링 + 예지정비
Edge PC 1대 연결로 진행

핵심 메시지	설명
"장비에 Caffeine 탑재 → AAS 표준 자동 준수"	개발 비용 절감
"납품 후 원격 모니터링"	유지보수 수익 모델

Case 2: 공장 엔지니어

대상: 다양한 벤더 장비를 운영하는 공장

비표준 장비 데이터 통합 수집
실시간 알람 + AI 이상 감지
Edge PC 2대 연결로 이기종 장비 통합 시연

핵심 메시지	설명
"장비 제조사와 무관하게 데이터 통합"	벤더 락인 해소
"실시간 알람으로 즉각 대응"	다운타임 최소화

🎯 8단계 시연 흐름

시나리오 선택 후 Demo Stage가 8단계 가이드를 표시합니다. 각 단계는 자동 감지 + 수동 진행 방식입니다.

Step	제목	자동 감지 조건	타임아웃
1	Host 환경 확인	—	—
2	Edge 시뮬레이터 연결	Bridge 감지 (Case1: ≥1, Case2: ≥2)	15초
3	Admin 대시보드 확인	—	—
4	장비 등록 확인	EquipmentCount ≥ 1	15초
5	데이터 수집 확인	IngestionCount > 0	15초
6	알람 확인	AlarmCount ≥ 1	15초
7	시나리오 전환	—	—
8	마무리	—	—

자동 감지와 수동 진행

조건이 충족되면 "다음" 버튼이 초록색으로 하이라이트됩니다
15초 내 자동 감지가 안 되면 수동으로 "다음" 버튼을 눌러 진행할 수 있습니다
"다음" 버튼은 항상 표시되어 데모가 멈추지 않습니다

Step 7 상세: 시나리오 전환

이 단계에서 시뮬레이터의 데이터 패턴을 런타임으로 변경합니다. 시뮬레이터를 재시작할 필요 없이 버튼 클릭만으로 전환됩니다.

Admin UI 버튼 → Engine API (POST /api/v1/demo/scenario)
  → MQTT "caffeine/demo/command" 토픽 발행
    → Simulator가 구독하여 즉시 반영

🌐 AAS 디지털 트윈 시연

데모 시연에서 AAS(Asset Administration Shell) 디지털 트윈을 생성하고 확인하는 흐름입니다.

Bridge AAS 설정 (현장 엔지니어 역할)

Bridge Config UI(Edge:5100)에 접속하여 AAS 탭에서 설비 정보를 입력합니다.

AAS 탭 선택
Nameplate 입력 (제조사명, 제품명, 시리얼번호, 제조년도, 원산지)
서브모델 선택 (Nameplate, OperationalData, TechnicalData 기본 체크)
시맨틱 매핑 확인 (Temperature, Pressure 등 자동 매핑됨)
저장 클릭

Bridge Config UI → AAS 탭:
  Nameplate: 제조사 정보 입력 폼
  서브모델: 체크박스로 선택
  시맨틱 매핑: 태그별 ECLASS IRDI 자동/수동 설정

Admin에서 디지털 트윈 생성 (운영자 역할)

Admin 대시보드(Admin:5003)에서 설비 구성 위저드를 실행합니다.

설비 구성 메뉴 → 위저드 시작
Step 1: Bridge 선택 (자동 검색된 Bridge 클릭)
Step 2: 태그 확인 (Bridge에서 자동 조회된 3개 태그 표시)
Step 3: AAS 매핑 확인 (Bridge에서 Pull한 Nameplate/서브모델/시맨틱 매핑이 자동 채움)
Step 4: "디지털 트윈 생성" 클릭

Plug & Twin

Bridge에서 설정한 AAS 정보가 Admin 위저드에 자동으로 반영됩니다. 현장 엔지니어가 입력 → 사무실 운영자가 확인 → 트윈 완성. 이중 작업 없이 한 번의 흐름으로 디지털 트윈이 생성됩니다.

AAS 대시보드 확인

Admin의 AAS 관리 페이지(/aas)에서 생성된 디지털 트윈을 확인합니다.

카드 클릭 → 상세 모달에서 서브모델 내용 확인:
- OperationalData: AliveBit, Temperature, Pressure 태그 엘리먼트
- Nameplate: ManufacturerName, SerialNumber, YearOfConstruction
- TechnicalData: 태그 기반 사양 데이터

Bridge AAS Config REST API

Bridge Host는 AAS 설정을 위한 REST API를 제공합니다.

메서드	경로	설명	권한
GET	`/api/bridge/config/aas`	AAS 설정 조회	viewer
GET	`/api/bridge/config/aas/export`	AAS 설정 조회 (인증 불필요)	공개
PUT	`/api/bridge/config/aas`	AAS 설정 저장	admin

export 엔드포인트: Admin 위저드가 Bridge에서 AAS 설정을 Pull할 때 사용합니다. 인증 없이 접근 가능하므로, 자동화 스크립트에서도 활용할 수 있습니다.

응답 예시 (GET):

{
  "nameplate": {
    "manufacturerName": "Hyundai Robotics",
    "productDesignation": "HA006B",
    "serialNumber": "HR-2024-00142",
    "yearOfConstruction": "2024",
    "countryOfOrigin": "KR"
  },
  "selectedSubmodels": ["Nameplate", "OperationalData", "TechnicalData"],
  "semanticMappings": {
    "Temperature": "0173-1#02-AAI835#001",
    "Pressure": "0173-1#02-AAE912#007"
  },
  "lastModified": "2026-03-29T06:47:38Z"
}

AAS 서브모델 REST API

Admin/Engine의 AAS REST API에서 서브모델 내용을 조회합니다.

메서드	경로	설명
GET	`/api/aas/shells/{shellId}/submodels`	모든 서브모델 조회
GET	`/api/aas/shells/{shellId}/submodels/{type}`	특정 타입 서브모델 조회

서브모델은 ISubmodelProvider가 EquipmentManifest 기반으로 동적 생성합니다.

🎭 텔레메트리 시나리오

시뮬레이터는 4가지 데이터 패턴을 지원합니다. Demo Stage의 Step 7에서 런타임 전환할 수 있습니다.

Normal (정상)

안정적인 정상 범위 데이터를 생성합니다.

센서	범위	특성
온도	20 ~ 30 °C	균일 분포
압력	1000 ~ 1020 hPa	균일 분포

시연 포인트: "정상 상태에서 안정적인 데이터 수집과 대시보드 표시를 확인하세요."

Overheat (과열)

온도가 위험 수준으로 지속적으로 높은 데이터를 생성합니다.

센서	범위	특성
온도	80 ~ 120 °C	위험 수준
압력	1000 ~ 1020 hPa	정상 유지

시연 포인트: "온도가 임계값을 초과하면 자동으로 Critical 알람이 발생합니다. 알람 페이지에서 실시간 확인하세요."

PressureDrop (압력 급락)

압력이 정상 범위 아래로 떨어지는 데이터를 생성합니다.

센서	범위	특성
온도	20 ~ 30 °C	정상 유지
압력	600 ~ 800 hPa	저압 이상

시연 포인트: "압력 이상은 AI 이상 감지 모듈이 패턴을 학습하여 예측 알람을 발생시킵니다."

RandomSpike (간헐적 스파이크)

15% 확률로 비정상 데이터가 발생하는 현실적인 패턴입니다.

상태	온도	압력	확률
정상	20 ~ 30 °C	1000 ~ 1020 hPa	85%
스파이크	60 ~ 110 °C	600 ~ 700 hPa	15%

시연 포인트: "실제 현장처럼 간헐적 이상이 발생합니다. Caffeine이 노이즈와 실제 이상을 어떻게 구분하는지 확인하세요."

시나리오 전환

CLI로 전환 (권장)

# 직접 지정
cafe demo scenario Overheat

# 대화형 선택 (인자 생략 시)
cafe demo scenario

REST API로 전환

POST /api/v1/demo/scenario
Content-Type: application/json

{
  "scenario": "Overheat"
}

응답 코드	의미
`200 OK`	시나리오 전환 성공
`400 Bad Request`	유효하지 않은 시나리오명
`503 Service Unavailable`	MQTT 브로커 연결 실패

유효한 시나리오: Normal, Overheat, PressureDrop, RandomSpike

🔧 데모 리셋

시연을 반복하려면 Demo Stage 상단의 리셋 버튼을 클릭합니다:

모든 SVG 노드 → 비활성(회색) 상태
카운터(장비/알람/수집) → 0
현재 단계 → 0 (시나리오 선택 화면)
시나리오 → Normal

📊 실시간 데이터 흐름

Demo Stage는 SignalR을 통해 실시간 이벤트를 수신합니다:

SignalR 이벤트	트리거	UI 반영
`OnAlarmRaised`	알람 발생 시	알람 카운터 증가 + SVG 노드 강조
`OnIngestionStats`	데이터 수집 시 (1초 버퍼)	수집 카운터 업데이트
`OnEquipmentRegistered`	장비 등록 시	장비 카운터 증가 + SVG 노드 활성화

SignalR 자동 재연결

네트워크가 일시적으로 끊어져도 자동 재연결됩니다 (재시도 간격: 즉시 → 2초 → 5초). 연결이 끊긴 동안 SVG 노드가 회색으로 표시됩니다.

🔒 장애 대응

상황	증상	해결
MQTT 브로커 다운	시나리오 전환 실패 토스트	`cafe demo down && cafe demo up`
SignalR 연결 끊김	노드가 회색으로 전환	자동 재연결 대기 (최대 5초)
Edge PC 미감지	Step 2에서 Bridge 카운트 0	네트워크 서브넷 확인, `ping` 테스트
15초 타임아웃	"다음" 버튼 하이라이트	수동으로 다음 단계 진행
상태 확인	컨테이너 실행 여부 불확실	`cafe demo status`

🛠️ 고급: 수동 Docker 실행

Caffeine CLI를 사용할 수 없는 환경에서는 Docker 명령어를 직접 실행할 수 있습니다.

인프라 시작

docker run -d --name caffeine-demo-mqtt -p 1883:1883 eclipse-mosquitto:2
docker run -d --name caffeine-demo-redis -p 6379:6379 redis:7-alpine

시뮬레이터 실행

# Edge PC 1
docker run --rm \
  -e MQTT_HOST=<Host-PC-IP> \
  -e DEVICE_ID=Edge-01 \
  -e DEVICE_COUNT=5 \
  -e SCENARIO=Normal \
  -e TARGET_RPS=10 \
  -e BATCH_SIZE=5 \
  nexcode/caffeine-simulator:latest

# Edge PC 2 (Case 2 시나리오 시)
docker run --rm \
  -e MQTT_HOST=<Host-PC-IP> \
  -e DEVICE_ID=Edge-02 \
  -e DEVICE_COUNT=5 \
  -e SCENARIO=Normal \
  -e TARGET_RPS=10 \
  -e BATCH_SIZE=5 \
  nexcode/caffeine-simulator:latest

정리

docker stop caffeine-demo-mqtt caffeine-demo-redis
docker rm caffeine-demo-mqtt caffeine-demo-redis

📚 다음 단계

시뮬레이션 환경 구성 가이드 — 시뮬레이터 상세 설정
벤치마크 테스트 가이드 — 성능 측정
엣지 연동 가이드 — 실제 장비 연동

📋 개요​

왜 Demo Stage인가?​

아키텍처​

📋 사전 요구사항​

🚀 데모 구성 조합​

조합 1: Docker 배포 — 고객 시연 (권장)​

실행 순서​

정리​

조합 2: 단일 PC — 빠른 데모/내부 확인​

조합 3: Edge Runtime — 현장 배포 시뮬레이션​

실행 순서​

복원력 시연 시나리오​

시나리오 A: Bridge 크래시 복구​

시나리오 B: Engine 재시작 자동 재연결​

시나리오 C: 서비스 상태 모니터링​

정리​

조합 3 vs 조합 1 비교​

조합 4: 전체 네이티브 — 양쪽 모두 systemd​

📡 mDNS 네트워크 검색 상세​

mDNS란?​

mDNS 동작 조건​

배포 방식별 mDNS 지원​

mDNS 없이 수동 연결 설정​

Bridge → Engine 연결 (수동)​

Engine URL 설정 우선순위​

포트 번호 안내​

mDNS 디버깅​

🔧 cafe demo simulator 옵션​

🏗️ 시나리오 선택​

Case 1: 설비 업체 (NexMind)​

Case 2: 공장 엔지니어​

🎯 8단계 시연 흐름​

Step 7 상세: 시나리오 전환​

🌐 AAS 디지털 트윈 시연​

Bridge AAS 설정 (현장 엔지니어 역할)​

Admin에서 디지털 트윈 생성 (운영자 역할)​

AAS 대시보드 확인​

Bridge AAS Config REST API​

AAS 서브모델 REST API​

🎭 텔레메트리 시나리오​

Normal (정상)​

Overheat (과열)​

PressureDrop (압력 급락)​

RandomSpike (간헐적 스파이크)​

시나리오 전환​

CLI로 전환 (권장)​

REST API로 전환​

🔧 데모 리셋​

📊 실시간 데이터 흐름​

🔒 장애 대응​

🛠️ 고급: 수동 Docker 실행​

인프라 시작​

시뮬레이터 실행​

정리​

📚 다음 단계​

📋 개요

왜 Demo Stage인가?

아키텍처

📋 사전 요구사항

🚀 데모 구성 조합

조합 1: Docker 배포 — 고객 시연 (권장)

실행 순서

정리

조합 2: 단일 PC — 빠른 데모/내부 확인

조합 3: Edge Runtime — 현장 배포 시뮬레이션

실행 순서

복원력 시연 시나리오

시나리오 A: Bridge 크래시 복구

시나리오 B: Engine 재시작 자동 재연결

시나리오 C: 서비스 상태 모니터링

정리

조합 3 vs 조합 1 비교

조합 4: 전체 네이티브 — 양쪽 모두 systemd

📡 mDNS 네트워크 검색 상세

mDNS란?

mDNS 동작 조건

배포 방식별 mDNS 지원

mDNS 없이 수동 연결 설정

Bridge → Engine 연결 (수동)

Engine URL 설정 우선순위

포트 번호 안내

mDNS 디버깅

🔧 cafe demo simulator 옵션

🏗️ 시나리오 선택

Case 1: 설비 업체 (NexMind)

Case 2: 공장 엔지니어

🎯 8단계 시연 흐름

Step 7 상세: 시나리오 전환

🌐 AAS 디지털 트윈 시연

Bridge AAS 설정 (현장 엔지니어 역할)

Admin에서 디지털 트윈 생성 (운영자 역할)

AAS 대시보드 확인

Bridge AAS Config REST API

AAS 서브모델 REST API

🎭 텔레메트리 시나리오

Normal (정상)

Overheat (과열)

PressureDrop (압력 급락)

RandomSpike (간헐적 스파이크)

시나리오 전환

CLI로 전환 (권장)

REST API로 전환

🔧 데모 리셋

📊 실시간 데이터 흐름

🔒 장애 대응

🛠️ 고급: 수동 Docker 실행

인프라 시작

시뮬레이터 실행

정리

📚 다음 단계