Architecture Decisions

Architecture decisions record choices that constrain several MaaSAI solutions at once: the platforms they build on, the protocols they share, and the way they hand work to each other. This page summarises the main architecture decisions documented in the deliverables, with the reason behind each one and the deliverables that document it.

Note

The decisions follow the MaaSAI deliverables. Where the design deliverables (D5.1, D5.2) and the M20 implementation deliverables (D6.1, D8.1, D10.1, D12.1) differ, the implementation deliverables take precedence.

Summary

Decision	Main solutions affected
Blockchain platform	MSB, SCT
Reference architectures for the twin and edge layers	DTD, PMT, MWC, SCS, DS, RMC
Secure messaging and identity stack	PSM, MCA, MPA
EDGE Data Storage technology	DS and the solutions that read from or write to it
Smart contract origination	CMM, MCA, MPA, SCT, MSB

Decisions

Blockchain Platform

• Decision: The MaaS Blockchain runs on Hyperledger Besu, a permissioned Ethereum client with Proof of Authority consensus, executing Solidity smart contracts on the Ethereum Virtual Machine (EVM) and exposing the Ethereum JSON-RPC over HTTPS, with BlockScout as block explorer. Only the Smart Contracts Toolkit submits transactions to the ledger.
• Main reason: The deliverables converge on this platform. D5.1 calls for a private Ethereum network with internal validation, D5.2 names Hyperledger Besu with Proof of Authority, and D8.1 reports the network built and validated with transactions submitted by SCT. D8.1 gives compatibility with the EVM and Solidity tooling of SCT as a primary selection criterion.
• Solutions affected: MaaS Blockchain (MSB), Smart Contracts Toolkit (SCT).
• Documented in: D5.1 §3.2–3.3; D5.2 §5; D8.1 §6.3–6.5; D12.1 §6.3.

Reference Architectures for the Twin and Edge Layers

• Decision: The Digital Twin Consortium Platform Stack and OpenFog are adopted as complementary reference architectures, next to IIRA (primary), RAMI 4.0 and IDS-RA. The Cloud, Fog and Edge tiers of D5.1 Figure 54 follow the OpenFog layering, and the Digital Twin Consortium Platform Stack serves as a design reference for the digital twin layer rather than as a conformance obligation.
• Main reason: D5.1 profiles both frameworks and states that MaaSAI adopts them together with IIRA, RAMI 4.0 and IDS-RA, and the D5.1 functional architecture is drawn on Cloud, Fog and Edge tiers. Limiting the adoption to the tier model and a design reference matches how D5.1 uses them.
• Solutions affected: Digital Twins Designer (DTD) and the solutions that consume twin states, Predictive Maintenance Toolkit (PMT), MaaS Workspace Configurator (MWC) and MaaS Supply Chain Simulator (SCS), together with EDGE Data Storage (DS) and Remote Monitoring and Control (RMC). The tier model is used for the deployment view of all solutions.
• Documented in: D5.1 §2.2, §2.4 and §3.4. See also Architecture Overview.

Secure Messaging and Identity Stack

• Decision: Point-to-Point Secure Messaging uses MQTT on an Eclipse Mosquitto 2 broker, with mutual TLS for client authentication and transport encryption, and Keycloak (OpenID Connect, JWT) for identity and access management. The broker validates the Keycloak token presented by each client, and topic-level authorisation follows the roles assigned in Keycloak.
• Main reason: D8.1 reports this stack implemented and validated in the laboratory, including tests of allowed and denied access. It follows the MQTT and token-based design already described in D5.1 and D5.2, and the secure negotiation module of the autonomous agents runs over the same broker (D6.1).
• Solutions affected: Point-to-Point Secure Messaging (PSM), MaaS Consumer Agent (MCA), MaaS Provider Agent (MPA).
• Documented in: D5.1 §3.3; D5.2 §5; D6.1 §5.2–5.3; D8.1 §4.3–4.6.

EDGE Data Storage Technology

• Decision: EDGE Data Storage is built on PostgreSQL with PostgREST, which exposes a REST endpoint for each table of an ISA-95-based data model. Access is controlled with JWT authorisation and PostgreSQL row-level security, and the solution is packaged with Docker Compose.
• Main reason: D8.1 reports this implementation working with the Data Integrator, Remote Monitoring and Control and the planners; D10.1 confirms the data exchange with RMC, and D12.1 describes the planners reading and writing through PostgREST. The earlier design described in D5.2 was based on MySQL.
• Solutions affected: EDGE Data Storage (DS), and the solutions that read from or write to it: Data Integrator (DI), MaaS Consumer Planner (MCP), MaaS Provider Planner (MPP), Remote Monitoring and Control (RMC), Predictive Maintenance Toolkit (PMT) (intended) and Digital Industrial Passport Designer (DIP).
• Documented in: D8.1 §3.1–3.6; D10.1 §5.6.1; D12.1 §2.2–2.3.

Smart Contract Origination

• Decision: The autonomous agents negotiate over the secure messaging broker and hand the agreed terms to the Cloud MaaS Marketplace, which originates the contract by sending the finalised agreement to the Smart Contracts Toolkit as a business event through its webhook. SCT creates and executes the smart contract through its lifecycle (agreement approval, production updates, quality checkpoints and completion) and is the only component that writes contracts to the MaaS Blockchain.
• Main reason: D12.1 designs SCT to receive finalised agreements from CMM through its business-event webhook and to propagate them to MSB, and in D6.1 CMM starts each negotiation and collects its decision. The resulting path has a single originator (CMM) and a single contract writer (SCT). D8.1 (Table 1) describes the WP6 agents as relying on the MSB to anchor finalised contracts; D8.1 §6.5 and D12.1 §6 place all transaction submission in the SCT, which this decision follows.
• Solutions affected: Cloud MaaS Marketplace (CMM), MaaS Consumer Agent (MCA), MaaS Provider Agent (MPA), Smart Contracts Toolkit (SCT), MaaS Blockchain (MSB).
• Documented in: D6.1 §2.1 and §5.2–5.5; D8.1 §6.5; D12.1 §6.1–6.4. See also the Integration Map.