Integration Map
MaaSAI solutions work together through a small set of shared interfaces and a set of documented solution-to-solution connections. This page summarises the integration principles, the interfaces and their protocols, the connections between solutions with the data they carry, and the security principles that apply to them. The connections follow the D5.1 reference architecture and are refined in the M20 implementation deliverables (D6.1, D8.1, D10.1, D12.1).
Integration map of the MaaSAI solutions, drawn from the D5.1 reference architecture and the M20 implementation deliverables.
Integration Principles
Section titled “Integration Principles”- Standards-based and message-oriented: open standards and event- or message-driven integration are preferred over bespoke point-to-point coupling. The standards in use in the first release are REST/JSON, MQTT, the Ethereum JSON-RPC, ISA-95 (the data model of EDGE Data Storage), and RDF/Turtle with SPARQL inside the MaaS Dynamic Catalogue (D6.1, D8.1, D10.1, D12.1).
- Open APIs: each solution exposes documented APIs. The M20 deliverables include endpoint tables for most solutions, and EDGE Data Storage documents its API with Swagger UI (D8.1 §3.6).
- Loose coupling: solutions are microservices, each deployable independently as a Docker or Docker Compose unit (D6.1, D8.1, D10.1, D12.1).
- Microservice conventions, taken from the marketplace design principles in D5.1 §3.1: stateless services; one database per component, with no shared databases; shared object storage allowed, with files passed by URL; documented JSON payloads instead of file transfer; a health endpoint returning HTTP 200 or an error code and message; a central registry of component endpoints; Single Sign-On for user interfaces and JWT for API calls.
- Secure by design: D5.1 assigns authentication, authorisation and encryption of exchanged data to the secure messaging layer (see Security and Access).
- Provenance where it matters: contracts are anchored on the MaaS Blockchain, and only the Smart Contracts Toolkit writes contracts to the ledger (D8.1 §6.5; see Smart contract origination).
Interfaces
Section titled “Interfaces”The M20 deliverables document the following interfaces and protocols.
| Interface | Between | Protocol and pattern | Documented in |
|---|---|---|---|
| Marketplace API | Provider and consumer interfaces and agents towards CMM; CMM towards MDC, RS, the agents and MCH | REST over HTTPS with JSON (Django REST Framework); CMM works with the agents through the agents’ REST API | D6.1 §2.3, §5.5 |
| Agent negotiation protocol | MCA and MPA (both directions) | MQTT over the PSM broker with mutual TLS and token-based access; JSON messages on discovery and bilateral negotiation topics, covering price, quantity and delivery date; agent-internal communication between orchestrator and child agents over XMPP | D6.1 §5.2–5.3 |
| ERP and MES connector | DI and enterprise ERP and MES systems (both directions) | HTTP polling at a configurable interval and HTTP webhooks; CSV, JSON, XML or iDoc input, converted to ISA-95 JSON and written to DS | D8.1 §2.2, §2.5 |
| Secure messaging | Provider and consumer systems, agents, IoT devices, desktop and mobile clients, through PSM | MQTT on Eclipse Mosquitto 2 with mutual TLS; Keycloak-issued JWT validated by the broker; topic-level authorisation by role | D8.1 §4.3–4.5 |
| Contract origination and ledger | CMM towards SCT; SCT towards MSB | Business-event webhook with JSON payloads into SCT; SCT signs transactions (web3.py) and submits them to MSB through the Ethereum JSON-RPC over HTTPS | D12.1 §6.2–6.3; D8.1 §6.4–6.5 |
| IoT and digital twin ingestion | Shop-floor sensors towards DTD, CP and PMT | Per solution: MQTT (Mosquitto 2) and Apache NiFi into DTD, with twin state held in Eclipse Ditto; Telegraf into InfluxDB 3 for CP; a Node-RED collector into TimescaleDB for PMT | D10.1 §2.3, §3.3; D12.1 §4.3–4.4 |
| Ontology and catalogue query | CMM towards MDC | REST/JSON for catalogue filters, provider publication and search, which returns the list of matching providers; SPARQL is used inside MDC (Apache Jena Fuseki) | D6.1 §3.5 |
| KPI and analytics API | DA and other sources towards CP | REST API of DA (FastAPI); CP accepts InfluxDB v3 HTTP writes (line protocol) and queries, and exposes Apache Superset charts and dashboards through REST | D10.1 §3.5, §4.5 |
| EDGE Data Storage access API | DI, MCP, MPP, RMC, DIP and, as intended, PMT towards DS | REST API generated by PostgREST for each ISA-95 table and documented with Swagger UI; bearer JWT with PostgreSQL row-level security; TLS | D8.1 §3.3–3.6 |
CMM mediates between the catalogue and the recommendation service: it obtains the matching providers from MDC and passes the preselected alternatives and the decision criteria to RS, which ranks them (D6.1 §4.1, §4.5).
Connections
Section titled “Connections”The tables below list the documented connections between solutions, grouped by area. Each connection is listed in the direction in which it is described; ‘both directions’ marks an exchange that goes both ways.
Marketplace
Section titled “Marketplace”Discovery, ranking, negotiation and contract origination around the Cloud MaaS Marketplace (CMM).
| From | To | Protocol and pattern | Data that travels | Documented in |
|---|---|---|---|---|
| CMM | MDC | REST/JSON | Provider capability publications, consumer search requests and catalogue filters; MDC returns the list of matching providers | D6.1 |
| CMM | RS | REST/JSON | Preselected candidate resources with decision criteria and weights; RS returns a ranked shortlist | D6.1 |
| CMM | MCA and MPA, through their orchestrator agents (both directions) | REST/JSON | Agreed terms returned to CMM; published resource notices, request candidates, deadlines, availability and costs, selected parties, and the start, terms and decision of each negotiation | D6.1 |
| MCA | MPA, over the PSM broker (both directions) | MQTT, mutual TLS and token-based access | Offers and counter-offers on price, quantity and delivery date until agreement | D6.1; D8.1 |
| CMM | MCH | REST/JSON | Order notification with the contract, provider, consumer, request and resource details | D6.1 |
| CMM | SCT | HTTP webhook, JSON (contract origination) | The finalised agreement as a business event (action, entity identifier, value and metadata) | D12.1; D6.1 |
Data Backbone
Section titled “Data Backbone”The ledger, the EDGE Data Storage and the Digital Industrial Passport, and the solutions that read from or write to them.
| From | To | Protocol and pattern | Data that travels | Documented in |
|---|---|---|---|---|
| SCT | MSB | Ethereum JSON-RPC | Signed transactions, contract state reads and writes, provenance records | D12.1; D8.1 |
| DI | DS | REST via PostgREST, ISA-95 JSON | ERP and MES master and operational data, harmonised to ISA-95 | D8.1 |
| DS | RMC | REST via PostgREST | Machine lists and status, calendar events and KPIs for remote monitoring | D10.1; D8.1 |
| PMT | DS (both directions) | REST and Node-RED (intended) | Telemetry and machine status towards PMT; maintenance plans and shutdown windows back to DS | D12.1 |
| MPP and MCP | DS | REST via PostgREST, ISA-95 JSON | Scheduler input read from DS (calendar, resource types, work breakdown structure, operator expertise); scheduling plans written back | D12.1 |
| DIP | DS (both directions) | Shared PostgreSQL / REST | Asset look-up, correlation handling and blueprint logging | D8.1 |
| MPA | DIP | API (to be defined) | Raw asset information and the instruction to start passport configuration | D8.1 |
Provider and Consumer Suites
Section titled “Provider and Consumer Suites”Digital twin, analytics, monitoring, workspace configuration, planning and simulation solutions.
| From | To | Protocol and pattern | Data that travels | Documented in |
|---|---|---|---|---|
| Shop-floor sensors | DTD | MQTT and Apache NiFi | Real-time shop-floor telemetry and asset feature values | D10.1 |
| DTD | DA | REST (intended) | Live twin state and processed asset data for analytics and KPI computation | D10.1 |
| DA | CP | REST; InfluxDB line protocol (intended) | KPIs and analytics results for dashboards | D10.1 |
| MWC | DTD | API (route to be defined) | Asset and resource state, availability, tool readiness and workspace state | D10.1 |
| MWC | MaaS Booking services | API (route to be defined) | Job and booking input: job identifiers, product, quantity and due dates | D10.1 |
| MCA | MCP | API (planned) | Request identifier, product type, quantity, target price and penalties; MCP returns the delivery date and the resources used | D12.1 |
| MPA | MPP | API (planned) | Request identifier, product type, quantity, target price and penalties; MPP returns the delivery date and the resources used | D12.1 |
| SCS | MCP and DS | API (planned) | Resilience hints and feedback: logistics bottlenecks, transport delays and warehouse utilisation | D12.1 |
| CMM | CP | API (intended; marketplace metrics) | Marketplace metrics and provider and consumer interaction data for visualisation | D10.1 |
Data Exchanged
Section titled “Data Exchanged”The main types of data that travel on these connections:
| Data | Typical content | Main deliverables |
|---|---|---|
| ERP data | Production orders, bill of materials and master data, calendar, resource types, work breakdown structure, operator expertise | D8.1; D12.1 |
| MES data | Production progress, operation status, produced quantities, shop-floor events | D8.1 |
| Sensor and IoT telemetry | Real-time signals and time-series feature values from assets | D10.1; D12.1 |
| Catalogue and ontology | Service and capability descriptions, vocabulary, search criteria, candidate resources | D6.1 |
| Organisation, user and order data | Organisations, users, facilities, resources, order requests and ranking criteria held by CMM | D6.1 |
| Negotiation log (off-chain) | Offers (price, quantity, delivery date), utility values and negotiation rounds | D6.1 |
| Agreements and contracts | Agreements, business events, on-chain transactions, provenance and audit records | D8.1; D12.1 |
| Life-cycle and passport data | Passport blueprints, asset lifecycle records, LCC and LCA values | D8.1; D12.1 |
| LCA and LCC inventory | Emission and cost factors, lifecycle inventory | D12.1 |
| KPI measurements | KPI values and analytics outputs | D10.1 |
Security and Access
Section titled “Security and Access”- Design intent: D5.1 (§3.1) calls for a central security mechanism with Single Sign-On for user interfaces and JWT for API calls, and assigns authentication, authorisation and encryption of exchanged data to the secure messaging layer (§3.3).
- Identity: Keycloak with OpenID Connect is the identity and access management platform reported in D8.1 (§4) for the secure messaging stack.
- Messaging: the secure messaging broker combines mutual TLS, Keycloak-issued tokens and topic-level access control (D8.1 §4; see Secure messaging and identity stack).
- Ledger: only the Smart Contracts Toolkit writes to the MaaS Blockchain (D8.1 §6.5; see Smart contract origination).
- Least privilege and data sovereignty: access respects the data owner’s control. In the first release this is realised through topic-level authorisation on the secure messaging broker (D8.1 §4), row-level security in EDGE Data Storage (D8.1 §3), and owner-only management of organisation content in CMM (D5.2).