deployEMDS is a project co-funded under the EU Digital Europe Programme and responds to its outlined challenges. The project will help make the common European mobility data space a reality. The initiative will cultivate a broad European ecosystem of data providers and users, facilitating the adoption of common building blocks. 16 use cases from nine EU countries will contribute to the development of innovative services and applications.
The European mobility data space (EMDS) will offer a framework for interlinking and federating ecosystems. deployEMDS supports the EMDS initiative through:
- Data interoperability: Sharing and exchanging data in a standardised way
- Data sovereignty and trust: Retaining authority and control over data
- Accessibility: Discoverability and availability of mobility data
The project supports real-life implementations in nine cities and regions:
- Barcelona (ES)
- Île-de-France (FR)
- Milan (IT)
- Lisbon (PT)
- Flanders (BE)
- Sofia (BG)
- Stockholm (SE)
- Tampere (FI)
- Budapest (HU).
These initiatives focus on the development of innovative services and applications in urban mobility, while assisting in policymaking through the sharing and reuse of data.
The deployEMDS repository is the reference container of a thorough assessment of multiple data space technology stacks, more in detail:
- The technical implementations of the
test facilities(see infra) - The test environment, where reference data sources, data schemas, vocabularies, and usage control policies are shared across all tests.
- The tests and assessments, these are linked to the data space participants' customer journeys covering the essential data space capabilities.
A test facility is an environment where a pre-defined technology stack is tested. There might be more test facilities based on the same core technologies but using different capabilities, if this would affect the tests.
For instance: EDC using verifiable credentials, EDC using iShare, Fiware, ...
Each test facility develops tests adapted to the data space's technology. The test definitions are data space stack-agnostic, while the test implementations are specific to the facility. Tests must produce the same expected outcome, but no assumption is made on approaches and technology.
A sandbox environment is provided by IONOS to deploy data space stacks. SaaS providers must make sure that their services are accessible from this environment.
A data space stack is the combination of technical building blocks, and it might span over more than one framework (e.g., EDC + iShare). The choice of the stack is delegated to the EMDS Building Block Working Group. The deployment of the stack should result in a mock data space.
The testing facility is the composition of infrastructure, data space stack, and test squad (team). We define one stack per test facility, and the mock data space should be consistent for each testing facility. They should have:
- The same participants and their identities.
- The same data product(s) being shared.
- The same usage policies.
- The same data planes.
- The same root taxonomies and vocabularies describing the data product(s).
- The same certificate authority.
The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. The progress of each testing facility will be tracked by use of reporting tools, in casu the GitHub issues of this repository.
The deployEMDS testing is planned to be executed in three phases:
-
Phase 1: 2024-07-01 - 2024-07-19
-
Phase 2: 2024-07-22 - 2024-08-09
- Minimal: The minimal set of tests to be executed in each testing facility.
- Extended: The extended set of tests to be executed in each testing facility, should time allow.
The following testing facilities are currently proposed:
| Facility Name | Stack | Components available | Technical buddy | Test squad 1 | Test squad 2 | Status |
|---|---|---|---|---|---|---|
| EDC+VC | EDC v0.7 with Verifiable Credentials | TBD | imec | i2cat (ph 1), NTTDATA (ph 2) | Ready to start | |
| Fiware | Fiware with Verifiable Credentials | TBD | Gernot (Fiware) | Fraunhofer | Cefriel | Ready to start |
| Pontus-X | Gaia-X compliant decentralized data economy toolbox | TBD | TBD | TBD | TBD | Interview had, seems interesting (?) |
- Technical buddies are either commercial providers or experienced partners who help deploying the stacks.
- The Test squads are deployEMDS WP2 workgroup "Building blocks" partners that are responsible for phase 0 and phase 1.
Following the initial stack-comparison testing campaign, the existing deployEMDS technology testing catalogue may also be reused during the integration phase.
The objective of this integration phase assessment is not to compare alternative testing facilities, but to assess the selected protoEMDS technical infrastructure and its readiness to support the expected data space capabilities.
For this purpose, selected existing tests may include an additional result perspective named protoemds_final_stack. This result perspective is added next to the historical stack-specific result files, while keeping the existing test definitions unchanged.
Example:
test.mdresult_edc_vc.mdresult_fiware.mdresult_protoemds_final_stack.md
The assessment should distinguish the deployment model used for the evidence collected:
| Deployment model | Meaning |
|---|---|
| CaaS / IONOS-managed deployment | Deployment managed in the IONOS environment |
| On-premise deployment | Deployment managed in a local or partner-managed environment |
The integration phase assessment should be supported by consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub issues, pull requests, repository references, deployment status or confirmation from the relevant component owner.
This approach keeps the historical EDC+VC and Fiware results unchanged while allowing the project to document the integration readiness of the selected protoEMDS technical infrastructure.
This section highlights the specific existing deployEMDS tests put forward for the protoEMDS Final Stack integration phase assessment.
The integration phase does not execute the full historical test matrix. It reuses a limited subset of existing test definitions and adds an protoemds_final_stack result file to document the assessment of the selected protoEMDS Final Stack when the corresponding evidence is available.
Last updated: 2026-06-23
protoemds_final_stack pending indicates that the protoEMDS Final Stack assessment is still being consolidated. The linked result_protoemds_final_stack.md files provide the integration-phase result perspective for each selected test and should be completed once consolidated evidence is available.
This gives a quick view of the tests from Phase 1 and Phase 2 that were deemed crucial for a Minimum Viable Data Space.
Last updated: 2024-09-06 13:16:10 UTC
GitHub may be utilized for version control; however, code should be treated as an information asset. Prior to publication, all code must undergo a thorough assessment in addition to standard code review procedures. This assessment aims to prevent the unintended disclosure of sensitive information, such as credentials, to the repository.
In accordance with the deployEMDS Information Security Policy, section 7.1 "Information asset protection responsibility," we are required to evaluate all information assets used or created during the project. This evaluation should adhere to the checklist provided in the risk assessment template (Annex 1, pp. 15). The Security Advisory Board (SAB) and Project Security Officer (PSO) should only be consulted if information security concerns arise, such as when any question on the checklist is answered affirmatively.
This process ensures compliance with our security protocols and safeguards the intellectual property and sensitive information.
Please note: secret keys have been redacted in this repository and must be replaced with user-provided keys to ensure functionality.