The multicore revolution solved a problem that had frustrated embedded system architects for decades. Instead of adding another processor board every time a new function was introduced, engineers could consolidate multiple applications onto a common computing platform. The benefits were obvious: lower size, weight, and power (SWaP), reduced hardware costs, and a simpler physical architecture.
Yet as many programs have discovered, consolidation does not automatically reduce complexity. In many cases, it simply moves that complexity from hardware into software.
The challenge becomes particularly visible several years into a program's lifecycle. The platform is fielded. New capabilities are requested. Cybersecurity requirements evolve. A sensor is upgraded. An autonomy function is added. What initially appeared to be a straightforward modification suddenly triggers a much larger effort. Safety teams need to assess impacts. Certification teams revisit assumptions. Security engineers examine new attack paths. Integration teams perform broader regression testing than anticipated.
The problem is often not the change itself. The problem is understanding everything that might be affected by the change. This phenomenon is what we call shared fate.
Shared fate exists whenever multiple functions become dependent on common infrastructure. The dependency may be obvious, such as a shared software service or device manager. It may be less visible, embedded within a common execution environment, resource management layer, or virtualization framework. Regardless of where it resides, the effect is the same: a modification to one part of the system creates uncertainty elsewhere in the system.
Over time, these dependencies accumulate. Each one may appear reasonable in isolation. Sharing resources often improves utilization. Centralized services can simplify management. Common infrastructure can reduce duplication. But every shared dependency introduces coupling, and coupling carries a long-term cost.
That cost rarely appears during initial integration. It emerges later, when the architecture must evolve. This is one reason why certification activities become increasingly challenging as systems mature. Engineers are not simply validating software functionality; they are validating assumptions about interactions. The more extensively functions depend on common infrastructure, the more difficult it becomes to bound the impact of change. What begins as a modification to one application can quickly expand into an assessment of timing behavior, resource utilization, interference paths, security boundaries, and system-level requirements.
The same dynamic appears in cybersecurity. When a vulnerability is discovered within a shared component, the question is rarely limited to that component alone. Security teams must determine which applications depend on it, what privileges it possesses, and whether the vulnerability creates a pathway into adjacent functions. The broader the dependency, the broader the investigation.
Multicore architectures amplify these challenges because they dramatically increase the number of possible interactions within a system. Applications that once operated on separate processors now coexist on the same hardware platform. Shared resources become more common. Timing relationships become more complex. Demonstrating freedom from unintended interference becomes a critical part of both safety and security assurance. As a result, many of the most important discussions in modern embedded computing are no longer centered on performance. Processing power continues to grow. Memory capacities continue to expand. Hardware capabilities are rarely the primary constraint.
The more difficult question is architectural. How can systems be designed so that individual functions remain independent even while sharing the same physical platform?
The answer increasingly lies in reducing shared fate.
Architectures that establish clear ownership of resources, explicit separation boundaries, and well-defined interfaces tend to age more gracefully than architectures built around extensive shared infrastructure. When responsibilities are clearly bounded, the consequences of change are easier to understand. Verification activities become more focused. Security assessments become more manageable. New capabilities can be introduced without forcing a system-wide reevaluation.
This does not eliminate complexity. Modern mission systems will always be complex. What it changes is where that complexity resides. Instead of concentrating complexity in a common layer that every application depends upon, the architecture contains complexity within individual functions and their clearly defined boundaries.
That distinction becomes increasingly important as systems remain in service for decades rather than years. The most successful platforms are rarely those that maximize consolidation on day one. They are the platforms that continue to evolve efficiently ten or twenty years later.
For that reason, architects evaluating multicore platforms should look beyond traditional measures of utilization and consolidation. Those metrics remain important, but they tell only part of the story.
A more revealing question is this:
When one function changes, how much of the rest of the system must care?
The answer often determines the true lifecycle cost of the architecture.
And in modern mixed-criticality systems, that cost is increasingly defined not by processing power, but by shared fate.
