arcadia-mbse

name

arcadia-mbse

description

Use when designing, building, auditing, or reviewing ARCADIA models or Eclipse Capella projects (.aird/.capella files) across the Operational Analysis, System Analysis, Logical Architecture, Physical Architecture, and EPBS perspectives; when producing or critiquing functions and functional exchanges, functional chains, scenarios, modes and states, data and exchange-item models, viewpoints, allocation legality, diagram kinds and acronyms, Capella validation rules, or cross-level realization traceability; or whenever the user mentions ARCADIA, Capella, MBSE architecture layers, capabilities, actors, or operational/system/logical/physical analysis.

ARCADIA MBSE

Overview

ARCADIA (ARChitecture Analysis and Design Integrated Approach) is a model-based systems engineering method and a domain-specific modeling language, created at Thales (principal author Jean-Luc Voirin). Its reference tool is the open-source Eclipse Capella workbench. Always keep the distinction sharp: ARCADIA is the method; Capella is the tool that implements it. This skill is methodology-first and Capella-aware — the guidance holds in any tool, and Capella-specific facts are marked as such.

Use this skill for two kinds of work, equally:

• Design / authoring — building a model top-down across the ARCADIA perspectives.
• Review / audit — checking an existing model for completeness, consistency, allocation legality, traceability, and methodological correctness.

The five perspectives

ARCADIA structures engineering into five perspectives. The first two capture the need (problem space); the next two define the solution; EPBS is the contractual layer.

Perspective	Need/Solution	Question it answers	Core elements
Operational Analysis (OA)	Need	What the users must accomplish (no system yet)	Operational Entities/Actors, Activities, Capabilities, Interactions, processes/scenarios
System Analysis (SA) — a.k.a. System Need Analysis	Need	What the system must do for users (black box)	System, Actors, System Functions, Functional Exchanges, Capabilities, functional chains, modes/states
Logical Architecture (LA)	Solution (notional)	How the system works to meet expectations (technology-independent)	Logical Components, allocated Logical Functions, Component Exchanges, interfaces — built by multi-viewpoint trade-off
Physical Architecture (PA)	Solution (final)	How the system is built (technology-bound)	Behavioural vs Node Physical Components, deployment, Physical Links/Paths
EPBS (End-Product Breakdown Structure)	Contract	What to procure, develop, integrate	Configuration Items, component integration contracts, IVVQ strategy

Top-down flow: OA to SA to LA to PA to EPBS, connected by realization/justification links created at each transition. OA, LA, and EPBS are methodologically optional depending on system complexity; SA and PA are load-bearing. Read references/fundamentals.md for history, principles, and positioning vs SysML/UML/NAF.

Quick start by task

Most requests are one of these four. Follow the playbook, loading only the files it names.

1. "Review / audit this model" (with or without a .capella file): read references/review-checklists.md; if a .capella file exists, run scripts/extract_realization_links.py -> scripts/traceability_audit.py and scripts/allocation_audit.py (recipe: references/capella-tooling.md); report with assets/review-report-template.md. Worked end-to-end example with expected output: assets/worked-example.md.
2. "Design / model a system": follow the Design workflow below with the per-level reference file; capture output in assets/model-capture-templates.md tables (filled example: assets/worked-example.md); sketch diagrams per references/diagrams-as-code.md.
3. "Explain this diagram / acronym / concept": references/glossary.md first (diagram catalogue + terms); deeper theory in references/fundamentals.md or the topic file from the routing table below.
4. "Check / build traceability": references/viewpoints-and-traceability.md for the semantics, then the same script pipeline as playbook 1; matrices in assets/traceability-matrix-template.md.

A ready-made sample project for smoke-testing any of this lives in assets/sample-model/ (see assets/worked-example.md).

How to use this skill

Start here, then load only the reference files relevant to the task. Do not read all references at once — they are deep and topic-scoped.

If the task involves…	Read
First principles, history, when/why to use ARCADIA	references/fundamentals.md
Modeling/reviewing a specific level	references/operational-analysis.md, references/system-analysis.md, references/logical-architecture.md, references/physical-architecture.md (incl. EPBS)
Functions, functional exchanges, ports, functional chains, scenarios	references/functional-modeling.md
Modes & states, the data/information model, exchange items, interfaces	references/modes-states-and-data.md
Viewpoints, realization links, transitions, requirements/ReqIF, REC/RPL reuse	references/viewpoints-and-traceability.md
Allocation legality (function to component to exchange to link) across levels	references/allocation-rules.md
Eclipse Capella tool facts: files, diagrams, validation engine, add-ons, version differences	references/capella-tooling.md
Scripting against a model with py-capellambse (verified snippets)	references/py-capellambse-cheatsheet.md
Reviewing/auditing a model	references/review-checklists.md
Drawing ARCADIA diagrams as Mermaid/PlantUML	references/diagrams-as-code.md
Exact terminology and the full diagram-acronym catalogue	references/glossary.md
Authoritative online sources to cite or verify against	references/sources.md

Output artifacts this skill supports (templates in assets/):

• Structured model content -> assets/model-capture-templates.md
• Diagrams-as-code -> references/diagrams-as-code.md
• Review reports -> assets/review-report-template.md
• Traceability matrices -> assets/traceability-matrix-template.md; audit a links table with scripts/traceability_audit.py (CSV schema in assets/traceability-links-template.csv).
• Auditing an actual .capella file -> extract its realization links straight into that CSV with scripts/extract_realization_links.py (stdlib-only, no Capella install), then run the audit script on the result; check function-allocation legality headlessly with scripts/allocation_audit.py. Recipe in references/capella-tooling.md.
• Sample project + worked example -> assets/sample-model/ (loadable Capella 7.0 project: all five perspectives incl. functional exchanges, chains, component exchanges, physical links, modes, and four seeded findings) and assets/worked-example.md (filled capture tables, real audit output, review-report rows).

Core mental model (the non-negotiables)

These principles govern every ARCADIA decision. Internalize them before designing or reviewing.

1. Separate need from solution. OA/SA describe the problem and the expected behaviour; LA/PA describe the chosen solution. Never let system, component, or technology choices leak upstream (no system in OA; no technology in LA). This is the single most common — and most damaging — mistake.
2. Functional analysis is the backbone. Architecture is built from and justified against functions and functional exchanges, not from text requirements alone. The same triad — functions, exchanges, threads (chains/scenarios) — recurs at every level with level-specific names (Operational Activity, then System / Logical / Physical Function).
3. Allocate behaviour to structure via leaf functions. Only leaf (non-decomposed) functions own ports and exchanges and are allocated to exactly one behavioural component (system, actor, or logical/physical component). A function crossing a component boundary needs a Component Exchange realizing it. See references/allocation-rules.md.
4. Trace across levels by realization, not copy-paste. Each downstream element realizes the upstream element it elaborates ([Realizing X] / [Realized X]). Levels are usually not 1:1 refinements; connect them with links and maintain them. Broken traceability breaks impact analysis and V&V.
5. Drive the solution with viewpoints. The LA/PA component breakdown must be a justified multi-viewpoint compromise (safety, performance, cost, security, reuse, IVVQ…), not gut feel.
6. The model is the truth, not the diagram. Capella diagrams are views of one semantic model. Reason from the model (Semantic Browser, queries, validation), never from a diagram's appearance alone.

Design workflow (top-down)

For each level, run this loop; expand with the per-level reference file.

1. Operational Analysis (if the need is not already well understood): model Operational Entities/Actors, Capabilities, Activities and their Interactions; illustrate each capability with an operational process/scenario. Keep it solution-free. (references/operational-analysis.md)
2. System Analysis: introduce the System as a black box and its external Actors; derive System Functions and Functional Exchanges from activities and capability gaps; allocate functions to System vs Actors; define functional chains, scenarios, modes/states, and the data model; consolidate system requirements. (references/system-analysis.md)
3. Logical Architecture: define architecture drivers and viewpoints; refine functions; build candidate component breakdowns by grouping/segregating functions per viewpoint; select the best compromise; allocate functions to logical components; derive component exchanges and interfaces from the functional analysis. Stay technology-independent. (references/logical-architecture.md)
4. Physical Architecture: refine into Physical Functions (adding technical functions); introduce Behavioural components (carry functions) and Node components (provide resources); deploy behavioural onto nodes; add Physical Links/Paths. (references/physical-architecture.md)
5. EPBS: derive Configuration Items from physical components (PC->CI), write component integration contracts, and prepare the IVVQ strategy. No new design here. (references/physical-architecture.md)

Use Capella Transitions to initialize each level and auto-create realization links; function allocation, node creation, and deployment remain manual. See references/viewpoints-and-traceability.md and references/capella-tooling.md.

Review workflow

Audit on two dimensions — passing tool validation does NOT prove methodological quality.

1. Methodological review (manual): need/solution separation respected per level; each level's intent honored; verb-named functions / noun-named components; leaf-only allocation; capability coverage by chains/scenarios; realization links present at the depth the engineering goal requires; modes vs states used correctly.
2. Tool-checkable review (Capella validation): run Model Validation; triage Errors before Warnings. Key categories: Integrity (I_*), Quality (Q_*), Design (split into Well-formedness DWF_*, Consistency DCON_*, Completeness DCOM_*, Coverage DCOV_*), Transition (consistency TC_*, justification TJ_*).

Produce findings using assets/review-report-template.md; work the per-perspective checklists and named anti-patterns in references/review-checklists.md; audit cross-level coverage with scripts/extract_realization_links.py (from a .capella file) piped into scripts/traceability_audit.py, and allocation legality with scripts/allocation_audit.py.

Critical accuracy rules (high-error facts — get these exactly right)

These are facts that are easy to state wrong. They were independently fact-checked against primary sources. The full glossary lives in references/glossary.md.

• Diagram acronyms. OAB = Operational Architecture Blank (NOT "Activity Breakdown" — that is OABD). SAB = System Architecture Blank (NOT "System Analysis Blank"). Data-flow diagrams use …DFB (SDFB/LDFB/PDFB; OA uses OAIB); breakdown diagrams use …BD with the type letter in the middle (SFBD, LFBD, LCBD, PFBD, PCBD).
• Capella Design-validation prefixes are DWF_, DCON_ (consistency — not "DCONS_"), DCOM_, DCOV_.
• Function allocation: only leaf functions allocate; each leaf allocates to exactly one component (rule DWF_DC_12, ERROR). Functions allocate to behavioural components only, never to Node/implementation components.
• Exchange Item communication mechanism has five values: UNSET (default), FLOW, EVENT, OPERATION, SHARED_DATA.
• Scenario message types: FS lifelines = Functions, messages = Functional Exchanges; ES lifelines = Components/Actors, messages = Functional or Component Exchanges; IS lifelines = Components/Actors, messages = Exchange Items allocated to Interfaces (not "interface operations", not Component Exchanges).
• Interfaces are defined by grouping Exchange Items and are allocated to behavioural component ports (a port/component provides or requires one or more interfaces) — not directly to component exchanges.
• Component Exchange realizes the functional exchanges between functions allocated to its source/target components; its Exchange Items are normally deduced from those functional exchanges (do not hand-specify them).
• EPBS: the PA->EPBS transition is PC->CI; the Configuration Item is the source of the Realization and the Physical Component is the target (the CI realizes the PC). EPBS consolidates component requirements/contracts; there is no mandatory "EPBS requirements must trace to PA requirements" rule.
• Modes vs States: a Mode is chosen/commanded (a design decision; transitions driven by functional events); a State is undergone/suffered (driven by external/environmental change events). They are kept separate — never nested in one another.
• REC/RPL: REC = Replicable Elements Collection (mnemonic "for Record"); RPL = Replica ("for Replay").
• Viewpoints are methodological recommendations ("should"), and at least one should be dedicated to Reuse and Product Policy — not a hard requirement.

Source grounding

All facts in this skill were researched from authoritative online sources (official Eclipse Capella documentation and source tree, mbse-capella.org, the Voirin/Bonnet/Exertier ARCADIA materials and Voirin's Arcadia User Guide, Roques' Capella book, INCOSE papers, and py-capellambse docs) and the most error-prone claims were independently verified. When a fact is version-sensitive (Capella rule IDs, menu names, add-on availability), verify against the target Capella version. Curated sources are in references/sources.md.