deployEMDS WP2.3 Component Deployment Status Survey

Welcome

This survey collects the actual deployment status of WP2.3 building block components across all deployEMDS implementation sites. WHY IS THIS INFORMATION COLLECTED? The coordination team currently lacks a reliable, self-reported picture of which technical components are deployed, tested, blocked, or not started at each implementation site. Existing tracking tools are coordinator-maintained and do not capture the ground truth. This survey fills that gap with a structured self-assessment from each site. HOW WILL THE RESULTS BE USED? Results will be aggregated into a component status heatmap and a blockers report. Both will be shared with the full consortium, including WP2 leads. Individual site responses (verbatim) will also be made available. The aggregated results will serve as a baseline for ongoing tracking and will inform coordination decisions, demo planning, and support allocation for the remaining project period. The EC may request this information at any time. WHY NOW? The April technical demo is confirmed, deliverable writing starts in June, and all use cases must demonstrate data sharing by July. We need an accurate baseline now to identify gaps and allocate support in time. WHO IS LEADING THIS? This exercise is led by the coordination team (WP1) in close consultation with WP2. The technical content of this questionnaire has been validated with WP2 colleagues. WP2 leads will have full access to all results and will be involved in defining follow-up actions. WHO SHOULD RESPOND: • One response per use case (e.g., BAR01 = 1 response, BUD01 = 1, BUD02 = 1) • Completed jointly by the Pilot Lead (WP4 SPOC — Single Point of Contact) and their Technical Buddy (WP2.4) • If only one person can respond, the person closest to the technical deployment should fill it in WHAT WE ASK: • For each building block component, report its ACTUAL status today • If something is blocked, tell us what is blocking it • Be honest: this survey is not an evaluation. It is a coordination tool to identify where support is needed before the project end CONFIDENTIALITY: • Responses are visible to the coordination team • All results (aggregated and verbatim) will be shared with WP2 leads and the consortium • Individual site names will not be shared externally without consent Questions marked with * are mandatory. Questions are numbered sequentially starting from Q1.1. DEADLINE: [TO SET — suggested: 10 calendar days from distribution]

Identification

Q1.1Which use case are you responding for?

Q1.2Name(s) of the person(s) completing this survey

If completing jointly (Pilot Lead + Technical Buddy), list both names.

Q1.3Your primary role in the project

Pilot Lead (WP4) Technical Buddy (WP2.4) Both / Joint response Other (please specify)

Q1.4Which release of the deployEMDS technical stack is your use case currently working with?

None yet — We have not deployed any release MVP — Minimum Viable Product release (core connector, basic data plane) R1 — Release 1 (connector + catalogue + initial identity) R2 — Release 2 (connector + catalogue + identity + observability + policy) Mixed / Multiple — We use components from different releases

Q1.5Release details (optional)

If relevant, specify which release version(s) or branch(es) you are using, or any custom setup.

Connector and Data Plane Components

For each component below, select the status that best describes YOUR SITE'S situation TODAY.

Not applicable Not started Deploying Testing Operational Blocked

Q2.1EDC Connector D2.3 §3.2.1 — Participant Agent (core middleware for data transfer negotiation and execution)

Connector details

Where is it deployed? Which version? If blocked, what is blocking you?

Q2.2Connector UI D2.3 Fig.30 — i2CAT (i2CAT web-based UI for managing the EDC connector)

Q2.3Data Plane: HTTP / REST API D2.3 §3.2.1.4 — Transfer Process (data transfer via REST APIs with API key authentication)

Q2.4Data Plane: MQTT / Streaming D2.3 §3.2.1.4 — Transfer Process (real-time or near-real-time data transfer)

Q2.5Additional / custom data planes (optional)

Catalogue and Metadata

These components handle data discovery, metadata descriptions, and catalogue federation.

Q3.1Local Connector Catalogue D2.3 §3.2.1.2 — Data, Services & Offerings Catalogue (asset descriptions, contract offerings, usage policies within your connector)

Q3.2Federated Catalogue D2.3 §3.2.3 — Catalogue (DS Level) / Fig.30 Cefriel (Cefriel — harvests participant connectors and integrates data offers)

Q3.3mobilityDCAT-AP metadata compliance D2.3 §3.2.3 — DCAT-AP / mobilityDCAT-AP

Are your data product descriptions aligned with the mobilityDCAT-AP profile?

Not applicable Not started: no metadata work done yet In progress: working on aligning our metadata Partially compliant: some fields aligned, gaps remain Fully compliant: metadata follows mobilityDCAT-AP Blocked: metadata requirements are unclear or not implementable

Please describe any challenges with metadata compliance.

Identity and Trust

These components manage participant identification, credential issuance, and trust anchors within the data space. NOTE: The Identity Hub has been identified as a cross-cutting dependency for many implementation sites. Please be as precise as possible about your current status.

Q4.1Identity Hub / Participant Wallet D2.3 §3.2.1.1 — Participant Wallet / §3.2.2 Data Space Wallet

Manages participant identity, Verifiable Credentials, and DIDs

Not applicable Not started: we have not begun identity integration Waiting: we need the Identity Hub but it is not yet available to us Deploying: we are integrating the Identity Hub into our setup Testing: Identity Hub is deployed and we are validating it Operational: Identity Hub is running and used in our data exchanges Workaround: we are operating without the Identity Hub using an alternative Blocked: we received the Identity Hub but cannot proceed

If WAITING: what are you waiting for and from whom? If WORKAROUND: what alternative? If BLOCKED: what is blocking?

Q4.2VC Issuer and Verifier D2.3 §3.2.2.2 — Trust Anchors (NTT DATA)

Q4.3Gaia-X / XFSC Catalogue Middleware D2.3 Fig.30 — Fraunhofer XFSC (Fraunhofer)

Q4.4Usage Policy Definition D2.3 §3.2.1.3 — Usage Policies (ODRL) (ODRL-based policies defining how shared data may be used)

Not applicable: we do not define usage policies Not started: we need policies but have not defined any yet Hypothetical only: drafted on paper but not implemented Deploying: policies being configured in our connector Testing: policies are active and being validated Operational: policies are enforced in production Blocked

Q4.5Usage Policy Enforcement D2.3 §3.2.1.3 — Policy Enforcement (runtime enforcement during data exchanges)

Vocabulary and Semantics

These components ensure data interoperability through shared vocabularies, data models, and semantic descriptions.

Q5.1Vocabulary Hub D2.3 §3.3.4 — Vocabulary Hub (NTT DATA / imec / Fraunhofer)

Q5.2Which data models or standards are you using or planning to use? (Select all that apply)

Observability and Logging

These components monitor data space health, log transactions, and provide traceability of data exchanges.

Q6.1Observability Module D2.3 §3.3.3 — Observability Registry / Fig.30 i2CAT (i2CAT — health monitoring, visual dashboards)

Q6.2Notarisation Service D2.3 Fig.30 — i2CAT Notarisation (i2CAT — centrally logging business process events)

Q6.3Extended Logging D2.3 Fig.30 — i2CAT Extended Logging (i2CAT — connector-level transaction logging)

Onboarding

These components manage the process of registering new participants into the data space.

Q7.1Participant Onboarding Portal D2.3 §3.3.1 — Onboarding Portal / §3.2.2.1 Orchestrator (NTT DATA / i2CAT — web-based self-service)

Q7.2How did you onboard your participants to the data space?

Not yet onboarded any external participants Manual process (CLI / API commands) Through the onboarding portal Via technical buddy support (hands-on assistance) External contractor / third-party support Self-service (participants onboarded themselves) Other (please specify)

Q7.3How many distinct organisations are currently onboarded (with a working connector)?

Count each organisation with a deployed and configured connector as 1. Include your own organisation.

Q7.4How many additional organisations do you plan to onboard before project end? (optional)

Data Exchange: Reality Check

This section assesses whether your implementation site can actually exchange data through the data space today. This is the most important section of the survey. Please answer based on what you have ACTUALLY tested, not what you plan to do.

Q8.1Can your implementation site publish data offers (make data products visible in the catalogue)?

Yes, we have published data offers Partially: we can publish but with issues No, we cannot publish data offers yet Not attempted

Q8.2Can your implementation site actually transfer data (send or receive actual data payloads through the connector)?

Yes, we have successfully transferred real data Yes, we have transferred test / dummy data Partially: transfers work intermittently or with workarounds No: we can publish offers but cannot transfer data No: we have not attempted data transfer yet

If NOT working or only partially: what happens when you try? Any GitHub issue?

Q8.3Has your implementation site completed at least one full end-to-end data sharing cycle?

Provider publishes offer → Consumer discovers → Contract negotiation → Data transfer → Consumer receives data

Yes, fully completed with real data Yes, fully completed with test / dummy data Partially: some steps work, others do not No

If partial or no: which specific step(s) fail or are not yet working?

Q8.4Data exchange partners (optional)

With which organisations have you exchanged (or attempted to exchange) data?

proto-EMDS Contribution

The proto-EMDS is the federated layer connecting all 9 implementation sites through shared technical components (federated catalogue, connector, identity management) and governance. These questions assess whether your use case contributes to this cross-site federation. Ambition Statement, Oct 2025

Q8.5Is your use case connected to the deployEMDS Federated Catalogue (Cefriel)?

Are your data products visible and discoverable at the proto-EMDS level (beyond your local connector)?

Yes: our data products are visible in the federated catalogue In progress: we are working on the connection No: we are not connected to the federated catalogue Not sure

Q8.6Has any organisation outside your local implementation site ever discovered or accessed your data through the proto-EMDS infrastructure?

This means: another deployEMDS site, a TUC participant, or an external party finding your data via the federated catalogue and initiating a contract negotiation or data transfer.

Yes No Not sure

If yes: which organisation(s) and what happened?

Q8.7In your view, does your use case require cross-site data sharing to achieve its core objectives?

Yes: our use case depends on data from other deployEMDS sites Partially: cross-site sharing would add value but is not strictly required No: our use case operates with local data only

Q8.8Is your use case contributing to any Transversal Use Case (TUC)? (optional)

TUCs (e.g., UMI, EV charging, integrated ticketing) are designed to demonstrate cross-site data sharing.

UMI (Urban Mobility Indicators) EV Charging Integrated Ticketing None / Not involved in any TUC Other (please specify)

Blockers and Dependencies

Be specific: naming the exact component, partner, or issue helps us route support effectively.

Q9.1Top blocking issues (up to 5, most critical first)

#	What is blocked?	Which component / partner?	Since when?
1
2
3
4
5

Q9.2What are you currently waiting on? (Select all that apply)

Q9.2bIf you selected items above, please briefly explain what specifically you are waiting for

E.g., "Identity Hub: waiting for deployment credentials from NTT DATA since February" or "Governance: need ODRL policy templates from WP3 before we can configure usage policies"

Q9.3What type of support would help you most right now? (Select up to 3)

Technical hands-on support (someone helps us deploy) Documentation (clearer installation / configuration guides) Training / workshop (on a specific component) Peer learning (see how another implementation site solved the same problem) Architecture guidance (how to set up our specific case) Faster delivery of a component we are waiting for Legal / governance advice None: we are self-sufficient Other (please specify)

Q9.4GitHub issues (optional)

If you have reported issues on GitHub (deployEMDS repositories), list issue numbers or URLs.

R3 and Forward-Looking

The R3 (final) release is planned for June 2026. This section helps us understand your plans for the remaining project period.

Q10.1Does your use case plan to integrate R3 (final release) components?

Yes: we plan to upgrade to R3 when available Partially: we will adopt some R3 components No: we will stay on our current release Undecided: we need more information about R3

Q10.2Which specific R3 features or components are you most interested in? (conditional)

Q10.3Realistically, when do you expect a working end-to-end data sharing demonstration?

Already achieved By June 2026 By September 2026 By October 2026 (current project end) By January 2027 (extended project end) Unlikely within the project timeline

Q10.4How confident are you that your use case will achieve its core objectives?

Very confident Somewhat confident Uncertain Not confident

Q10.5What would need to change for you to become more confident? (conditional)

Final Remarks

Q11.1Is there anything working particularly well that you would like to highlight?

Q11.2In one sentence: what is the single biggest gap between where your use case is today and where it needs to be?

Q11.3Any other comments, questions, or concerns?

END OF SURVEY

Thank you for completing this survey.
Your responses will be reviewed by the coordination team within 5 working days.
If you reported critical blockers, we will follow up directly.

Two steps to submit your responses:

1

Download your responses as a CSV file to your computer

2

Send the downloaded CSV file to the coordination team by email

Please download the CSV first (Step 1), then click Send by Email (Step 2).
The CSV file must be attached manually to the email that opens.

WP2.3 Component Survey