deployEMDS WP2.3 Component Deployment Status Survey

Welcome

This survey collects the actual deployment status of WP2.3 building block components across all deployEMDS pilot 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 pilot 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. WHY IS THE COORDINATION TEAM LEADING THIS? This falls within the coordination mandate (WP1) to ensure the EC has an accurate project status. WP2 colleagues have been consulted on the technical content and will have full access to results. 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) 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. DEADLINE: [TO SET — suggested: 10 calendar days from distribution]

Identification

Q2.1Which pilot site / use case are you responding for?

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

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

Q2.3Your primary role in the project

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

Q2.4Which release of the deployEMDS technical stack is your pilot site currently working with?

None yet — We have not deployed any release MVP — Minimum Viable Product release R1 — Release 1 R2 — Release 2 Mixed / Multiple — We use components from different releases

Q2.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

Q3.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?

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

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

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

Q3.5Additional / custom data planes (optional)

Catalogue and Metadata

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

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

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

Q4.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 pilots. Please be as precise as possible about your current status.

Q5.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?

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

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

Q5.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

Q5.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.

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

Q6.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.

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

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

Q7.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.

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

Q8.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)

Q8.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.

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

Data Exchange: Reality Check

This section assesses whether your pilot 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.

Q9.1Can your 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

Q9.2Can your 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?

Q9.3Has your 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?

Q9.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 pilot 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

Q9.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

Q9.6Has any organisation outside your local pilot 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?

Q9.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

Q9.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.

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

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

Q10.2Which partner(s) or component(s) are you currently waiting on? (Select all that apply)

Q10.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 pilot 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)

Q10.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.

Q11.1Does your pilot 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

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

Q11.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

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

Very confident Somewhat confident Uncertain Not confident

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

Final Remarks

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

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

Q12.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.

Your responses will be saved as a CSV file on your computer.
Please email the downloaded file to the coordination team at the address provided in your invitation.

WP2.3 Component Survey