Functional, logical and physical architecture in MBSE: from functions to system architecture

Three views of one system

An architecture is easy to draw and hard to get right, because one drawing usually tries to say three different things at once: what the system does, how its work is grouped into coherent pieces, and what hardware and software will actually be built. Model-based systems engineering separates these into three views of the same system, linked by allocation:

Keeping the views apart is what lets a team change one without redrawing the others. If the battery supplier changes, the physical view changes and the functions stay put. If the customer adds a requirement, a function appears and the team can ask which logical element should own it before anyone argues about boxes. And if the team wants to compare two designs, it can hold the functional and logical views fixed and vary only the physical one, which is what makes the comparison fair.

ISO/IEC/IEEE 42010 calls this idea viewpoints and views: one architecture, described by several views, each answering the concerns of particular stakeholders. The three views here are the ones nearly every systems project needs.

A note on terminology

The words are not used the same way everywhere. Some texts call the functional architecture the logical architecture, because both are free of hardware; the functional analysis guide uses "logical view" in that broad sense. Others use "logical" only for the middle layer described here, the grouping of functions into technology-neutral elements. Many small projects skip the middle layer and allocate functions straight to physical subsystems. Any of these works if the project writes down which it uses and keeps functions, roles and part numbers out of the same diagram.

Where architecture fits in the life cycle

ISO/IEC/IEEE 15288 places this work in two technical processes. The architecture definition process (clause 6.4.4) develops candidate architectures, evaluates them, and selects one, expressed as a set of consistent views. The design definition process (clause 6.4.5) then gives each element enough detail to build or buy it. System requirements definition feeds both, and system analysis (6.4.6) supplies the numbers that decide between candidates.

The NASA Systems Engineering Handbook (NASA/SP-2016-6105 Rev 2) follows the same order under different names: logical decomposition (section 4.3) turns requirements into functional and behavioral models, and design solution definition (section 4.4) turns those into alternative physical designs and picks one. The INCOSE Systems Engineering Handbook describes the loops that tie them together: architecture work regularly sends the team back to the requirements, and design work back to the architecture.

In practice: functional architecture first, then the logical grouping, then one or more candidate physical architectures, each fully allocated so that its interfaces and budgets can be compared, then a trade study to pick one, and finally interface definition and component design.

The functional architecture

The functional architecture states what the system must do, with no commitment to how. Its building blocks are a function tree (one top-level function decomposed level by level), a flow for each parent function (sequence, parallel branches, alternatives and loops), and the items each function produces and consumes. Every function traces to the requirements it satisfies.

The functional analysis guide covers the method on the same CubeSat used below. For architecture work its key results are the lowest-level functions (the units that get allocated), the items between them (the raw material for interfaces) and the requirements on each function, which travel with it to whatever component performs it.

The logical architecture

A logical element is a responsibility that the system needs, stated without choosing the technology that will carry it. Energy Storage is a logical element; a lithium-ion battery pack, a supercapacitor bank and a flywheel are three physical ways to realize it. The logical architecture groups the functions into such elements and records what must pass between them.

Why add a layer between functions and parts? Three reasons:

• It stabilizes the design. Functions are fine-grained and parts are volatile. A handful of logical elements with clear responsibilities survives supplier changes and technology upgrades, so the requirements and interfaces written against them survive too.
• It frames the alternatives. A trade study compares physical candidates against the same logical elements. Without that common frame, two candidates often differ in what they do as well as in how, and the comparison is not fair.
• It separates "what goes together" from "what is bought together". Two logical elements can end up in one box (a flight computer that does both command processing and fault management) or one element can span several boxes (fault management split between software and a hardware trip circuit). Seeing that difference explicitly is the start of a good allocation decision.

To form logical elements, look at the N2 chart of the functions. Functions that exchange many items, share data, or must run at the same rate belong together; functions that exchange little can live apart. This is the cohesion and coupling rule familiar from software: strong ties inside an element, few ties between elements. Name each element after its responsibility, check that every function falls into exactly one element, and write a one-sentence purpose for each.

The physical architecture

The physical architecture names the real things: hardware assemblies, software items, people and facilities, organized as a breakdown from the system through segments and subsystems to components. Each component carries the attributes that design and budgets need (mass, power, data rate, cost) and is connected to others by physical interfaces: harnesses, buses, radio links, mechanical mounts, fluid lines.

Include external systems and the environment as context outside the system boundary, so that their interfaces can be listed too.

Allocation: from what to who

Allocation is the decision that a given element of one view is realized by a given element of the next. It runs as a chain:

requirement  -> satisfied by -> function
function     -> allocated to -> logical element
logical      -> allocated to -> physical component

When the logical layer is skipped, functions are allocated directly to physical components. Requirements and constraints that are not functions (mass, operating temperature, a mandated standard) are allocated straight to components or to the system, never forced into the function tree.

The rules

• Every lowest-level function is allocated. A function nobody performs is work the system will not do. Parent functions are covered through their children.
• Each lowest-level function has one owner. If two components must cooperate to perform a function, an interface is hiding inside it; decompose the function until each piece has one performer, and the interface between them becomes visible.
• Many functions to one component is normal. A flight computer schedules commands, stores data and runs fault management. Many-to-one allocation is how real hardware is used efficiently; check only that the component can carry the combined load (processing, memory, power, timing).
• One function to many components is a signal. At the lowest level it means the function is not decomposed far enough. At a parent level it is expected: a parent function is performed by the set of components that perform its children.
• Allocation is traceable both ways. From any component you can list the functions it performs and, through them, the requirements it must meet; from any requirement you can find the function and the component responsible. That is what makes change impact analysis possible (the requirements traceability guide shows how).

The usual way to review allocation is an allocation matrix: functions in the rows, components in the columns, a mark where a component performs a function. An empty row is an unallocated function; an empty column is a component that does nothing; a row with two marks at the lowest level is a shared function.

Interfaces follow from allocation

In the functional view, an item passes from one function to another. After allocation, the same item passes from the component that performs the first function to the component that performs the second. If those are different components, the item now crosses a physical boundary, and something has to carry it. That is where interfaces come from:

1. For each item exchanged between functions, look up the performer of the producing and of the consuming function.
2. If the performer is the same, the exchange is internal to that component; it is a design concern for the component's own team.
3. If the performers differ, the exchange needs a physical path between them: an existing interface that can carry it, or a new one.
4. Check each path's capacity against everything it carries, and give each interface an owner and a status.

This is also why allocation choices matter so much. Moving one function from one component to another can create interfaces, remove them, or move a heavy data flow onto a slower link. A good allocation keeps the heaviest and most frequent exchanges inside components and leaves simple, stable exchanges at the boundaries. Once the interfaces are found, the interface control document guide covers how to define and control them.

Architecture trade-offs

There is almost never only one reasonable physical architecture. Each candidate realizes the same logical elements differently, and the differences are what a trade study weighs:

• Integration versus separation. Putting several logical elements in one component saves mass, power and interfaces, but couples their failures and their schedules. Separating them isolates faults and suppliers at the cost of more interfaces.
• Hardware versus software. A function such as undervoltage protection can be a software rule on the flight computer, a hardware trip circuit in the power unit, or both. Each choice moves requirements, test effort and failure modes.
• Where the heavy flows go. High-rate data, high power and tight timing are expensive across boundaries. An allocation that puts the producer and consumer of a heavy flow in different components needs a capable interface between them.

Score the candidates against criteria derived from the requirements, with weights agreed before the scores are known, and test how far the weights can move before the winner changes. The trade study example works through that method on the same CubeSat, and the Monte Carlo guide shows how to treat uncertain inputs when the margins are small.

Worked example: the EO-1 power and data handling slices

The example is EO-1, a fictional 6U Earth observation CubeSat in a 500 km sun-synchronous orbit, the same system the other guides follow (the MBSE example project walks through the whole model). Two slices of it show the full chain from functions to components: the electrical power subsystem (EPS) and command and data handling (C&DH). Everything below is taken from the demo model as it ships, with one exception that is marked: the demo has no separate logical layer, so the logical elements L1 to L6 are written for this guide to show what that layer adds.

Download: EO-1 allocation chain for the EPS and C&DH (CSV): one row per EPS and C&DH function with its requirements, logical element, component, the items it exchanges with other components and the interfaces that carry them. Use it as a template for your own allocation table.

The physical architecture

The model's physical breakdown starts at 0 EO-1 Mission, with the spacecraft, the ground segment, the launch vehicle and the orbit environment below it. The spacecraft has six subsystems, and three of them are broken down into parts:

• 1.3 EPS holds 1.3.1 Solar Arrays (two deployable triple-junction panels), 1.3.2 Battery Pack (8-cell lithium-ion, 77 Wh) and 1.3.3 Power Distribution Unit (peak power tracking, 12 V regulation, switched load outputs).
• 1.4 C&DH is one unit: a flight computer with 64 GB of payload storage.
• The conduits are physical interfaces with numbers, such as IF-01 to IF-04 for the power lines from the EPS and IF-09 Power Telemetry Link, an I2C link between the power distribution unit and the flight computer.

A logical layer for the two slices

The demo goes straight from functions to subsystems and parts. Writing a logical layer for the two slices shows what the middle step adds. Six logical elements cover the functions involved (the numbers L1 to L6 are for this guide, not the demo):

The EPS side maps one-to-one: each logical element has its own part. The C&DH side does not: three logical elements share one flight computer. That is a legitimate design choice for a CubeSat, where a second processor costs mass, power and volume, but the logical layer makes it a visible choice rather than an accident. It also shows the alternatives a trade study could weigh: L5 in a separate mass memory unit, or part of L6 as a hardware undervoltage trip in the power distribution unit, which would serve requirement 4.3 (safe mode within 10 seconds of undervoltage detection) without depending on flight software.

The allocation, checked in a matrix

The model records each function's performer with a performed by link. An allocation matrix with the function tree of F0 Perform EO-1 Mission in the rows and the asset tree of the mission in the columns shows the whole allocation at once (columns that perform nothing are hidden):

Read the matrix against the rules:

• Every function is allocated. Each of the 18 functions has exactly one mark. The only empty row is F0, the top-level function, which is covered through its children.
• Parents go to subsystems, children go to parts. F3 Generate and Store Power is performed by the EPS, and its three sub-functions by the three EPS parts. Allocation is consistent across levels: each child's performer is part of the parent's performer.
• Many-to-one on the C&DH. The C&DH column has two marks in this tree, F8 and F10. Across the whole model it performs six actions, adding OPS.3 Load Command Schedule and OPS.7 Encode and Store Image from the operations scenario and two mode activities from the state machine. That is the L4 to L6 grouping above, made concrete.
• A subsystem doing a part's job. F4.2 Compute Control Torques is performed by 1.2 ADCS itself, while its siblings go to parts (star tracker, reaction wheels, magnetorquers). The ADCS has no controller part in the breakdown, although three part-level links (IF-16 to IF-18) end on the ADCS. Adding a part such as ADCS Controller and moving F4.2 and those link ends to it would make the breakdown say what the interfaces already imply.
• A function on the whole spacecraft. F5 Operate Imaging Orbits is performed by 1 EO-1 Spacecraft. That is right for a function that is really a repeating loop over other functions: no single subsystem owns it, and its requirements (revisit time, mission lifetime) are system-level.

The matrix also exposes allocations that need a second look against the requirements. Requirement 4.4 Downlink Encryption, added after the requirements baseline, is satisfied by F8 Store Payload Data and the C&DH. Encrypting frames is a different transformation from storing them; a function such as Encrypt Downlink Frames under L5 would carry it more precisely and give the test team one place to look.

Interfaces that follow from the allocation

With every power function allocated to a part, the items between those functions show where the EPS needs physical paths. A Physical I/O Diagram of the EPS draws a line wherever a function performed by one part sends an item to a function performed by another:

Each line is a functional exchange that allocation turned into a physical one:

The internal block diagram of the EPS shows the same exchanges from the physical side: each connector between parts, its status and the items it conveys.

Three points stand out:

• Every functional exchange has a path. IF-20 and IF-21 exist because F3.1, F3.2 and F3.3 are on different parts. Had charge control been built into the battery pack, Battery Charge Power would be an exchange inside the pack, and IF-21 would carry unregulated bus power instead: the allocation decides what an interface carries.
• The slices meet at one interface. Apart from the C&DH power line, the only exchange between the EPS and C&DH slices is the telemetry and command loop of fault management. Because L6 Fault Management sits on the flight computer while the power data comes from the power distribution unit, IF-09 is on the critical path of requirement 4.3. It carries 0.01 Mbps of telemetry and 0.001 Mbps of commands on a 0.4 Mbps I2C link, ample margin, but its latency and its behavior when the flight computer is busy or resetting now belong in the ICD.
• The boundary is typed. IF-22 Regulated Bus ends at the EPS port 12 V Bus, typed by the 12 V Power Interface. Every subsystem that draws power connects to that one definition, so a change to the bus voltage or current limit is made in one place.

An open trade on the power slice

Allocation also puts the budgets in the right place. Requirement 3.1 asks the solar arrays to generate at least 30 W orbit-average power at end of life (it was 28 W until the orbit-average load grew to 26 W after the preliminary design review). TC-06 measured 75.1 W peak; at the model's 0.62 sunlit fraction and 0.6 power path efficiency that gives about 27.9 W orbit average, short of 30 W. The requirement is allocated through F3.1 to the solar arrays, so that is where the shortfall lands, and the options are architectural:

• more array area or higher-efficiency cells on L1 (mass, deployment complexity, cost);
• a better power path on L3, raising the 0.6 efficiency (a different regulator topology in the power distribution unit);
• less load: an operations change that images fewer targets per orbit, which moves the problem to the mission requirements.

Each is a candidate change to the physical architecture or to the concept, and each can be scored against the same criteria. That is the bridge from architecture to the trade study; until it closes, the TC-06 result stays suspect, as the traceability guide describes.

How LML and SysML express the three views

LML (the Lifecycle Modeling Language) keeps the vocabulary small. Functions are Actions, decomposed with decomposed by, exchanging Input/Outputs through generates and receives. Components are Assets, connected by Conduits that transfer the Input/Outputs. Allocation is the performs relationship (read the other way, performed by) from an Asset to an Action, and requirements are allocated with satisfies. LML has no separate class for logical elements; a project that wants a logical layer models it as a second Asset tree, marked with a label such as Logical, and links each physical Asset to the logical one it realizes with a trace relationship.

SysML has a dedicated allocation concept. In SysML v1, functions are activities or actions, components are blocks and parts, and allocation is an «allocate» dependency, often shown as swimlanes (allocate activity partitions) on an activity diagram or as allocation compartments on blocks. Logical and physical architectures are usually two block hierarchies with allocations between them.

In SysML v2 the same ideas are written as text. Actions are action def and action, components are part def and part, and allocation is the allocate … to …; statement (or perform, when a part carries out an action). The listing below writes the two EO-1 slices in that form: the functional, logical and physical views, the allocation chain between them, and the telemetry loop that becomes IF-09.

package EO1Architecture {
    // Items the functions exchange
    item def PowerTelemetry;
    item def SafeModeCommands;

    // Functional architecture: what the system does
    action def GenerateAndStorePower {
        action convertSunlight;
        action storeEnergy;
        action regulateBus {
            out telemetry : PowerTelemetry;
            in commands : SafeModeCommands;
        }
    }
    action def EnterSafeMode {
        in telemetry : PowerTelemetry;
        out commands : SafeModeCommands;
    }
    action def StorePayloadData;

    // Logical architecture: solution-independent elements
    part def PowerGeneration;
    part def EnergyStorage;
    part def PowerConditioning;
    part def FaultManagement;
    part def DataStorage;

    // Physical architecture: the real components
    part def SolarArray;
    part def BatteryPack;
    part def PowerDistributionUnit;
    part def FlightComputer;

    part def Spacecraft {
        action power : GenerateAndStorePower;
        action safeMode : EnterSafeMode;
        action storeData : StorePayloadData;

        part logical {
            part generation : PowerGeneration;
            part storage : EnergyStorage;
            part conditioning : PowerConditioning;
            part faults : FaultManagement;
            part data : DataStorage;
        }
        part eps {
            part solarArrays : SolarArray[2];
            part battery : BatteryPack;
            part pdu : PowerDistributionUnit;
        }
        part cdh : FlightComputer;

        // Functions to logical elements
        allocate power.convertSunlight to logical.generation;
        allocate power.storeEnergy to logical.storage;
        allocate power.regulateBus to logical.conditioning;
        allocate safeMode to logical.faults;
        allocate storeData to logical.data;

        // Logical elements to physical components
        allocate logical.generation to eps.solarArrays;
        allocate logical.storage to eps.battery;
        allocate logical.conditioning to eps.pdu;
        allocate logical.faults to cdh;
        allocate logical.data to cdh;

        // The functional exchange becomes an interface between components
        flow of PowerTelemetry from power.regulateBus.telemetry to safeMode.telemetry;
        flow of SafeModeCommands from safeMode.commands to power.regulateBus.commands;
    }
}

The two allocate logical.… to cdh; lines are the many-to-one allocation of the C&DH in one glance. The SysML v2 tutorial builds the EO-1 power system step by step, including its allocation with perform.

Architecture review checklist

• The project has written down which views it uses (functional and physical, or functional, logical and physical) and what each word means.
• Every lowest-level function is allocated to exactly one logical element or component.
• Every component performs at least one function, and every logical element is realized by at least one component.
• Each function's performer is part of its parent function's performer.
• Components that perform many functions have been checked for combined load: processing, memory, power and timing.
• Every item exchanged between functions on different components has a physical path, and every path carries at least one item.
• Each interface has an owner, a status and a capacity checked against the sum of what it carries.
• Requirements that are constraints are allocated to components or the system, not to invented functions.
• Mass, power and data budgets are allocated to components and roll up within the system limits, with margin.
• At least one alternative physical architecture was considered for each major allocation decision, and the choice is recorded with its rationale.

Common mistakes

Try it in Holarch

Holarch is an MBSE tool built on LML, where functions are Actions, components are Assets and allocation is performed by. The example above is the CubeSat EO-1 demo project: create it with Manage Projects → Project Files ▾ → New Demo Project. To review its architecture:

1. Open Behavior → Functional Analysis for the function tree, the flow and the FFBD. Link each function to its component with performed by in the inspector's Trace section, and tick Subsystem to show the performers in the allocation table.
2. For the allocation matrix, open Verification → Traceability Matrix. Click the Rows chip and choose Hierarchy under a root entity with F0 Perform EO-1 Mission; click the Columns chip and choose Hierarchy under a root entity with 0 EO-1 Mission; set Relationship to performed by and tick Hide empty columns. Click an empty cell to allocate, and Save view… to keep the setup. See the Traceability Matrix docs.
3. Open the Asset Diagram of 1 EO-1 Spacecraft from the Diagrams page for the physical architecture, then switch the diagram type selector to Physical I/O Diagram. Its lines come from the allocated exchanges and the conduits; the diagram checks (Checks in the toolbar) list any exchange with no conduit to carry it. See build a physical architecture and check its interfaces.
4. Double-click EPS on that Asset Diagram to open its own diagram, and switch the type selector to Physical I/O Diagram or Internal Block Diagram for the two EPS views shown above.
5. Open Interfaces → N² Diagrams for the exchanges between functions, and Interfaces → Interface Register for every conduit with its status and capacity check.
6. Run Verification → Model Checks: Action.11 lists actions no asset performs, Asset.11 assets that perform no action, and Asset.13 assets that exchange an item with no conduit in common.

From a flow on an Action Diagram, Arrange ▾ → Generate Asset Diagram builds a first physical context from the performers and the items they exchange.

Where to go next

• Architecture in Holarch: assets, allocation and the physical interfaces that follow from the functional ones.
• Behavior in Holarch: function hierarchies, FFBDs, action diagrams and simulation.
• Other Diagrams docs: Asset, Physical I/O, N2 and Interface Control Diagrams.
• Model Checks docs: the rules that find unallocated functions and missing interfaces.