Imagine if every electric vehicle (EV) came with its own dedicated charging connector unique to its brand or model. Similar to the early days with mobile phones, charging operators would need to support a range of incompatible plugs—leaving drivers to wonder whether they could charge at a given station. Managing this disparity would quickly become impractical, slowing the ecosystem’s growth.
In the physical world, several industries have made progress by agreeing on common building blocks, such as EV connectors, improving compatibility, and reducing friction for users. In data and software, a similar challenge occurs, but often less visibly. Instead of plugs, we deal with data models and APIs. Different systems often define the same concepts in slightly different ways, leading to integration overhead, duplicated effort, and systems that become harder to evolve.
In the automotive industry, organizations, such as the Connected Vehicle Systems Alliance (COVESA), play an important role. Through projects like the Vehicle Signal Specification (VSS), COVESA has shown how a shared controlled vocabulary can bring consistency across the industry. As mobility ecosystems expand beyond the vehicle into infrastructure and services, COVESA has adapted to modern architectural needs by designing a Simplified Semantic Data Modeling (S2DM) approach. This approach enables domain experts to contribute to shared vocabularies across the broader connected mobility ecosystem, not just the vehicle itself.
In this article, we explore how this approach can be applied from design to storage, using EV charging as a real-world practical example.
A common language for automotive data
Just as standard connectors enable charging, shared data models allow systems to understand each other. In an EV charging scenario, different actors must agree on the meaning and data structures for relevant concepts, such as ChargingSession, Connector, and others. Without that agreement, even well-connected systems struggle to exchange data reliably.
S2DM addresses this need by lowering the barrier to defining that shared vocabulary. It gives domain experts a way to describe data using familiar structures without requiring deep expertise in data modeling. The approach balances simplicity and rigor. It adopts the Schema Definition Language (SDL) of the GraphQL ecosystem as its authoritative language, but focuses on building a canonical data model rather than APIs. In other words, it enables built-time composition and not run-time federated access. The goal is to capture meaning in a way that is clear, consistent, and easy to evolve. Hence, it operates in the conceptual/logical layer rather than in the physical one.
At its core, S2DM embraces SDL to model a domain as entities (i.e., object types) and their properties (i.e., fields). Its tools support governance teams by handling validation, identification of concepts, CI workflows, and releases, translations to other formats, among other functions.
Figure 1. S2DM operating model.
The Vehicle Data Model (VDM) follows the S2DM approach to serve as a controlled vocabulary for any data related to connected vehicles. It extends the earlier VSS approach to cover not only in-vehicle generated data, such as the one coming from sensor observations, but also infrastructure, surroundings, person, and others. This allows different parts of the ecosystem to reuse the vocabulary of common interest.
Figure 2. Representation of sample sub-domains related to the Vehicle Data Model.
A shared model benefits organizations of all sizes. Large companies gain consistency and governance, while smaller players integrate more easily into broader ecosystems. But defining a common language is only the first step. The next question is how this shared understanding shapes the systems that rely on it.
From models to systems
A shared model creates clarity, but systems still need concrete structures to store, validate, and exchange that data. This is where the transition from descriptive to prescriptive becomes important.
S2DM supports this transition through the generation of artifacts. The conceptual model defined by domain experts remains focused on meaning, but it can be translated into formats that systems understand, such as JSON Schema, AVRO Schema, or other data specifications. They become the contract between data production and consumption.
Figure 3. Artifact generation using S2DM.
This separation of concerns allows each layer to evolve independently. Domain experts can refine the model without being constrained by storage or API decisions, allowing engineers to apply those definitions consistently across applications. In practice, this approach improves both speed and consistency. Teams spend less time reconciling differences between systems and more time building functionality.
Connecting the EV charging ecosystem
EV charging brings together a wide range of actors: vehicles, charging stations, operators, mobility providers, and end users. Each of them produces and consumes data, often in real time. A driver expects to find a station, receive accurate information about availability and cost, and start a session. Operators need to monitor infrastructure, manage sessions, and optimize performance. All of this depends on consistent data flowing across systems.
Following the S2DM approach, we can describe this domain with a shared vocabulary. Concepts such as ChargingStation, Connector, ChargingSession, Vehicle, and User are defined once, with clear relationships between them.
From this model, artifacts are generated to support implementation. On the application side, a schema-first approach can be used, where the model is exported into a GraphQL schema. Developers can then generate code from this schema, ensuring that applications follow the same structure and definitions.
On the storage side, the same model can be translated into JSON Schema. In MongoDB, this schema can be applied directly for validation. Although MongoDB is often described as flexible, this flexibility does not mean a lack of control. Schema Validation rules can be defined with different levels of strictness, allowing teams to decide how strongly they want to enforce the model. This makes it possible to maintain consistency while still adapting to evolving requirements.
Figure 4. Schema validation in MongoDB Compass.
This architecture supports the main workloads in an EV charging ecosystem. A driver-facing application relies on geospatial queries to locate nearby stations and on up-to-date session data to guide the charging process. At the same time, operators process high-frequency telemetry from charging points, analyze time-series data, and monitor infrastructure in real time. Across the ecosystem, from automotive OEMs to energy providers such as EnBW and charging platforms like Noodoe, organizations rely on MongoDB to handle these patterns at scale.
Figure 5. EV charging ecosystem architecture overview.
By grounding these systems in a shared model, the ecosystem stays interconnected without constant translation. Applications, APIs, and databases can rely on common definitions to remain aligned.
The foundation for connected systems
A shared model creates a consistent foundation that connects design, development, and operations. S2DM and VDM allow teams to define concepts once and apply them across systems. In the EV charging example, this approach shows how a common vocabulary can guide everything from APIs to database validation.
This work continues as part of an ongoing collaboration within COVESA. One area of focus is how models evolve over time. The flexibility of the document model, combined with design approaches such as the versioning pattern, provides a practical way to manage change while maintaining consistency at the storage layer. At the same time, there is growing interest in how these models can support AI use cases and serve as a foundation for knowledge graphs. Together, these areas point to a broader goal: Building systems that stay aligned as technology, requirements, and ecosystems evolve.
The industry has already aligned on how vehicles connect physically. Aligning how systems understand data is the next step.
Next Steps
Explore the source code of the reference EV charging application and model definition, and discover more connected vehicle solutions in the MongoDB Solutions Library.