Skip to content

Usage Viewpoint

This page summarises the usage viewpoint of MaaSAI deliverable D5.2 across the 23 MaaSAI solutions: who interacts with the solutions, in which roles, and within which limits. The detailed roles of each solution are on the individual solution pages (see Per-Solution Details). For the business frame (features, business processes and stakeholder groups), see the Business Viewpoint. For the architectural foundations, see the Architecture Overview.

MaaSAI describes its architecture through the four IIRA viewpoints (Business, Usage, Functional and Implementation). The viewpoints are layered, so choices made in the business viewpoint set requirements for the usage viewpoint, which in turn constrains the functional viewpoint. The usage viewpoint explains how the system works in practice (D5.1, §4.1; D5.2, §1).

  • Key concepts (D5.1). D5.1 Figure 57 relates the system, the parties that use it, their roles, the activities they carry out, the tasks that make up each activity, and the functional and implementation components behind each task. An activity is a series of tasks that together use a solution; triggers start the tasks and effects describe the changes in the system once they are completed.
  • Users as stakeholders (D5.2). “In the MaaSAI usage model, users are considered stakeholders of each solution.” For each solution, D5.2 defines roles that assign responsibilities and actions to these stakeholders: “Typical roles include MaaS Providers, MaaS Consumers, and System Administrators, each with differentiated permissions and capabilities within the platform.”
  • Content per solution (D5.2). For each solution, D5.2 provides a roles table (responsibilities, permissions and constraints of each role), a role-task matrix linking roles to the tasks they perform, and a use-case diagram.
  • Human and system parties. Roles cover both human users and system participants, such as other MaaSAI solutions, external systems and autonomous agents.

D5.2 presents the 23 solutions in 21 usage sections: the MaaS Consumer Planner and MaaS Provider Planner share one section, and the MaaS Blockchain and Smart Contracts Toolkit share the “MaaS Blockchain & Smart Contract” section.

Source: MaaSAI deliverables D5.1, §4.1 and Figure 57; D5.2, §3.

Role names are defined per solution, so similar roles can carry different names in different solutions. The table groups the actors and system roles named in the D5.2 usage sections and shows where each one appears.

Actor / roleDescriptionSolutions
MaaS Provider (MaaS Provider Admin in CMM)Organisation offering manufacturing resources, and the users acting on its behalf. Publishes and describes resources, services and offers, negotiates with consumers on order requests, shares collaboration workspaces with consumers and, in MWC, launches and approves workspace configurations.CMM, MDC, RS, MCH, MWC
MaaS Consumer (MaaS Consumer Admin in CMM)Organisation seeking manufacturing resources, and the users acting on its behalf. Starts order requests, specifies manufacturing requirements, searches for services, reviews and selects recommendations, accepts or declines offers and takes part in collaboration workspaces.CMM, MDC, RS, MCH
CMM OperatorMonitors and manages the administrative operation of the marketplace, supports all users and answers their requests, such as organisation validation, provider approval and approval of published resources.CMM
Administrator (Admin, Administrator, System Administrator, SysAdmin, System Admin or a solution-specific name)Manages the users, roles and permissions of a solution and, depending on the solution, its configuration or deployment: for example, installing and updating the agents (MCA, MPA), approving registrations and services (MDC), configuring scheduling policies (MCP, MPP), maintaining datasets (LCT) or configuring integration flows (DI, as Integration administrator).MCH, MDC, CP, DA, RMC, MCA, MPA, LCT, MWC, MCP, MPP, SCS, PMT, R3T, DI, DS, MSB, SCT, PSM
User / Regular UserOperational user working within a limited scope: viewing dashboards (CP, RMC), creating analytics workflows and managing datasets (DA), creating and editing own production orders (MCP, MPP), building models and running simulations (SCS), running algorithms and managing own results (R3T), or viewing and completing own blockchain transactions (MSB, SCT).CP, DA, RMC, MCP, MPP, SCS, R3T, MSB, SCT
Power User / Dashboard CreatorUser with extended rights within a solution: adding custom operators (DA), managing the transaction flow (MSB, SCT), or adding data sources and building dashboards (CP).DA, MSB, SCT, CP
Consumer Power User / Provider Power UserAdvanced user of the consumer or provider organisation who defines negotiation policies and thresholds, manages the agent’s knowledge base and access credentials, and reviews negotiation explainability reports. D5.2 notes that this user “has the ability to intervene in the negotiation process, adjust negotiation parameters”.MCA, MPA
Consumer Analyst / Provider AnalystRequests and reviews negotiation explainability reports, consults performance and statistics, and exports negotiation reports, without configuration rights.MCA, MPA
Consumer Agent / Provider AgentSystem role: an autonomous digital actor that negotiates on behalf of the MaaS Consumer or the MaaS Provider. The Consumer Agent discovers and evaluates providers and initiates negotiations; the Provider Agent evaluates the proposals it receives and accepts or rejects them according to the defined policies.MCA, MPA
Cloud MaaS Marketplace and Recommendation System (as system roles)In the RS usage model, the CMM provides the interface for providers and consumers, forwards consumer requirements to the RS and displays the recommendations; the RS generates recommendations and refines its algorithms using consumer feedback.RS
Asset designer, Manufacturing line designer, Simulator, Optimizer, Digital Twin DesignerDesign roles that define assets and manufacturing lines, define and run simulations, and launch optimisations; the Digital Twin Designer role holds the permissions of the other four.DTD
LCA Analyst, LCI Data Provider (Pilot)The LCA Analyst creates, edits and shares studies and generates dashboards and reports; the LCI Data Provider fills out life cycle inventory data in templates for the studies shared with it.LCT
MWC AgentSystem role: a software agent that retrieves bookings, queries the digital twin for resource availability and runs the configuration optimisation; it operates via APIs only.MWC
Super Administrator, User Administrator, User SharedGraded simulator roles: the Super Administrator manages base and custom libraries, builds models and runs simulations; the User Administrator manages custom libraries only; the User Shared contributes to an assigned section of a shared model, with other users’ contributions hidden as black boxes.SCS
Maintenance technician, Maintenance managerThe technician executes the maintenance tasks generated by the toolkit and reports the results; the manager analyses machine status and alerts, accepts or dismisses them and assigns tasks to technicians.PMT
External system, External system managerThe external system (a system role) provides production schedule and execution data and receives updates from MaaSAI; the external system manager supports the connection and checks synchronisation between MaaSAI and the external system.DI
User (Decision-maker), Data Sources, MaaS Ontology, Other MaaSAI Solutions, DIPThe decision-maker explores and queries passport information. The other roles are system roles that supply data (Data Sources, Other MaaSAI Solutions), provide harmonised data structure definitions (MaaS Ontology), or gather, harmonise and maintain the passports (the DIP itself).DIP
Retrieve DB, Storage DB, Sys Admin DBDatabase privilege roles: querying data; storing and retrieving data and managing tables; managing users in addition to data access.DS
Message Sender, Message ReceiverSend messages to the assigned topics; read messages from the available topics.PSM
ADMIN, CLIENT, PROVIDER (on-chain roles, D12.1)D12.1 reports an on-chain role-based access control for the Smart Contracts Toolkit with three roles, each with distinct permissions over sensitive contract functions; the ADMIN role is used for privileged contract operations.SCT

Source: MaaSAI deliverable D5.2, §3 (role tables of each solution); on-chain roles from D12.1, §6.

D5.1 (§3.1.1) also lists further organisation roles in the Cloud MaaS Marketplace environment: Solution Developer, Suite Provider, Service Expert and Broker (for example, an EDIH or a professional or industrial cluster).

Although each solution defines its own roles, the D5.2 role tables follow a recurring pattern. The grouping below is a cross-solution reading of those tables; the examples use the D5.2 role names.

Role typeExamples (D5.2)Typical scope and constraints (D5.2)
Organisation adminMaaS Provider Admin and MaaS Consumer Admin (CMM)Acts for its own organisation only and cannot manage the profiles, resources, order requests or users of other organisations.
Operational userUser (CP, MCP, MPP, SCS, R3T), Regular User (DA), Maintenance technician (PMT)Works within a limited scope, such as own orders, models or results, or view-only access. In the planners, the user “can only see orders of which it is the owner (principle of least privilege)”.
Power user or configuratorConsumer and Provider Power User (MCA, MPA), Power User (DA), Dashboard Creator (CP), Super Administrator and User Administrator (SCS)Configures policies, operators, dashboards or libraries within the solution. In the agents and in DA, this role cannot manage other users.
Autonomous agentConsumer Agent (MCA), Provider Agent (MPA), MWC Agent (MWC)Acts within limits set by human roles: the negotiation agents cannot edit negotiation policies, user administration, the knowledge base or access credentials, and the Power User can intervene in the negotiation. The MWC Agent operates via APIs only.
AdministratorPer-solution administrators; CMM Operator (CMM)Manages users, roles and permissions. Some solutions add stronger controls, such as multi-factor authentication for high-privilege operations and versioned, tracked configuration changes in the planners. In several solutions the administrator is kept apart from operational work: for example, the DA SysAdmin cannot create workflows, and the MDC Administrator cannot provide manufacturing services.
System roleCMM and RS (RS), External system (DI), Data Sources, MaaS Ontology and Other MaaSAI Solutions (DIP), database roles (DS)Non-human participants with defined data or API permissions; for example, the DI external system “needs authentication and must use supported protocols or data formats”.

Source: MaaSAI deliverable D5.2, §3 (role tables of each solution).

Each solution page lists its D5.2 roles in the Primary Actors section, with the use-case diagram where available.