Dynamic data collection

The solution uses a three-layer data collection model that decouples what signals exist from how they are encoded on the wire from which signals to collect right now. This separation allows fleet operators to change collection behavior without modifying vehicle software or redeploying infrastructure.

Signal catalog

The signal catalog is the single source of truth for every telemetry signal the platform understands. It is stored in the cms-{stage}-signal-catalog DynamoDB table and seeded during deployment with a comprehensive catalog of 260 CAN bus signals across 55 CAN messages, plus 2 GPS signals and 6 metadata fields. The catalog covers a realistic 2026 model-year vehicle with ICE, EV, and hybrid support. It includes 48 actuatable commands for remote vehicle control. The default catalog is a starting point — it is fully customizable to any vehicle platform, OEM signal set, or industry standard.

Customizing the signal catalog

The signal catalog is not hardcoded. Customers replace or extend it to match their vehicle fleet:

When the signal catalog is updated, the SignalCatalogLoader detects the version change in Redis and hot-reloads across all Flink processors without restart. Downstream consumers (Fleet Manager UI, Commands Lambda, FWTelemetryProcessor) automatically pick up the new signals.

Signal entry structure

Each signal in the catalog contains:

Default signal catalog

The solution ships with a comprehensive fleet telemetry catalog covering ICE, EV, and hybrid vehicles. The 260 signals are organized into two tiers:

All IDs are unique and aligned across the signal catalog, decoder manifest, protobuf encoding, and campaign definitions.

Original core signals (15 messages, 75 signals):

Expanded signals (40 messages, 185 signals):

Actuatable commands (48 commands across 6 categories):

VSS path convention

The signal catalog follows the COVESA Vehicle Signal Specification (VSS) naming convention. VSS provides a standardized, tree-structured taxonomy for vehicle signals used across the automotive industry. The fully qualified path uses dot notation from the vehicle root:

Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
│       │       │    │    │     │    │    └── Signal name
│       │       │    │    │     │    └── Component
│       │       │    │    │     └── Position
│       │       │    │    └── Assembly
│       │       │    └── Location
│       │       └── System
│       └── Domain
└── Root

This hierarchical naming enables:

DBC file format

The solution includes a DBC file (services/simulation/can/cms-fleet.dbc) that defines the CAN bus message layout. DBC (Database CAN) is the industry-standard format for describing CAN bus communication, used by every major automotive OEM and tool vendor.

How a DBC file works

A DBC file defines messages (CAN frames) and signals (data fields within frames):

BO_ 256 ECM_Engine_1: 8 Vector__XXX
 SG_ VehicleSpeed : 0|16@1+ (0.1,0) [0|655] "mph" Vector__XXX
 SG_ EngineRPM : 16|16@1+ (1,0) [0|8000] "rpm" Vector__XXX
 SG_ EngineTemp : 32|16@1+ (0.1,-40) [0|370] "degF" Vector__XXX
 SG_ IgnitionOn : 48|1@1+ (1,0) [0|1] "" Vector__XXX

Reading this:

CAN message layout

The default DBC defines 55 CAN messages with different cycle times based on how frequently the data changes:

Original messages (0x100–0x190):

Expanded messages (0x1A0–0x1C7):

Safety-critical signals (speed, braking, acceleration) use 100ms cycle times for rapid detection. Slow-changing signals (tire tread, maintenance indicators) use 5000ms cycles to reduce bus load.

Customizing the DBC

To adapt the guidance for a different vehicle platform:

The Flink processors, Fleet Manager UI, and Redis LKS layer automatically adapt to the new signals through the signal catalog — no code changes required.

Decoder manifest

The decoder manifest bridges the gap between raw CAN bus data and human-readable signal names. It tells the FleetWise Edge Agent how to interpret the binary CAN frames coming off the vehicle bus. The default decoder manifest covers all 260 CAN signals plus 2 GPS custom decoding signals.

Each entry in the decoder manifest maps:

The decoder manifest is defined in a DBC file (services/simulation/can/cms-fleet.dbc) that follows the standard automotive DBC format. The CampaignSyncProcessor reads the manifest from DynamoDB and serializes it as a protobuf DecoderManifest message for delivery to the FWE agent.

Example — how a single signal flows through the decoder manifest:

CAN bus frame 0x100, bytes [0x02, 0x8F, ...]
  → DBC: signal "VehicleSpeed" at bit 0, length 16, factor 0.1, offset 0
  → Raw value: 0x028F = 655
  → Physical value: 655 × 0.1 = 65.5
  → VSS name: Vehicle.Speed
  → standard JSON field: "speed": 65.5

The decoder manifest covers 15 CAN messages with cycle times ranging from 100ms (engine, safety) to 5000ms (tire tread, maintenance indicators). See Signal catalog reference for the complete mapping.

Campaigns

A campaign defines what to collect and from which vehicles. Campaigns are the control plane for FleetWise Edge data collection — they determine which signals the agent actively monitors and uploads.

Each campaign record in the cms-{stage}-campaigns DynamoDB table contains:

Campaign lifecycle

Example campaigns

Full fleet telemetry — Collect all 66 signals from every vehicle at 1-second intervals. This is the default campaign created by the simulation service.

Tire health monitoring — Collect only tire pressure (4 signals) and tire tread (4 signals) from vehicles in a specific fleet at 5-second intervals. Useful for reducing data volume while monitoring a specific concern.

Safety investigation — Collect all ADAS safety signals (10 signals) from a single vehicle at 100ms intervals after a safety incident is reported. High-frequency collection for detailed analysis.

EV battery diagnostics — Collect state of charge, HV battery voltage, regenerative braking power, and motor temperature from EV vehicles only. Uses a condition to collect only when the vehicle is driving (speed > 0).

How the layers connect

Signal Catalog (what signals exist)
    ↓ defines
Decoder Manifest (how to read signals from CAN bus)
    ↓ referenced by
Campaign (which signals to collect, from which vehicles)
    ↓ pushed as protobuf to
FWE Agent (collects and uploads)
    ↓ decoded by
FWTelemetryProcessor (protobuf → standard JSON)
    ↓ flows into
Standard processing pipeline (trips, safety, maintenance)

This layered design means: