It's easy to collect vehicle data. It's much harder to collect the right data, in a form that engineering, service, and product teams can each use without a translation layer. Most fleet data architectures fail not because they capture too little, but because they capture too much of the wrong thing and too little of the right thing.
Decide What's Worth Streaming vs. What's Worth Logging
Not every signal needs to be real-time. Safety-critical faults and location data often justify streaming; long-term usage trends and diagnostic traces are usually fine as batched, on-change, or condition-triggered logs. Treating everything as a stream is what makes cloud costs spiral — and treating everything as a nightly batch is what makes debugging a live issue impossible.
Push Filtering to the Edge
A vehicle produces far more raw CAN traffic than anyone needs in the cloud. Filtering, deduplication, and compression at the edge — before data ever leaves the vehicle — is usually the single biggest lever for controlling both bandwidth and storage cost, and it doesn't require slower cloud processing to compensate.
Design for the Three Teams That Will Actually Use It
Engineering wants raw signal traces to reproduce a specific failure. Service teams want fleet-wide health summaries and early-warning alerts. Product wants aggregated usage trends to prioritize the roadmap. If your architecture only serves one of these well, the other two will build their own shadow pipeline — which is how organizations end up with three incompatible copies of the same data.
Plan for Schema Change From Day One
Vehicle software changes constantly, and every new ECU or sensor generation potentially changes what signals are available and what they mean. A data architecture that assumes a fixed schema will need a rewrite within a year. Signal harmonization — mapping raw, hardware-specific signals to a stable logical schema — is what lets analytics and dashboards keep working as the underlying fleet evolves.