Arcadia's Four-Layer Architecture: How OA/SA/LA/PA Controls Rework Costs

Introduction: The Cost of Layer Confusion

When engineers discuss the same requirement from different architectural layers — system interface, component interaction, bus signal — they talk past each other. The root cause is a lack of standardized layering. The Arcadia method, developed by Thales and implemented in the Eclipse Capella tool, defines four strict layers (OA, SA, LA, PA) that create a shared coordinate system for architecture discussions, requirement definitions, and design changes.

01 Four Layers, Each Answering One Core Question

Arcadia splits system architecture into four perspectives, progressing top-down with bidirectional traceability:

OA — Operational Analysis : What mission must people and business organizations accomplish?

SA — System Analysis : As a black box, what capabilities must the system provide to its environment?

LA — Logical Architecture : As a white box, how do internal components collaborate?

PA — Physical Architecture : What concrete hardware and software realize the design?

Engineering domains often group OA/SA as the problem space (defining the problem) and LA/PA as the solution space (solving the problem). The critical boundary: the first two layers do not decompose the system internals; they only define external value.

02 What You Save and What You Lose by Jumping Straight to Physical Architecture

Many projects start by drawing domain controllers, cameras, and buses in a modeling tool, producing a physical architecture in days. This apparent efficiency hides massive risk: locking in a physical solution before the system direction is clear causes exponential rework cost later.

Architecture rework cost depends on two factors: impact scope and detection timing . A tiny top-level deviation amplifies down through layers:

SA boundary error → LA components over-split, missed, or mis-assigned

LA responsibility mismatch → PA hardware selection, harness architecture all shift

PA physical deviation → test cases, calibration data, compliance certification all redone

One top-level flaw can become dozens of bottom-level fixes by production. The cost to fix the same top-level issue at different stages:

Concept review: adjust requirements and boundaries, near-zero hardware cost

After logical architecture: re-split components, rebuild functional chains

After physical architecture freeze: redesign harnesses, molds, components

After volume production: field updates, maintenance, recall risk

Upper layers set direction; lower layers carry it. The more detailed the lower work, the higher the price of a top-level error.

Layered design is not about more documents; it is about controlling the propagation radius of errors : verify layer by layer, converge layer by layer, stabilize the top direction before investing in bottom implementation.

Skipping three layers and going straight to PA leaves four irreversible side-effects:

Solution locked by intuition : once “one domain controller + five cameras” is drawn, the team only tweaks details, never compares alternatives.

Constraints masquerading as requirements : compute limits force feature cuts, then hardware compromises are disguised as “the requirement was always that way.”

Missing architecture trade-off process : vendor selection becomes pure price comparison without professional argument for architectural fit.

Inability to pinpoint root cause : integration errors cannot be traced to missing requirements, logical misallocation, or physical selection faults.

03 OA: Forget the System, Define Only the Business Mission

OA’s core principle: do not think about system implementation; only reconstruct real business scenarios and human activities. No technical specs like “12 camera inputs, 200 TOPS” appear here.

Example: Highway driving assistance scenario. OA captures the complete business flow:

Before driving: driver sets cruise speed and navigation destination.

During driving: driver monitors road, hands on wheel.

System triggers takeover request: driver must manually take over within specified time.

After trip: vehicle data syncs to cloud platform.

Participants include driver, cloud platform, roadside equipment, regulatory platforms. The target system is a black-box tool in this scene, with zero internal structure.

Core OA modeling elements:

Operational Activities : concrete business actions of driver and external actors.

Operational Actors : all people, platforms, external devices in the scenario.

Operational Interactions : information and command exchanges among actors.

Operational Capabilities : mission-level capabilities the scenario must achieve.

Operational Scenarios : complete business loops linking all activities and interactions.

Typical OA mistake: injecting system functions and hardware specs before the business is clear — putting the cart before the horse.

04 SA: Translate Business Mission into System External Capabilities

SA’s sole subject is the entire target system as a black box (no internal decomposition). Its task: accept OA mission, define system boundary, external capabilities, external interfaces, and system-level constraints.

Key distinction in this article: Capability (SA layer) vs Function (LA layer) .

Capability: user-facing result contract describing the value the system delivers, with built-in scenario, performance, safety constraints, directly verifiable.

Function: internal execution action after decomposition, fine-grained processing logic serving only internal implementation.

Using an automated driving domain system as example:

Define system boundary : system responsibility ends at “output vehicle control commands”; brake calipers, steering motors are external devices. Unclear boundary invalidates all interfaces, requirements, and architecture.

Define system external capabilities (pure black box) :

Receive driver cruise and following-distance commands.

Receive sensor data from cameras, mmWave radar, lidar.

Output drive, brake, steer vehicle control commands.

Provide fault diagnosis, status alarms, and graceful degradation.

Report vehicle runtime data and status to cloud platform.