| name | fleet-management |
| description | Use when designing fleet management infrastructure for IoT device fleets. Covers device provisioning, OTA firmware update strategy, telemetry pipeline design, fleet monitoring, remote management, and scaling projections. Do not use for firmware architecture (use embedded-architecture) or wireless protocol selection (use protocol-design). |
| metadata | {"author":"dtsong"} |
Fleet Management
Purpose
Design the fleet management infrastructure for an IoT device fleet, including device provisioning, OTA firmware update strategy, telemetry aggregation, and fleet-scale monitoring.
Scope Constraints
Produces fleet architecture recommendations covering provisioning, OTA, telemetry, and monitoring. Does not provision actual devices, deploy cloud infrastructure, or manage live certificates. Does not execute firmware builds or signing operations.
Inputs
- Expected fleet size (current and projected)
- Device hardware capabilities (storage, connectivity, compute)
- Update frequency requirements
- Monitoring and alerting requirements
- Regulatory requirements (safety-critical updates, rollback mandates)
Input Sanitization
No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.
Procedure
Step 1: Design Device Provisioning
Plan how devices go from factory to operational:
- Identity: Unique device ID (hardware serial, provisioned certificate)
- Authentication: Device certificates (X.509), pre-shared keys, or cloud-provisioned tokens
- Registration flow: First-boot sequence, cloud registration, owner assignment
- Zero-touch: Can a device self-provision without manual intervention?
- Factory integration: What happens on the manufacturing line?
Step 2: Design OTA Update System
Plan the firmware update lifecycle:
- Partition scheme: A/B (dual partition for atomic swap), single with rollback region
- Update delivery: Pull (device checks periodically) vs push (server initiates)
- Delta updates: Full firmware image vs binary diff (saves bandwidth)
- Integrity verification: Cryptographic signature verification before applying
- Rollback mechanism: Automatic rollback if new firmware fails health check
- Staged rollout: Canary (1%) → early (10%) → general (100%) with hold gates
Step 3: Design Telemetry Pipeline
Plan how device data reaches the cloud:
- Data types: Health metrics (battery, signal, temperature), application data, error reports
- Aggregation: On-device pre-aggregation to reduce bandwidth (send averages, not raw samples)
- Transport: MQTT topics, HTTP batch uploads, or store-and-forward
- Cloud ingestion: Message broker → stream processing → storage
- Retention: Hot (real-time queries), warm (weekly), cold (archive)
Step 4: Design Monitoring and Alerting
Plan fleet-scale observability:
- Health dashboards: Fleet-wide metrics (online %, firmware version distribution, battery levels)
- Anomaly detection: Devices reporting unusual values, sudden offline clusters
- Alert thresholds: Battery < 10%, signal < -90dBm, error rate > 1%, offline > 24h
- Group operations: Query and act on device groups (by firmware version, region, owner)
Step 5: Design Remote Management
Plan remote device operations:
- Configuration updates: Push configuration changes without firmware update
- Remote diagnostics: Request debug logs, trigger self-test, read sensor state
- Remote actions: Reboot, factory reset, enter recovery mode
- Access control: Who can perform which operations on which devices
Step 6: Plan Scaling Strategy
Design for fleet growth:
- Connection management: Connection limits per broker, load balancing
- Update infrastructure: CDN for firmware binaries, rate limiting downloads
- Database design: Time-series storage for telemetry, device registry scaling
- Cost modeling: Per-device cloud cost at 1K, 10K, 100K, 1M devices
Progress Checklist
Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what fleet is being designed, check the Progress Checklist for completed steps, then resume from the earliest incomplete step.
Output Format
# Fleet Management Architecture
## Provisioning Flow
[Factory] → [Flash firmware + certificate] → [First boot] → [Cloud registration] → [Owner assignment] → [Operational]
| Step | Method | Duration | Manual? |
|------|--------|----------|---------|
| Identity | X.509 certificate | Factory | No |
| Registration | MQTT first-connect | <30s | No |
| Owner assignment | QR code scan | User-initiated | Yes |
## OTA Update Strategy
| Aspect | Approach |
|--------|----------|
| Partition scheme | A/B dual-partition |
| Delivery | Pull, 6-hour check interval |
| Format | Delta updates (bsdiff) |
| Verification | Ed25519 signature |
| Rollback | Automatic on 3 failed health checks |
| Staged rollout | 1% → 10% → 50% → 100% with 24h holds |
## Telemetry Pipeline
[Device] → [MQTT] → [Message Broker] → [Stream Processor] → [Time-Series DB] → [Dashboard]
| Data Type | Frequency | Aggregation | Retention |
|-----------|-----------|-------------|-----------|
| Health | 5 min | On-device avg | 90 days |
| Errors | Event-driven | None | 1 year |
| Application | 30 sec | 1-min rollups | 30 days |
## Monitoring Dashboard
| Metric | Threshold | Alert |
|--------|-----------|-------|
| Fleet online % | < 95% | Warning |
| Firmware current % | < 80% | Info |
| Battery critical | < 5% | Critical |
| Error rate | > 1% | Warning |
## Scaling Projections
| Fleet Size | Monthly Cost | Key Bottleneck |
|-----------|-------------|----------------|
| 1,000 | $X | None |
| 10,000 | $X | MQTT connections |
| 100,000 | $X | Telemetry storage |
Handoff
- Hand off to embedded-architecture if firmware-level OTA partition or recovery mode design decisions arise during fleet planning.
- Hand off to operator/observability-design if cloud-side observability infrastructure needs deeper design beyond fleet dashboards.
Quality Checks
Evolution Notes
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
