Scaling Vehicle Data Innovation: A VISS Proof of Concept

Authors: Ulf Björkengren, Ford, and Rami Pinto, MongoDB

As connected vehicle services expand from individual vehicles to entire fleets, the challenge is no longer only how to access vehicle data, but how to make that data useful across increasingly diverse systems.

VISS provides an important foundation by defining a common interface for accessing vehicle data. As the specification has evolved, so have the needs it addresses. Recent VISS 3.x developments introduce greater flexibility in how vehicle data can be organized, exposed, transported, and consumed, helping the interface support a broader range of vehicle and service architectures.

At the same time, more vehicle data is moving beyond the vehicle itself. That raises a practical question: how can VISS-based data be connected to cloud systems that can handle growing volumes, evolving data structures, and fleet-scale workloads?

A collaboration between Ford and MongoDB has been exploring this through a VISSR-based fleet monitoring experiment.

VISS Evolves for More Diverse Vehicle Data

VISS 3 introduced capabilities that make the specification more adaptable to real-world vehicle architectures. These include support for multiple data trees, richer server capability information, additional transport and payload options, and schema-based validation. Together, these capabilities make it easier to expose vehicle information in ways that reflect different domains and application needs.

The introduction of the HIM Vehicle data profile extends this flexibility further. Rather than assuming a single VSS-based tree, VISS can work with multiple trees defined using the vspec syntax and expose them through the same interface. This becomes particularly useful as vehicle data models need to represent more complex systems and combinations of assets.

The VISSR reference implementation provides a practical environment for exploring these capabilities with running software. The specification continues to evolve, with VISS 3.2 extending the work through additional capabilities for accessing multiple signals efficiently.

Figure 1. VISSR technology stack

Bringing VISS Data to the Cloud

Once data from many vehicles needs to be collected and used centrally, the architecture must address a different set of challenges. Fleet applications may need to ingest continuous telemetry, support real-time access, and accommodate data structures that evolve as vehicles and use cases change.

Document-oriented data stores are one approach to this problem. Their flexible data model can represent diverse vehicle information without requiring every variation to fit a rigid structure, while distributed architectures can support the scale and availability expected from cloud services.

The VISSR integration experiment explores these ideas through a truck fleet monitoring scenario. Simulated vehicles publish telemetry through MQTT, which is then synchronized into a cloud backend for storage and access. The experiment uses the HIM model to represent the relationship between a truck and its trailer, providing a concrete example of how richer vehicle structures can be carried from the vehicle into backend systems.

MongoDB is used in the experiment as an archetype of a document-oriented cloud backend, providing a practical way to evaluate the architecture and its data flows. The complete implementation is available in the VISSR integration GitHub repository.

Figure 2. VISSR cloud synchronization architecture with MongoDB

The broader lesson is that standardizing how vehicle information is exposed is only part of the journey. As connected vehicle data moves into cloud-based services, the same emphasis on flexibility and interoperability needs to continue through the systems that collect, store, and use it.

Get Involved!

Learn more about the VISS project, explore the VISSR reference implementation, and contribute through the VISS GitHub repository.