What Is a Physical Architecture in Systems Engineering?
Physical architecture is the answer to a specific question: what physical things will be built, and what will each one do? It describes the hardware assemblies, software components, firmware modules, and mechanical structures that make up a system — and it specifies how those elements are connected. In the systems engineering process, physical architecture is not a starting point. It is an output, derived from decisions made earlier in the design process about what the system must do and how those functions should be logically organized.
That derivation chain matters more than most teams realize. When physical architecture is designed in isolation — when a team jumps from customer requirements to hardware block diagrams without working through function and logical structure first — the result is a system whose rationale is hidden inside individuals’ heads. It cannot be audited. It cannot be systematically changed. And when requirements change, as they always do, no one can reliably assess which physical elements are affected.
This article defines physical architecture precisely, explains how it relates to functional and logical architectures, walks through the allocation process that produces it, and covers how interface definitions emerge from that allocation. The second half addresses how requirements management platforms — particularly newer, graph-based tools — help teams maintain the traceability that makes physical architecture decisions defensible over time.
Three Architectures, One System
Systems engineering distinguishes three architectural views of the same system. Each view answers a different question.
Functional architecture answers: what does the system do? It describes the system’s functions — discrete, bounded behaviors the system must perform — and the logical flow of data, energy, or material between them. Functional architecture is deliberately technology-agnostic. It says “process sensor data” without specifying whether a microcontroller, FPGA, or cloud service performs that processing.
Logical architecture answers: how is the system organized? It groups functions into logical subsystems and defines the interfaces between those subsystems in terms of information types, data rates, and timing constraints. Logical architecture is still largely technology-agnostic, but it imposes structure. A logical subsystem is a coherent grouping of functions — a “power management subsystem” or a “communication subsystem” — not yet a specific piece of hardware.
Physical architecture answers: what is actually built? It maps logical elements to physical items: specific processors, sensor packages, PCBs, enclosures, software executables, network links. Physical architecture is where technology decisions are made and documented. It introduces part numbers, suppliers, form factors, and physical interfaces.
These three views are not sequential phases that a team completes and closes. They are concurrent and iterative. Physical architecture choices feed back into logical organization; logical groupings constrain what physical implementations are feasible. The progression from functional to logical to physical is a direction, not a waterfall.
From Functional Requirements to Physical Architecture
The derivation process from functional requirements to physical architecture involves three major steps.
Step 1: Functional Analysis and Decomposition
Functional architecture begins with the system’s stakeholder requirements — what the system must accomplish from the perspective of operators, customers, and the environment it operates in. Systems engineers decompose these requirements into discrete functions: actions the system performs, with defined inputs and outputs.
A satellite communication terminal, for example, might have a top-level requirement to “receive and decode telemetry data from orbit.” Functional analysis breaks this into: acquire uplink signal, filter and amplify received signal, demodulate carrier, decode data stream, validate data integrity, route validated data to user systems. Each function has defined inputs, outputs, and performance parameters. The function tree produced by this process is the functional architecture.
Step 2: Logical Grouping
Functions are then grouped into logical subsystems based on cohesion, performance requirements, and interface complexity. Functions that share data intensively, that have tight latency requirements relative to each other, or that represent a common concern (thermal management, power conversion, fault detection) tend to belong in the same logical subsystem.
The logical architecture at this stage defines subsystem interfaces in abstract terms: this subsystem produces a digitized baseband signal at this sample rate; this subsystem consumes it. Interface Control Documents (ICDs) begin to take shape here, but they are not yet tied to physical media or connector pinouts.
Step 3: Physical Allocation
Physical allocation is where logical subsystems and their constituent functions are assigned to physical elements. This is where architecture decisions have cost and schedule consequences. Allocating the signal processing subsystem to an FPGA versus a general-purpose processor changes thermal requirements, power budget, software architecture, and supplier relationships.
Allocation decisions are constrained by physical requirements: mass budgets, thermal envelopes, electromagnetic compatibility rules, reliability targets, and cost caps. Each allocation must be traceable to the requirements it satisfies — if you allocate signal decoding to a particular processor, that allocation exists because specific performance requirements demanded it.
How Interface Definitions Emerge from Allocation
Interfaces are not designed independently and then assigned to the system. They emerge directly from allocation decisions.
When two functions that exchange data are allocated to the same physical element — the same processor, the same PCB — the interface between them becomes an internal software or hardware boundary. It may still need documentation, but it is contained within one item.
When two functions that exchange data are allocated to different physical elements, a physical interface is mandatory. The boundary between “demodulate carrier” (on the FPGA processing board) and “decode data stream” (on the application processor) becomes a physical bus, a connector, a network link. Its bandwidth, latency, electrical characteristics, and connector specification must now be defined and maintained.
This is why allocation sequence matters. If teams defer allocation decisions and allow physical interfaces to be defined ad hoc by individual engineers, the interfaces will not be traceable back to functional requirements. When a functional requirement changes — say, data throughput doubles — no one can systematically identify which interfaces are affected without manually tracing through disconnected documents.
The complete set of physical interfaces, fully specified, forms the Interface Architecture. It is derived from, and must remain consistent with, the functional architecture and the allocation decisions that produced it.
Why Traceability Is the Core Engineering Problem
Physical architecture produces dozens or hundreds of allocation decisions. Each decision has a rationale tied to requirements. That rationale is engineering knowledge — it represents why the system is built the way it is, not just what was built.
Traceability is the practice of maintaining explicit, queryable links between requirements and the architecture elements that satisfy them. A requirement for vibration tolerance traces to a specific mounting solution. A latency requirement traces to an allocation decision to co-locate two functions on the same device. A power budget constraint traces to the selection of a specific processor family.
Without traceability, requirement changes generate uncertainty rather than impact assessments. An engineer changing a mass budget constraint cannot determine which physical assemblies are affected, which allocation decisions need to be revisited, or which interfaces may need to be renegotiated.
With traceability, the same change generates a scoped impact list automatically. The change propagates through the architecture’s dependency graph and surfaces every affected element.
How Requirements Management Platforms Support Physical Architecture Traceability
Maintaining traceability manually — in spreadsheets, Word documents, or disconnected Requirement Traceability Matrices (RTMs) — works for small systems. For systems with thousands of requirements and hundreds of allocation decisions, manual traceability collapses under its own weight. Updates to one document do not propagate. Links become stale. The RTM becomes a compliance artifact rather than a live engineering tool.
Established platforms like IBM DOORS Next, Jama Connect, Polarion, and Codebeamer all provide requirement traceability capabilities. They allow teams to create links between requirement objects and architecture elements, generate coverage reports, and manage change notifications. These tools are mature, have deep domain support, and are well-understood by verification and compliance teams.
The limitation common to most legacy platforms is that their data model is fundamentally document-centric. Traceability links exist within and between documents. Running a query like “show me every physical element that has an allocation link to a function that is derived from a Level 2 safety requirement” requires either a custom report configuration or manual cross-referencing. The architecture model and the requirements model live in separate representations, connected by links that are fragile to reorganization.
Graph-based architectures handle this differently. When requirements, functions, logical elements, and physical elements are all nodes in the same connected graph, traversal queries become straightforward. Allocation is a relationship type, not a separate document. Interface definitions are nodes connected to the functions they support and the physical elements they connect.
Flow Engineering takes this approach directly. Built for hardware and systems engineering teams, it models requirements and architecture elements together in a connected graph structure. Functional requirements, their derived functions, logical groupings, physical allocations, and interface definitions are all first-class nodes with typed relationships between them. When an engineer is reviewing a physical component, they can traverse back through allocation relationships to the original functional requirements that drove its existence — and forward to the verification activities that confirm it meets those requirements. The model does not require a separate RTM maintained alongside it; the traceability is intrinsic to the graph.
For teams managing avionics, defense electronics, satellite systems, or complex industrial hardware — domains where physical architecture decisions must be auditable and change-resistant — this representation difference is operational, not theoretical. A design review where you can query “which physical elements have outstanding allocation rationale gaps” produces a different conversation than one where that question requires manual inspection of linked documents.
Practical Starting Points
For teams building or rationalizing a physical architecture:
Establish functional architecture first, in a form your toolchain can reference. If your functions exist only in a Word document, traceability is manual from the start. Even a basic SysML block definition or a structured spreadsheet with stable function identifiers gives allocation something to link to.
Make allocation decisions explicit and documented at the time they are made. The rationale for an allocation decision has the most fidelity immediately after the trade study or technical discussion that produced it. Reconstructing rationale after the fact produces compliance artifacts, not engineering knowledge.
Treat interface definitions as derived outputs, not separate work products. When you finalize an allocation, immediately identify what interfaces that allocation creates or modifies, and update your interface architecture accordingly. Interfaces maintained separately from allocation decisions drift apart within one design cycle.
Choose tooling that can query across architectural levels. Whether that is a mature platform like Polarion with a well-configured architecture module, or a graph-native tool like Flow Engineering, the test is simple: can you start from a physical component and trace back to the stakeholder requirement that justified it in under two minutes without opening a separate document? If not, your traceability is documentation, not engineering infrastructure.
Summary
Physical architecture defines what gets built. Functional architecture defines what must be done. The allocation process that connects them — assigning functions to physical elements — is where most engineering decisions of consequence actually happen, and where interface definitions emerge as necessary consequences of those decisions.
The quality of your physical architecture, in an engineering sense, is determined not by whether the hardware works on the first build, but by whether the decisions that produced it are traceable, auditable, and maintainable when requirements change. That requires tooling designed to hold those connections — and a discipline of maintaining them throughout the design process, not reconstructing them for a review.