S2DM in Action: From Models to Systems

As connected mobility expands beyond the vehicle, the need for consistent data across domains becomes more visible. Within COVESA, the Vehicle Data Model (VDM) formalizes data of common interest across the vehicle and vehicle-related sub-domains, based on the Simplified Semantic Data Modeling (S2DM) approach.

This blog explores how S2DM enables systems at the physical layer, such as databases and applications, to share common concepts modeled in a unified conceptual layer, using EV charging as a practical example.

A Foundation for Shared Data Models

S2DM addresses a common challenge: different systems often represent the same concept in slightly different ways. This leads to duplicated effort, fragile integrations, and inconsistent data interpretation. By providing a structured yet accessible modeling approach, S2DM allows domain experts to define entities and relationships using a common language. 

At its core, S2DM uses the GraphQL Schema Definition Language (SDL) to describe domains in terms of object types and fields. These definitions are not tied to a specific runtime or storage system. Instead, they form a canonical representation of meaning that can be reused across teams and organizations.

The key step is the transition from descriptive models to prescriptive artifacts. S2DM enables the generation of implementation-ready specifications such as JSON Schema or other formats. These artifacts serve as enforceable contracts between producers and consumers of data. Teams can select only the relevant entities or fields and apply them to specific systems, ensuring alignment without forcing a one-size-fits-all implementation.

This separation between conceptual modeling and physical realization brings practical benefits. Large organizations gain consistency and governance across distributed teams, while smaller participants can integrate more easily into shared ecosystems. At the system level, it reduces ambiguity and makes data validation and interoperability part of the design rather than an afterthought.

An EV Charging Example

EV charging ecosystems involve multiple organizations and systems that must exchange data reliably, from vehicles and charging stations to mobility operators and energy providers. In practice, even common concepts are interpreted differently. When does a charging session start: when the vehicle plugs in, when energy begins flowing, or when billing starts? And what does energy delivered represent, the amount drawn from the grid, or what the vehicle actually receives?

At the same time, EV charging systems need to support a diverse set of workloads, including geospatial queries, telemetry streams, and analytics. Across these contexts, maintaining consistency in units, rounding, and formats remains challenging, despite existing standards.

Given this complexity, how do we ensure that all participants interpret shared data consistently across domains? 

S2DM provides a way to address this by defining common concepts once and selectively translating them into artifacts that can be applied across systems. These artifacts can be used to guide API definitions, database schemas, or other implementation layers. Let’s look at a simple example of how this can be applied end-to-end.

At the application layer, one option is to use the shared model directly as a GraphQL schema. Since S2DM is based on SDL, this provides a simple and direct way to apply it, though it is not limited to this approach. Furthermore, in a schema-first design, the schema can also drive code generation, helping keep type definitions in the application aligned with the model.

At the storage layer, different databases may use different mechanisms to enforce structure and validation. In this example, MongoDB is chosen as an archetype of a popular cloud database for these workloads. Here, the JSON Schema artifacts can be used for validation. Often described as schema-less, MongoDB is better understood as having a flexible schema, as it does not require a predefined, rigid structure before storing data. This flexibility does not imply a lack of control. Teams can selectively enforce validation rules to the degree needed while still allowing the model to evolve.