Module 7: MagicGrid

MagicGrid was developed by No Magic (now part of Dassault Systèmes) as a practical, prescriptive MBSE methodology. Unlike academic frameworks that describe principles in the abstract, MagicGrid was designed from the outset to be directly usable — providing a clear, step-by-step recipe for populating an MBSE model.

The methodology emerged from years of consulting experience with Cameo Systems Modeler and was first documented publicly in the MBSE Grid-Based Approach technical paper by No Magic. Its goal was to answer a deceptively simple question: "I have a modelling tool open — what do I model first, and where does each diagram go?"

Design philosophy

MagicGrid rests on two organising principles:

• Abstraction levels — separate what the system must do (problem) from how it does it (solution) and what it is built from (implementation).
• Concern columns — separate requirements, structure, behaviour, and parametrics so each aspect of the system has a dedicated home.

The intersection of a row (abstraction level) and a column (concern) tells you exactly which SysML diagrams and model elements to create. This makes MagicGrid highly approachable for teams new to MBSE.

The core of MagicGrid is a 3 × 4 matrix. Rows represent abstraction levels; columns represent engineering concerns. Every model element you create has a well-defined "address" inside this grid.

Rows — abstraction levels

• Problem Domain (Black Box) — the system is an opaque box; we define external interactions without revealing internals.
• Solution Domain (White Box) — we open the box and describe the logical internal architecture.
• Implementation — we map the logical architecture to physical components, hardware, software, and services.

Columns — engineering concerns

• Requirements — what the system must do or satisfy.
• Structure — what the system is made of (parts, connections, interfaces).
• Behaviour — how the system behaves over time (activities, states, interactions).
• Parametrics — quantitative constraints, equations, and measures of effectiveness.

The 3 × 4 grid at a glance

Table 1 — The MagicGrid 3 × 4 matrix with example artifacts

The grid is typically worked through top-to-bottom (from problem domain down to implementation) and roughly left-to-right within each row, though iteration across cells is expected and encouraged.

In the problem domain row, the system is treated as an opaque box. We define what it must do without deciding how. This forces the engineering team to fully understand the problem before jumping to solutions.

Running example: EV Charging Station

Throughout this module, we will use an EV charging station as a running example. This is a system that charges electric vehicles, processes payments, communicates with the electricity grid, and provides status information to station owners.

Stakeholders

The first step in the problem domain is identifying who interacts with the system and who has an interest in it:

• EV Driver — the primary user who charges their vehicle and pays for the service.
• Grid Operator — the electricity provider who supplies power and needs load management data.
• Station Owner — the business entity that owns and operates the charging infrastructure, interested in uptime, revenue, and maintenance.

Use cases

Use cases capture the externally visible functions of the system:

• Charge Vehicle — the primary function; the driver plugs in and the station delivers energy.
• Monitor Status — the station owner (or an automated system) checks real-time status — availability, fault conditions, energy delivered.
• Process Payment — the system handles contactless payment, authorisation, and transaction logging.

System context

A system context diagram at this level shows the EV charging station as a single block, surrounded by its actors (EV Driver, Grid Operator, Station Owner) and external systems (payment gateway, electricity grid, cloud monitoring platform). All interfaces are external — we do not yet show what is inside the station.

Measures of effectiveness

Parametrics in the problem domain capture high-level performance targets:

• Charging power: 50–350 kW (DC fast charging)
• Payment processing time: < 3 seconds
• System availability: ≥ 99.5%
• Mean time to repair: ≤ 4 hours

Having defined what the system must do, we now open the box and describe how it achieves those goals. The solution domain introduces the logical architecture — subsystems, internal interfaces, state machines, and detailed behaviour.

Logical decomposition

For our EV charging station, the logical subsystems include:

• Charging Controller — manages the charging protocol (CCS, CHAdeMO, or AC Type 2), controls power delivery, and handles safety interlocks.
• Payment Processor — handles NFC card reading, online authorisation, and transaction recording.
• Energy Management — communicates with the grid operator for load balancing, monitors power draw, and implements smart charging schedules.
• User Interface — the display and physical controls that guide the driver through the charging session — plug-in instructions, charging progress, and receipts.

Internal structure

An internal block diagram at this level shows how the four subsystems connect. The Charging Controller exchanges power commands with Energy Management; the Payment Processor sends authorisation status to the Charging Controller (charging only begins after payment is confirmed); and the User Interface communicates with all other subsystems to display status.

Behaviour modelling

State machines describe the lifecycle of a charging session: Idle → Authenticating → Charging → Complete → Idle, with fault transitions from any state to a Faulted state. Activity diagrams detail the sequence of internal operations within each state transition.

Constraint blocks

Parametric constraints at the solution level express engineering trade-offs. For example, a constraint block might relate charging power, cable temperature, and session duration to ensure that thermal limits are never exceeded.

The implementation row bridges the gap between the logical architecture and the real world. Here, logical subsystems are allocated to physical components, and interface specifications become concrete.

From logical to physical

The allocation from solution-domain subsystems to implementation-domain components for our EV charging station:

• Charging Controller → a dedicated embedded ECU (e.g., ARM Cortex-based industrial controller) running real-time firmware that implements the CCS/CHAdeMO protocol stack.
• Payment Processor → a combination of an NFC card reader (physical hardware at the station) and a cloud payment service (remote software) connected via 4G/5G.
• Energy Management → a smart meter and power electronics module at the station, communicating via OCPP (Open Charge Point Protocol) with a cloud-based energy management platform.
• User Interface → a ruggedised touchscreen display, LED status indicators, and an optional mobile app companion.

Interface specifications

At the implementation level, interfaces become concrete protocols and physical connectors:

• Charging Controller ↔ Energy Management: CAN bus (physical), OCPP 2.0.1 (application layer)
• Payment Processor ↔ Cloud Service: HTTPS/TLS over 4G, ISO 8583 message format
• User Interface ↔ Charging Controller: internal Ethernet, MQTT for status updates

Verification constraints

Parametric constraints at this level map directly to test procedures. For example: "The NFC reader shall complete a contactless transaction in under 500 ms" is a testable constraint allocated to the Payment Processor hardware.

Module 6 introduced OOSEM (Object-Oriented Systems Engineering Method). Both OOSEM and MagicGrid are widely used MBSE frameworks, but they differ in philosophy, organisation, and emphasis. The table below compares them across six dimensions.

Table 2 — MagicGrid vs. OOSEM comparison

In practice, the two frameworks are not mutually exclusive. Many organisations adopt MagicGrid's model organisation (the 3×4 grid) while following OOSEM's process steps within each cell. The key is to choose the approach — or combination — that best fits your team's maturity and project context.