For decades, “rugged” hardware has referred to equipment that could survive shocks, extreme temperatures and moisture while still getting the job done. If the hardware is MIL-STD-810 compliant with a solid IP rating, you have a pretty good idea of whether it will physically hold up in the field.
Things have changed, to say the least.
That old definition no longer covers what mission-critical edge computing needs to do. Today’s edge platforms include dense sensor arrays, high-speed storage, real-time data streaming, and compute-heavy AI workloads on GPUs.
Physical hardening still matters, of course, but the more difficult challenge is now architectural: how does a program converge safety-critical control, deterministic networking, and non-critical Linux or AI applications onto a single multicore platform without creating risks that outweigh the benefits of consolidation?
The Modern Edge Paradigm Shift
The forces influencing the shift are simple enough to understand. Programs want fewer boxes, lower SWaP, and platforms that can take on new sensors, processors and AI capabilities without needing a full redesign. But whenever a new workload is added to shared hardware, it comes with shared schedulers, memory, caches and I/O paths.
And none of it will show up on a MIL-STD-810 test report.
Architectural resilience is all about the ability to absorb changing hardware, new capabilities and ongoing software updates without triggering system-wide recertification every time something changes. It’s a different design goal than durability, meaning it requires different engineering pillars.
The Core Engineering Pillars of Architectural Resilience
There are four main pillars that support architectural resilience:
- Modular Open Systems Approaches. It’s easy to get caught treating MOSA as a box to check, but standards like FACE and SOSA don’t do the actual work. The focus here should be on decoupling application logic from the underlying hardware so that a change (processor refresh, new sensor, new supplier, etc.) doesn’t force a rewrite of the application layer above it. Aligning with FACE and SOSA gives you a common language for that decoupling and makes component reuse viable across platform generations. That said, it only pays off if the interfaces between them are precisely defined, including syntax, timing, error behavior, and the evidence needed to prove conformance.
- Hardware-enforced isolation and partitioning. A bare-metal, type 1 hypervisor running directly on the hardware (rather than on top of a host OS) gives a program better control over which cores, memory regions, devices and communication paths belong to which function. A crash or compromise in an AI or Linux partition shouldn’t have a way into a safety-critical partition. A properly designed separation architecture can prevent a failure or compromise in one partition from propagating into safety-critical domains by strictly controlling memory, device and communication access.
- Deterministic resource management. Isolation solves the intentional communication problem, but it doesn’t necessarily address hardware issues. On a multicore processor, two applications with no software communication path could interfere with each other through shared caches, memory controllers, interconnects or accelerators. The idea is to guarantee that a real-time control thread gets the execution window it needs regardless of what a high-throughput Linux workload is doing on another core. This requires the architecture to account for hardware-level coupling from the beginning rather than patching around it later.
- Zero-trust cyber resilience. Physical hardening protects the box from its environment, while zero-trust principles protect the system from itself. Components including secure boot, a hardware root of trust, encrypted storage and dynamic attestation extend the same discipline that governs physical security in the software and execution layers, meaning a compromised component can’t silently expand its reach across the platform.
Navigating Mixed-Criticality and Certification Challenges
Certification is where your architectural decisions could become costly. With monolithic architecture, for example, a minor software update to one function could trigger a retesting cycle that costs millions of dollars under DO-178C or IEC6 1508 because the certification authority can’t reliably rule out that the change affected everything else that shares runtime.
Explicit, testable partition boundaries can help contain the impact of change, allowing programs to focus certification and requalification effort on affected components rather than automatically reopening the entire system.
Separation also protects certified legacy code when a program wants to add a new, non-certified algorithm from a third party. Since the new component runs in its own domain, the legacy partition’s certification basis may not need to be reopened to the same extent
This is increasingly important as GPUs, FPGAs and NPU inference engines move into the same platforms as safety-critical control. AI workloads are useful because their outputs aren’t predictable in advance, but deterministic safety timing requires the opposite. Bounding the AI workload within a defined resource envelope prevents its compute behavior from interfering with deterministic control functions. The system architecture can then independently constrain how AI-derived outputs are consumed by safety-critical logic.
Best Practices for System Architects and Engineers
There are a handful of practices that help create value from MOSA-aligned architectures:
- Decouple the software infrastructure from specific hardware silicon before committing fo a processor (not after).
- Treat every software module as an untrusted boundary (even within the same SoC) until spatial and temporal separation is proven and documented.
- Build certification arguments around modular boundaries from the beginning, so a hardware refresh down the line only needs targeted requalification, not a retest from the ground up.
- Design two processing paths on the same platform: a deterministic, real-time path for flight or system controls, and a high-throughput path for payload and AI processing. Each should have its own resource guarantees.
These practices make the architecture explicit enough that resource ownership, data flow and system boundaries can be reviewed, tested and proven.
Physical ruggedization protects hardware from its environment. Architectural resilience protects the system from complexity, cyber threats, technological change, and obsolescence.
Modern mission-critical platforms need both.
The next generation of rugged computing will not be defined only by whether it survives the physical elements. It will be defined by whether it can survive change.
Author bio:
Michel Genard brings over three decades of experience in critical edge software, where he has held executive roles in both business and product management. Previously, he served as Vice-President of Product Management at Wind River, an established provider of embedded safety and security solutions. At Lynx, Michel’s primary focus areas are driving corporate and product strategy, messaging/branding and M&A. He also serves as an advisor and board member to other private companies.
