Modeling with Arcadia

Arcadia is a model-based systems engineering method. It was created at Thales and is the method of Capella, the open-source modeling tool of the Eclipse Foundation. ArcLang follows Arcadia: its blocks are the levels of the method, and its element kinds are the Arcadia concepts.

This page explains the method level by level, with the home heating model of the tutorial as the example. For each level it gives the question the level answers, its main concepts, the names of the Capella diagrams of that level, and the ArcLang block and view that match them.

The idea of the method

Arcadia describes a system at five levels, from the need to the delivered product. Each level answers one question, and the method asks you to answer them in order:

Two principles run through all five:

• Functions and structure are separate. Each level has its own functions (what is done) and its own structure (who does it). A function is allocated to the structural element that performs it.
• Each level realizes the one above. A system function realizes an operational activity; a logical function realizes a system function; and so on. These realization links make every element traceable to the need.

Requirements are not a level of their own: they sit beside the levels and are linked to them by traces.

Operational analysis

Question: what do the users and the systems around them need to accomplish, whatever the solution?

The operational analysis describes the world before the system exists. Operational actors are people; operational entities are organizations or existing systems. They perform operational activities, which exchange interactions. An operational capability is what they achieve together, and an operational process is an ordered path through activities.

For the heating system: the Occupant (an actor) and the Home (an entity) take a wished temperature and keep the rooms warm.

System analysis

Question: what must the system do for its users, seen from the outside as a black box?

The system analysis draws the boundary. The system is one box, the actors are around it, and the system functions say what the system must do. Functions have input and output ports, linked by functional exchanges. Missions are high-level goals; capabilities are what the system can do to serve them. A functional chain is an ordered path through functions, often with a latency budget.

For the heating system: measure the room temperature, take the set temperature, decide the heating demand, drive the burner; the chain Reading to burner must take at most 2 s.

Logical architecture

Question: how will the system work inside, without choosing technology yet?

The logical architecture opens the box. Logical components split the system; each performs logical functions that realize the system functions. Components are linked by component exchanges through their ports, and can provide or require interfaces. This is where architecture trade-offs are made: which component does what, and what passes between them.

For the heating system: a Thermostat, a Heating controller and a Burner unit.

In ArcLang, a function written inside a component is allocated to it, and realizes: names the system function it realizes:

system_analysis "System Analysis" {
  function "Decide the heating demand" { id: "SF-DECIDE" }
}

logical_architecture "Logical Architecture" {
  component "Heating controller" {
    id: "LC-CTRL"
    function "Compute the demand" { id: "LF-DECIDE" realizes: "SF-DECIDE" }
  }
}

Physical architecture

Question: how will the system be built, with what hardware and software?

The physical architecture chooses the technology. Nodes (Capella's node physical components) are hardware: boards, computers, devices. Behavior components are the software or logic that runs on them, and perform physical functions. Nodes are connected by physical links (cables, buses, radio). In ArcLang, a node deploys the logical components it hosts, and a behavior_component written inside a node is deployed on it.

For the heating system: a Wall thermostat and a Boiler control board, linked by a radio link.

End product breakdown structure

Question: what exactly is delivered, bought or manufactured?

The EPBS lists the products: systems, subsystems and configuration items, each with a part number and a supplier if needed. A configuration item realizes the physical elements it contains.

Here is the EPBS of the heating system, added to the tutorial model with an import:

import "heating.arc"

epbs "EPBS" {
  system "Home heating kit" {
    id: "EPBS-KIT"
    subsystem "Controls" {
      id: "EPBS-CONTROLS"
      item "Wall thermostat" { id: "EPBS-THERMO" part_number: "TH-200" }
      item "Boiler control board" { id: "EPBS-BOARD" part_number: "BC-10" }
    }
  }
}

trace "EPBS-THERMO" realizes "PN-WALL"
trace "EPBS-BOARD" realizes "PN-BOARD"

Transverse diagrams

Some Capella diagrams belong to no single level. ArcLang has the same concepts:

Draw every view

arclang diagram draws every view the model has, in one HTML file that needs no network:

$ arclang diagram heating_epbs.arc -f html -o heating.html
✓ oab — 4 nodes, 2 edges
✓ sab — 6 nodes, 3 edges
✓ lab — 7 nodes, 2 edges
✓ pab — 5 nodes, 1 edges
✓ cap — 10 nodes, 9 edges
✓ pbs — 4 nodes, 3 edges
✓ req — 9 nodes, 6 edges
✓ par — 9 nodes, 4 edges
✓ gv — 14 nodes, 5 edges
✓ iv:Operational Analysis — 2 nodes, 0 edges
✓ afv:System Analysis — 8 nodes, 5 edges
✓ iv:Logical Architecture — 3 nodes, 2 edges
✓ iv:Physical Architecture — 2 nodes, 1 edges
  Output: heating.html

The view codes in the output are the ones used in the tables above. A diagram declaration names a subset of a view, as a Capella user names a diagram: see Diagrams. In the workbench, each view has its palette, and each level of the layer bar opens the sheet of that level.

Traces between levels

Arcadia realizations become realizes traces in ArcLang (or the realizes: attribute of a function or capability). A realization goes from a lower level to the level above it: SA to OA, LA to SA, PA to LA, EPBS to PA. Both ends must exist, or the build stops. The other trace kinds (satisfies, implements, allocates, refines, derives, validates) link the architecture to requirements and to tests. The metamodel lists which elements each kind may link.

Exchange with Capella

ArcLang reads and writes Capella projects: arclang import -f capella reads a Capella 6 or 7 project with its diagrams, and arclang export -f capella writes the .capella, .aird and .afm files of a Capella 7 project.

arclang import -f capella "My model.capella" -o my_model.arc
arclang export -f capella my_model.arc -o out/my_model.capella

The Capella page says what each direction carries, what it leaves out, and how the round trip keeps Capella's identifiers.

Next

• Model the same system with the concepts of the SysML v2 standard.
• The language tour gives the syntax of every Arcadia concept, level by level.