Architecture Patterns Across Domains

Patterns That Recur Everywhere

Lessons 1 through 3 addressed architecture decisions, interfaces, and trade studies. This lesson steps back to observe something striking: the same structural patterns appear across engineering domains that developed independently. Software architects, aerospace engineers, chemical process designers, and nuclear safety engineers have all converged on a small set of recurring architecture patterns — not because they copied each other, but because the underlying constraints they face are fundamentally similar.

Understanding these patterns gives you a transferable vocabulary. When you recognize that a layered avionics architecture and a layered software application solve the same structural problem — isolating concerns into ordered tiers — you can apply lessons from one domain to the other. When you see that publish-subscribe in an IoT sensor network and publish-subscribe in a distributed manufacturing system share the same coupling trade-offs, you can anticipate failure modes before they occur.

These patterns are not prescriptions. They are named solutions to recurring structural problems, each with known trade-offs. The value is in recognizing which pattern fits your constraints — and what you give up when you choose it.

Layered Architecture

A layered architecture organizes the system into ordered tiers where each layer depends only on the layer immediately below it. Higher layers use services provided by lower layers; lower layers are unaware of the layers above them. Communication flows vertically through the stack.

Where It Appears

Software. The OSI network model is seven layers. Web applications follow a presentation-logic-data layering. Operating systems layer user space above kernel space above hardware abstraction. Each layer provides a defined interface to the layer above and consumes the interface of the layer below.

Avionics (aerospace). Modern avionics systems like ARINC 653 partition applications into layers: application software runs above an operating system layer, which runs above a board support layer, which runs above hardware. Each layer has strict interface boundaries. An application cannot bypass the OS to touch hardware directly — the layering enforces isolation.

Industrial control (manufacturing, chemical). The Purdue Enterprise Reference Architecture (ISA-95) defines five layers from physical process (Level 0) through sensors and actuators (Level 1), control systems (Level 2), manufacturing operations (Level 3), to business planning (Level 4). Each layer has a defined scope of responsibility and communicates through standardized interfaces.

Building systems (civil). Building automation systems layer physical plant (HVAC, lighting, fire) below controllers, below a supervisory network, below a management workstation. The layering isolates the physical control loops from the business-level scheduling and energy optimization.

What It Trades Off

Gains. Separation of concerns — each layer has a bounded responsibility. Substitutability — a layer can be replaced without affecting layers above it, provided the interface is preserved. Testability — layers can be tested independently by mocking the layer below. Understandability — engineers can reason about one layer at a time.

Costs. Performance overhead — every request must traverse the stack, and each layer crossing adds latency. Rigidity — if a high layer needs something from a non-adjacent low layer, it must pass through every intermediate layer (or violate the pattern, creating a "layer bypass" that erodes the architecture). Abstraction mismatches — the abstractions that make sense at one layer may not map cleanly to the needs of the layer above.

MBSE connection. In the system model, layered architecture is expressed through structural decomposition with dependency constraints. Each layer is a block or component; the allowed dependencies (which layer can reference which) are captured as directed relationships. The model enforces the layering rule computationally — a dependency from Layer 3 to Layer 1 that skips Layer 2 is a model violation, not just a code review finding.

Pipe-and-Filter Architecture

A pipe-and-filter architecture structures the system as a sequence of processing stages connected by data channels. Each filter receives input, transforms it, and passes the output to the next filter through a pipe. Filters are independent — each knows only its own input format and output format, not what comes before or after it in the chain.

Where It Appears

Chemical processing (chemical). A chemical plant is a physical pipe-and-filter system. Raw material enters a reactor (filter), flows through a heat exchanger (filter), passes through a separation column (filter), and exits as product. Each unit operation transforms the stream. The piping between units carries material flow with defined composition, temperature, pressure, and flow rate.

Data pipelines (software). ETL (extract-transform-load) systems, Unix command-line pipelines, stream processing frameworks (Kafka Streams, Apache Flink). Data enters, passes through a sequence of transformations, and exits in its final form. Each stage is independently deployable, testable, and replaceable.

Signal processing (electrical). A signal chain passes through amplification, filtering, digitization, and feature extraction. Each stage transforms the signal and passes it forward. The interface between stages is defined by signal characteristics — voltage range, bandwidth, sample rate.

Water treatment (environmental, civil). Raw water passes through screening, coagulation, sedimentation, filtration, and disinfection. Each treatment stage is a filter that transforms the water quality. Stages can be added, removed, or reordered based on source water characteristics.

What It Trades Off

Gains. Composability — filters can be rearranged, added, or removed to create new processing pipelines. Reusability — a filter that normalizes data can be used in multiple pipelines. Parallelism — independent filters can execute concurrently. Simplicity — each filter has a single, well-defined transformation responsibility.

Costs. Latency — data must pass through every filter in sequence, and total latency is the sum of all filter latencies. No shared state — filters cannot easily access data from non-adjacent stages without breaking the pattern. Data format overhead — if each filter has a different native format, format conversion at each pipe adds processing cost. Error propagation — a malformed output from one filter becomes a malformed input to the next, and diagnosing which filter corrupted the data requires inspecting every stage.

MBSE connection. Pipe-and-filter maps naturally to behavioral models. Each filter is a function or activity; each pipe is a flow. The system model captures the transformation at each stage, the flow types between stages, and the performance budgets (latency allocation per filter). When a filter is modified, the model's flow-type constraints verify that the output still matches the next filter's expected input.

Publish-Subscribe Architecture

In a publish-subscribe (pub-sub) architecture, components communicate through a message broker rather than directly. Publishers emit messages tagged with topics; subscribers declare interest in topics; the broker delivers matching messages. Publishers and subscribers are unaware of each other's existence — they know only the broker and the topic namespace.

Where It Appears

IoT and sensor networks (electrical, environmental). Sensors publish readings to topics (temperature/zone-3, pressure/tank-7). Monitoring dashboards, alerting systems, and data loggers subscribe to the topics they need. Adding a new subscriber requires no change to any publisher. Removing a sensor requires no change to any subscriber (they simply stop receiving data on that topic).

Distributed systems (software). Event-driven microservices use message brokers (Kafka, RabbitMQ, MQTT) to decouple services. An order service publishes an "order-placed" event; inventory, billing, and shipping services each subscribe independently. No service calls another directly.

Building automation (civil). BACnet and similar protocols use a publish-subscribe model for sensor data distribution. A temperature sensor publishes its reading; the HVAC controller, the energy management system, and the fire alarm system each subscribe to the readings they need.

Spacecraft telemetry (aerospace). Onboard systems publish telemetry to a data bus. The communications subsystem subscribes to downlink the data. The onboard fault manager subscribes to monitor for anomalies. The attitude control system subscribes to sensor data it needs for state estimation. The data bus acts as the broker.

What It Trades Off

Gains. Loose coupling — publishers and subscribers evolve independently. Scalability — adding subscribers does not require modifying publishers. Flexibility — new consumers can tap into existing data streams without system modification. Resilience — a failed subscriber does not affect publishers or other subscribers.

Costs. Message delivery guarantees are complex — at-most-once, at-least-once, and exactly-once delivery each have different failure modes and performance implications. Debugging is harder because the interaction between publisher and subscriber is indirect — you cannot trace a call stack from sender to receiver. Ordering guarantees are difficult to maintain across topics. The broker is a critical dependency — if it fails, all communication stops.

MBSE connection. Pub-sub architecture in the system model is represented through ports with topic-typed flows and a broker component that mediates. The model captures which components publish to which topics and which subscribe — making the implicit data flows explicit. When a topic schema changes, the model's type system identifies every subscriber that will be affected, enabling impact analysis before deployment.

Redundancy Architecture

A redundancy architecture replicates critical components so that the failure of any single component does not cause system failure. Redundancy comes in several forms: active-active (all replicas process simultaneously), active-standby (backup activates on primary failure), and voting (multiple replicas execute independently and a voter selects the majority result).

Where It Appears

Aerospace (aerospace). Fly-by-wire flight control systems use triple modular redundancy (TMR): three independent computers execute the same control laws, and a voter selects the majority output. If one computer fails or produces an erroneous result, the other two outvote it. The redundancy is not just hardware — the software on each channel may be developed by different teams using different algorithms (dissimilar redundancy) to protect against common-mode software faults.

Nuclear (nuclear). Nuclear reactor protection systems use redundant sensor channels and voting logic. The safety system that initiates a reactor trip typically uses two-out-of-four voting: four independent channels monitor reactor parameters, and a trip is initiated when any two channels agree that a limit has been exceeded. This tolerates one failed channel (spurious trip) and one failed channel (missed detection) simultaneously.

Data infrastructure (software). Database replication (primary-replica, multi-primary), load-balanced web servers, redundant network paths. Cloud systems replicate data across availability zones so that a datacenter failure does not cause data loss. Consensus protocols (Raft, Paxos) coordinate replicas to maintain consistency.

Power systems (electrical). Electrical grids use N-1 contingency: the grid is designed so that the failure of any single transmission line does not cause cascading outages. Substations have redundant transformers. Critical facilities have backup generators and uninterruptible power supplies. The redundancy is sized to maintain full capability under any single-element failure.

What It Trades Off

Gains. Fault tolerance — the system continues operating despite component failures. Safety — redundancy prevents single faults from propagating to hazardous states. Availability — system uptime increases with redundancy level. Confidence — voting detects erroneous outputs that a single channel would pass through silently.

Costs. Weight, volume, cost, and power all increase with each redundant element. Complexity increases because the redundancy management logic (failure detection, switchover, voting, resynchronization) is itself a potential failure source. Common-mode failures can defeat redundancy if all replicas share the same design flaw, the same power supply, or the same environmental exposure. Maintenance burden increases because more components require inspection, testing, and replacement.

MBSE connection. Redundancy architecture is expressed in the system model through replicated structural elements with explicit failure-mode annotations. The model captures which components are redundant, what voting or switchover logic governs them, and what failure combinations the redundancy protects against. Fault tree analysis, often linked to the system model, quantifies the reliability improvement that redundancy provides and identifies common-mode vulnerabilities.

Reveal each card above to review the four patterns. Notice the structural parallel: every pattern appears in both physical and digital domains because the underlying problem — how to organize components, manage data flow, handle coupling, or tolerate faults — transcends any single discipline.

Choosing the Right Pattern

The patterns are not mutually exclusive. Real architectures combine them. A fly-by-wire system uses layered architecture for software partitioning, redundancy for fault tolerance, and publish-subscribe for sensor data distribution. A modern cloud application uses layered architecture for request handling, pipe-and-filter for data processing, and publish-subscribe for event distribution.

The choice of pattern is driven by the same architecture drivers from Lesson 1 — performance, scalability, safety, cost, schedule, maintainability. The pattern vocabulary accelerates trade studies (Lesson 3) because each pattern comes with known trade-offs. Instead of analyzing every architecture from first principles, you start with the pattern whose trade-off profile aligns with your drivers and then adapt it to your specific constraints.

When the system model (DGTLENG 201) captures the architecture in terms of patterns, the model becomes more communicable. Saying "the data processing subsystem uses a pipe-and-filter pattern with six stages" conveys structural intent immediately to any engineer familiar with the pattern vocabulary — regardless of whether they come from software, chemical, or electrical engineering.

Assessment