The Functional -> Logical -> Physical Distinction: Why It’s Not a Framework Artifact, It’s an Analytical Necessity

Using Requirement-Functional-Logical-Physical models to support early assembly process planning for complex aircraft systems integration — Tao Li Et al

If you’ve worked in systems engineering long enough, you’ve encountered the debate: is the separation between Functional, Logical, and Physical architecture a real, necessary step in system design, or just an artifact of whichever MBSE method you happen to follow?

After spending considerable time researching this question across SE literature, design theory, set theory, philosophy, and multiple engineering disciplines, I’ve arrived at a conclusion that I think is both useful and defensible: the three-layer decomposition is not owned by any framework. It emerges from the mathematics of decomposition itself, and it appears, independently discovered, across virtually every discipline that designs complex artifacts.

Here’s what I found.

The Debate

In practice, the SE community is split. Some practitioners treat Functional and Logical as essentially synonymous, both representing the abstract “what” of the system before you get to physical implementation. Others insist the Logical layer is distinct: a technology-agnostic structuring of how the system is organized to perform its functions, sitting between the pure behavior of the Functional architecture and the concrete reality of the Physical one.

The confusion isn’t surprising. INCOSE guidelines have historically treated functional and logical as closely related. The SEBoK acknowledges the distinction but doesn’t enforce it. Arcadia (via Capella) makes the separation explicit with four analysis levels. OOSEM bundles function and structure together through the object paradigm. Different methods, different answers.

But the question I wanted to answer wasn’t “which method is right?” It was: is there a deeper, method-independent justification for the three-layer separation?

To be clear, what follows is not an argument for a three-step process. It’s an argument that the design space has three analytically distinct layers, and that understanding this structure helps engineers make better tailoring decisions, including the decision to collapse layers when the domain supports it.

One further scoping note: what follows addresses the decomposable aspects of system design, where system-level behaviors can be meaningfully allocated to subsystem responsibilities. Complex systems also exhibit emergent properties that arise from interactions and resist allocation to any single component or subsystem. The F->L->P analytical distinction doesn’t claim to account for emergence; it claims to be a necessary lens for the aspects of design that are decomposable, which must be complemented by integrative methods, simulation, architectural prototyping, whole-system evaluation, that work at the system level. Both lenses are necessary. Neither is sufficient alone.

The Intellectual Roots Go Far Deeper Than SE

One of the most important findings from this investigation is that the F->L->P layering was not invented by any SE standard or method. It emerged from multiple converging intellectual traditions spanning over two millennia.

Aristotle’s Four Causes (~350 BCE)

This is not a stretch. Aristotle’s explanatory framework for both natural and artificial things already contain the essential separation:

• Final cause (what something is for) -> Function
• Formal cause (the arrangement or organizing principle) -> Logical structure
• Material cause (what it’s made of) -> Physical realization

His priority ordering mirrors ours: the final cause is “the cause of causes”, purpose determines form, form determines material selection. Aristotle was analyzing the structure of explanation for designed artifacts and arrived at essentially the same distinctions we debate today.

German Systematic Design, Pahl & Beitz (1977)

The first rigorous engineering formalization came from the German design methodology tradition. Pahl and Beitz established the design sequence: clarify the task -> establish function structures -> search for working principles -> combine into concept variants -> embodiment design -> detail design.

The Hubka-Eder Technical System model makes the layers explicit: function structure -> organ structure (working principle) -> component structure. That middle layer, the “organ” or “working principle”, is what we now call the logical architecture. It’s the how in principle before the how in specifics. VDI 2221 codified this progression as a German engineering standard.

Herbert Simon, Architecture of Complexity (1962)

Simon’s concept of near-decomposable systems, hierarchical systems where intra-subsystem interactions are stronger than inter-subsystem interactions, explains why decomposition works at all. His inner environment / outer environment distinction in The Sciences of the Artificial (1969) implicitly separates function (what the outer environment requires) from structure (the inner environment that satisfies it). Simon didn’t formalize F->L->P explicitly, but his complexity theory provides the mathematical justification for why the decomposition must proceed through intermediate structural layers.

Gero’s Function-Behavior-Structure Framework (1990)

In design research, John Gero’s FBS framework formalized the progression: Function is purpose as ascribed by the designer, Behavior is the observable attributes that achieve the function, Structure is the components and their relationships. The F->B->S progression is essentially F->L->P with “behavior” playing the role of logical mediation between intent and realization.

Suh’s Axiomatic Design (1990)

Nam Pyo Suh’s Independence Axiom requires maintaining the independence of functional requirements, and his mapping from functional domain -> physical domain formalizes the principle that function determines structure, not vice versa. Suh collapses the logical and physical into one “physical domain,” but his axioms reinforce the information-dependency ordering.

Industrial Standardization (1990s–2000s)

IEEE 1220 (1994), EIA-632 (1994/1998), and Dassault Systèmes’ V6 platform codified RFLP (Requirements-Functional-Logical-Physical) as an explicit product lifecycle structure. Baughey (2011) introduced the RFLP acronym. Kleiner & Kramer (2013) refined it for model-based design. But these are industrial codifications of a pattern that was already implicit in decades of engineering practice, standardization, not invention.

A Note on Wymore

Wayne Wymore’s A Mathematical Theory of Systems Engineering: The Elements (1967) and his Tricotyledon Theory of System Design (T3SD) provided the mathematical formalization of systems and system design, the system as a formal tuple, input/output specifications, the technology base, merit orderings. He gave us the mathematical objects and relationships needed to rigorously describe what a system is and what a system design problem is.

What Wymore did not do is articulate a functional -> logical -> physical architectural layering. That’s a methodological and architectural construct that emerged from the sources described above. What’s true is that if you take Wymore’s mathematics and attempt to decompose a complex system transformation into sub-transformations, the operations naturally separate into three analytically distinct steps. But that derivation is an inference from his math, not something he prescribed. The distinction matters for intellectual honesty.

The Logical Justification: Information Dependency

So what makes the three layers logically necessary rather than just a useful convention?

It comes down to an information-dependency chain that I’d argue is inescapable for any design of complex artifacts:

1. You cannot determine how to structure a solution without first knowing what the solution must accomplish. Function must precede logical structure, otherwise you’re partitioning something before you’ve defined what it does.
2. You cannot select specific realizing elements without first knowing what structural roles they must fill. Logical structure must precede physical selection, otherwise you’re choosing technology before you know what it needs to do in the system.
3. These are not merely practical preferences, they’re logical prerequisites. Attempting to reverse them produces either random search or implicit assumptions about the preceding layer that remain unexamined and untested.

This information-dependency argument applies to the aspects of system behavior that can be allocated, where a system-level function can be meaningfully assigned to a subsystem responsibility. It is worth acknowledging explicitly that not all system behavior has this character. Emergent properties, behaviors that arise from the interaction patterns among components rather than from the components themselves, cannot be ‘allocated’ in any meaningful sense. A flock’s murmuration pattern cannot be assigned to an individual bird. These properties require analysis at the whole-system level through integration, simulation, and test. The F->L->P distinction organizes the decomposable design space; it does not replace the need for holistic system-level reasoning about what the assembled whole will actually do.

This doesn’t mean the process is purely sequential. The decomposition has logical ordering (information dependency) but operational iteration (bidirectional refinement). Physical realization reveals constraints on logical structure. Logical structure reveals incompleteness in functional specifications. You iterate, but the iterations converge on a state where the information dependencies are satisfied.

The ordering describes the invariant structure of the design space, not a waterfall process.

Why Methods Disagree About the Layers

If the three-layer separation is logically necessary, why do prominent MBSE methods handle it differently?

Arcadia: Explicit Separation

Arcadia emerged from Thales’ defense electronics practice, radar systems, electronic warfare suites, avionics. In these domains, the same function (e.g., “detect airborne threat”) might be allocated to radically different logical architectures: a centralized processor vs. a distributed sensor network, a hardware-dedicated FPGA vs. a software-defined radio. The logical architecture is where you make the fundamental partitioning decisions, what components exist, what responsibilities they carry, how they interact, before committing to any physical technology.

Thales engineers found, through decades of practice, that conflating function with logical structure led to premature commitment. You’d start defining “detect threat” and immediately think in terms of a radar component, when the better logical solution might distribute that function across multiple cooperating subsystems. So Arcadia’s progression (Operational Analysis -> System Functional Analysis -> Logical Architecture -> Physical Architecture) enforces a deliberate cognitive pause between “what the system does” and “what parts it has.”

OOSEM: Bundled Through Object Orientation

OOSEM comes from the object-oriented tradition (Friedenthal, Moore, Steiner). In OO thinking, the fundamental unit is the object, an entity that encapsulates both behavior (what it does) and structure (what it is). When you identify a Use Case and realize it through a collaboration of Blocks in SysML, you’re simultaneously defining functional behavior and logical structure. The function doesn’t exist independently of the block that performs it, they co-emerge through analysis.

In my opinion, this isn’t a flaw. It reflects a legitimate philosophical position that function and structure are dual aspects of the same entity, not separable layers.

The Practical Consequence

Arcadia forces you to ask “could this function be allocated differently?” because the function exists as its own model element before any logical component owns it. OOSEM tends to converge on allocation faster because the object paradigm naturally binds behavior to structure.

Neither is mathematically wrong. They’re different traversal strategies through the same design space. But they produce different cognitive effects on the engineer, and for novel or cross-domain systems where the “obvious” allocation might not be the best one, the explicit separation pays for itself.

It’s also worth noting that in mature domains with well-established component patterns, telecom with TMF’s eTOM and SID, automotive with AUTOSAR, enterprise IT with established reference architectures, practitioners can often skip the explicit logical step because the industry has pre-solved that layer. The logical decomposition has been absorbed into domain convention. That’s not the same as saying the step doesn’t exist.

A Universal Pattern Across Design Disciplines

The strongest validation of F->L->P is that it works outside systems engineering entirely. The same three-layer decomposition appears wherever complex artifacts are designed through intentional decomposition of objectives into coordinated sub-objectives.

Structural Engineering:

• Functional: “Resist lateral wind loads of 110 mph with maximum drift of H/400”
• Logical: Moment frames vs. braced frames vs. shear walls, column grid layout, load path hierarchy, structural system decisions with defined interfaces but no specific member sizes
• Physical: W14x82 columns, A992 Grade 50 steel, 3/4" A325 bolts, specific weld details

Electrical/Electronic Engineering:

• Functional: “Amplify a 10 MHz signal with 40 dB gain and noise figure below 2 dB”
• Logical: Two-stage amplifier topology with defined inter-stage matching, feedback configuration, and bias architecture, circuit decisions without specific component selection
• Physical: BFP740 SiGe transistor, E96 series resistors, FR-4 PCB with controlled impedance traces

Anthropology (testing outside engineering entirely):

• Functional: “Resolve disputes between kinship groups, allocate scarce resources, transmit cultural knowledge”
• Logical: Council of elders, reciprocal exchange networks, apprenticeship systems, institutional arrangements with defined social interfaces
• Physical: The Nuer leopard-skin chief, the Trobriand kula ring, Balinese water temple networks, specific, culturally-situated implementations

This is actually what structural functionalism in anthropology was attempting, Radcliffe-Brown and Malinowski were trying to identify functional requirements of societies and their structural realizations, though they lacked the mathematical formalism to do it rigorously.

It’s worth noting that structural functionalism was eventually criticized within anthropology itself for its difficulty in accounting for emergence, agency, and systemic change, a limitation that mirrors the broader point that decomposition-based analysis, while necessary, requires complementary holistic methods.

Electronic Music Composition (in this case testing the approach from a creative product perspective — a discipline that I am very fond of):

• Functional: “Create a 7-minute arc of increasing harmonic tension resolving through timbral transformation”
• Logical: Three-section form, layered drones establishing harmonic ground, rhythmic fragmentation of that foundation, spectral filtering for resolution, with defined crossfade interfaces between sections
• Physical: Moog Subsequent 37 for bass drone, Mutable Instruments Clouds for granular processing, specific reverb chain, rendered at 48kHz/24-bit

The fact that this decomposition works or could work for music composition is not trivial. It demonstrates that F->L->P is not an engineering-specific heuristic, it’s a consequence of how complex designed systems get from intent to realization, regardless of domain.

The Meta-Pattern: Mathematics -> Methods -> Languages & Tools

Looking across all these disciplines, a consistent three-layer structure emerges in how humans organize the design of complex artifacts. I’d frame it as:

Layer 1, Mathematics (Universal, Method-Agnostic): Set theory, graph theory, category theory, formal logic, domain-specific mathematical foundations. These describe the invariant structure of the design space. They don’t care what method or tool you use.

Layer 2, Methods (Procedural Strategies): OOSEM, Arcadia, Harmony, Pahl/Beitz, Axiomatic Design. Different traversal strategies through the same mathematical decomposition space. Methods are heuristic strategies, not mathematical requirements.

Layer 3, Languages & Tools: SysML, Capella metamodel, OPM notation, VHDL, GD&T. These provide syntax and semantics for expressing models. Tools (Cameo, Capella, SAP2000, Ableton Live) provide execution environments.

This structure is self-similar across disciplines. In software engineering: lambda calculus and type theory (mathematics) -> OOP, functional programming, reactive (methods) -> Python, TypeScript, Go (languages) -> VS Code, React, Docker (tools). In structural engineering: continuum mechanics and linear algebra (mathematics) -> Limit State Design, Performance-Based Design (methods) -> AISC 360, Eurocode (languages) -> SAP2000, ETABS (tools).

The pattern universality suggests that building methodology or tooling at Layer 1 (mathematics) rather than Layer 2 (method) produces approaches that are inherently more generalizable, they encode the invariants that all methods must satisfy rather than the procedural choices that distinguish them.

One More Thing: The SE Process Should Vary Across Lifecycle Phases

A related insight that I think is underappreciated in the SE community: the systems engineering process itself is not a fixed engine that you crank identically at every lifecycle phase.

Most SE textbooks present a generic process (requirements analysis -> functional analysis -> synthesis -> evaluation -> decision) and say “apply this recursively at each level of the hierarchy and across lifecycle phases.” The Vee model does this. The SE Engine does this.

But the nature of the design problem changes qualitatively as you progress:

• Early phases are dominated by divergent exploration -> the design space is wide, uncertainty is high, the process must generate variety
• Middle phases are dominated by convergent commitment -> narrowing options, making allocation decisions, resolving trade-offs
• Late phases are dominated by integration and verification -> assembling realized components, testing against requirements, managing the gap between intent and reality

The types of analysis, feedback structures, decision criteria, and artifacts produced are qualitatively different in each phase. Kossiakoff’s Systems Engineering: Principles and Practice is one of the few texts that makes this explicit, showing structurally different process flows for each lifecycle phase rather than a single generic process with different labels. This is closer to how experienced systems engineers actually work, they know that the kind of thinking you do in concept exploration is fundamentally different from what you do in integration and test.

This connects back to F->L->P: the three-layer decomposition itself may be emphasized differently at different phases. Early phases are more functionally oriented. Later phases are more physically constrained. The logical architecture serves as the stable bridge between evolving requirements and evolving implementation, which is why getting it right matters so much.

Key Takeaways

1. F->L->P is not owned by any framework. Its roots span Aristotelian philosophy, German systematic design, complexity theory, step theory, fractal theory, design research, and industrial standardization. Multiple intellectual traditions converged on the same structure independently.
2. The logical layer is logically necessary, not just practically useful. The information-dependency chain (function -> structure -> implementation) cannot be reversed without either random search or hidden assumptions.
3. The process is iterative, not sequential. The ordering describes information dependency, not a waterfall. You iterate, but iterations converge on a state where the dependencies are satisfied.
4. Methods differ in how they handle the layering, and neither approach is wrong. Arcadia makes it explicit. OOSEM bundles it through object orientation. Both navigate the same mathematical territory with different cognitive effects.
5. Mature domains may pre-solve the logical layer through industry reference architectures. But for novel or cross-domain systems, skipping the explicit step means making structural and technology commitments simultaneously.
6. The pattern is universal across every discipline that designs complex artifacts through intentional decomposition, from structural engineering to anthropology to music composition.
7. The SE process itself should adapt across lifecycle phases, not just across system hierarchy levels. The optimal traversal of the F->L->P space changes as the design matures.
8. F->L->P addresses the decomposable aspects of system design. Emergent properties that arise from component interactions require complementary integrative analysis at the system level. Decomposition is a necessary lens, not a complete one — both analytical strategies are required for complex systems.

The more I investigate this topic, the more I’m convinced that the three-layer decomposition is one of those fundamental patterns that keeps getting rediscovered across disciplines because it reflects something real about how complex designed systems move from intent to realization. It’s not a methodological preference. It’s a structural necessity.