SKIX 서비스 라이프사이클과 도메인 상태 감사
현재 결론
주요 ManagerService에는 서로 독립적인 두 상태축이 필요하다.
- Component lifecycle: 서비스가 요청을 받을 수 있는가.
CREATED → STARTING → READY, 장애 시DEGRADED → RECOVERING → READY, 종료 시STOPPING → STOPPED로 관리한다. - Domain operation state: 로봇 기능이 지금 무엇을 하고 있는가.
예를 들어 Mobility는
IDLE / PREPARING / MOVING / PAUSED / DOCKING / STOPPING / ERROR를 소유한다.
서비스가 READY라고 해서 도메인이 IDLE인 것은 아니다. 반대로 도메인이
IDLE이어도 서비스가 DEGRADED라면 신규 명령을 받아서는 안 된다.
- 이 그림이 답하는 질문: 서비스가 요청을 받을 준비가 됐다는 상태와 로봇이 실제로 동작 중이라는 상태를 왜 따로 관리하는가?
- 읽는 순서: 왼쪽 서비스 준비 상태와 오른쪽 기기 동작 상태를 비교한 뒤 아래의 함께 적용하는 규칙을 읽는다.
- 현재 검증 범위: 공통 lifecycle 골격과 상태 전이 계약은 JVM 검증됐다. AOSP 부팅 연결과 장애 복구의 실기기 동작은 검증 전이다.
AOSP식 소유권
SDK Manager
→ ManagerService typed request
→ Component lifecycle READY gate
→ Domain operation state snapshot
→ Policy / Resource admission
→ desired-state transition
→ Executor / DeviceAgent
→ MCU·HAL·remote completion evidence
→ observed-state transition
→ StateMirrorService + Task result publication
- 각 ManagerService가 자기 도메인 상태의 유일한 writer다.
- StateMirrorService는 immutable snapshot을 모아 호환 상태를 제공할 뿐, 도메인 상태를 추론하거나 덮어쓰지 않는다.
- PolicyManagerService는 상태를 읽고 결정만 하며 하드웨어 명령을 호출하지 않는다.
- WorkflowManagerService는 stop/prepare/execute/wait/compensation 순서를 소유한다.
- ResourceManagerService는 camera, audio, display, fan, tilt 같은 공유 자원 lease를 소유한다.
- DeviceAgent는 각 vertical slice가 실기기 검증될 때까지 단일 privileged executor다.
현재 소스에서 확인한 상태 집중
| Legacy 영역 | 소스에서 확인한 혼합 상태·책임 | 목표 소유권 |
|---|---|---|
StateManager |
청정·ICT·업데이트·SelfTest·Wizard·Streaming과 UI side effect를 한 main state에 혼합 | 도메인별 ManagerService + read-only StateMirrorService |
CmdPolicyManager |
admission, 암묵 priority, stop workflow, 복귀 실행을 한 클래스에서 수행 | Policy + Workflow + Mobility + executor |
MovingController |
위치·목적지·이동·도킹·충전·availability를 관리하며 isMoveToStation()은 TODO 고정값 |
AmrManagerService observed/desired state |
CleaningTransaction |
mode·action·pause·countdown·fan·schedule·AI·movement를 혼합 | CleaningManagerService + Mobility/Resource/Workflow |
AirCleaningPolicy |
실제 호출되지만 최종 POLICY_NOT_DEFINED, 일부 상태 강제값 존재 |
사양 확인 후 Cleaning admission으로 이관 |
WssTransaction |
run state·verification stage·movement state를 별도 축으로 보유 | SecurityManagerService + VisionManagerService + Mobility |
WssPolicyChecker |
camera·tilt·privacy·network·battery bit를 혼합하며 warning과 blocker를 구분 | typed PolicyDecision의 warning/rejection 분리 |
LlmManager |
STT·cloud/on-device·TTS·pause·init·reinit 상태 | LlmManagerService |
StreamingManager |
stream lifecycle과 AMR movement/stop reason을 함께 보유 | StreamingManagerService + Mobility snapshot |
InterScheduleManager |
workflow·action·pause·movement·timeout을 혼합 | WorkflowManagerService + TaskManagerService |
ScheduleAlarmReceiver |
duplicate·due trigger·admission·실행 dispatch를 혼합 | TaskSchedulerManagerService → Policy → Task |
| IotAgent | Android service·MQTT connection·reconnect timer·publish 결과를 혼합 | IotManagerService lifecycle + delivery evidence |
ManagerService별 상태 소유권
| ManagerService | 운영 상태 예시 | 외부로 분리할 책임 |
|---|---|---|
| AmrManagerService | idle, preparing, moving, paused, docking, stopping, error | tilt 정책, UI, cleaning state |
| CleaningManagerService | idle, preparing, stationary/mobile cleaning, paused, stopping, error | movement truth, global admission |
| AirQualityManagerService | idle, monitoring, mapping, paused, error | cleaning/mobility execution |
| PowerManagerService | unknown, ready, invalid; percent·low·charging observation | System 설정·AMR 이동 실행 |
| VisionManagerService | idle, acquiring, observing, processing, error | camera lease priority, WSS workflow |
| LlmManagerService | idle, preparing, listening, thinking, speaking, paused, error | audio lease와 movement |
| internal StreamingRuntimeService | idle, starting, active, paused, stopping, error | LLM/AMR authority 재정의 |
| SecurityManagerService | idle, starting, patrolling/monitoring, paused, stopping, error | Vision 구현 상태 |
| IotManagerService | disconnected, connecting, connected, degraded, recovering | delivery Task terminal state |
| TaskSchedulerManagerService | idle, evaluating, submitting, recovering, error | cross-domain command 실행 |
| EvidenceManagerService | lifecycle ID만 반영, 기능·operation state 미구현 | provider progress/result를 Task terminal과 구분해 수집 |
| UpdateManagerService | idle, checking, downloading, verifying, installing, reboot-required, failed | UI presentation priority |
| UiManagerService | requested, launching, ready, foreground, paused, dismissed, failed | domain admission |
| TaskManagerService | submitted, admitted, queued, running, waiting-evidence, terminal | domain observed state |
이번 소스 반영
refactor/blueprint-foundation에 다음 foundation을 반영했다.
- 5개 Control + 4개 Execution + 15개 Product Domain의 계획 ID, Runtime root, internal Streaming provider를 합한 26개 독립 lifecycle component 등록
- 15개 Product Domain은 별도 concrete
*ManagerServicelifecycle 골격으로 생성; Control/Execution은 Task·Policy 외에는 아직 기능 구현 전 - Cleaning·AirQuality·Power·UI는 같은 process를 공유해도 서로 다른 component ID·의존성·상태 타입을 유지
ServiceLifecycleSupervisor의 명시적 전이, sequence, reason, timestamp- dependency가 READY가 아니면 start 거부
- 기반 component 장애 시 준비/실행 중인 종속 component를 전이적으로 DEGRADED 처리
- lifecycle READY가 아니면 domain state transition 거부
- immutable
DomainStateSnapshot과 explicit transition graph - Mobility, Cleaning, Air Quality, Vision, LLM, Streaming, Security, IoT, Schedule, Update, UI의 초기 상태 family
AMR·IoT·MCU·Pairing·EventAsset·System·Diagnostics는 concrete lifecycle 골격은 반영됐지만 도메인 operation state enum은 기존 소스 characterization 전이다. 사양 근거 없이 임의 상태를 만들어 완료로 표시하지 않는다.
이 상태 enum은 목표 경계이며 현재 DeviceAgent 동작을 변경하지 않는다. 정확한 transition graph는 기존 소스 characterization과 제품 사양 확인 후 도메인별로 고정한다.
검증 상태
| Gate | 상태 | 범위 |
|---|---|---|
| 설계 완료 | 완료 | 두 상태축, writer, dependency, evidence 경계 |
| 소스 반영 | 완료 | lifecycle/state foundation 및 주요 domain enum |
| JVM 검증 | PASS | lifecycle ordering, dependency degradation, READY gate, transition guard |
| APK 빌드 | PASS | SkixFrameworkService.apk release source integration |
| 실기기 검증 | 미검증 | Binder death, 재연결, 실제 MCU/HAL 완료는 아직 확인 전 |
따라서 현재 최고 판정은 소스 반영 + JVM 검증 + APK 빌드다. 구현 커밋은
a4588bc, release APK SHA-256은
ce7217bb38cee8760a15cd936728b76272bd7cd362cde12f569bad62931a50e1이다.
이를 실기기 검증으로 확대 해석하지 않는다. 현재 상태는 실기기 미검증이다.
후속 순서
- legacy 상태와 신규 snapshot을 연결하는 read-only adapter를 만든다.
CmdPolicyManager, WSS, Cleaning, Schedule의 현재 결정을 characterization 한다.- stable rule/reason ID로 shadow comparison을 기록한다.
- MR6
task_manager의 queue·timeout·retry·cancel·compensation을 서버 권위로 이식한다. - 한 vertical slice씩 executor ownership을 옮기고 dual execution을 차단한다.
- process death, Binder reconnect, timeout, cancel, evidence failure와 물리 완료를 실기기에서 검증한다.