Mixed Criticality¶
Cohosting differently critical computing functions while accounting for interference and preserving their required guarantees.
Core Idea¶
A computing system presents a mixed-criticality integration problem when functions with materially different safety or assurance requirements share computational resources and the design must account for how one can interfere with another while preserving the required guarantees. The defining structure is not merely a priority list: it is differently critical functions + shared carrier + differentiated requirements + an interference account.[1][2]
Two original design settings illustrate the relation. NASA's integrated modular avionics work examined applications of different criticality cohosted through partitioning, including a formal model of spatial or logical noninterference. An automotive research paper evaluated a fixed model of four ECUs and FlexRay communication with three safety-critical control and two time-critical applications, synthesizing time-triggered schedules to meet control and timing constraints. The former is formal and program-level avionics work; the latter is a modeled automotive scheduling experiment, not a reported deployed vehicle.[1][3][2]
Structural Signature¶
- Differently critical functions. Identify the resident functions and why their failure consequences or assurance obligations differ. Application names or task priorities alone do not establish criticality.
- Shared computing carrier. Identify the processor, kernel, memory, communication medium, or platform through which the functions can affect one another. If systems are physically and logically separate, the characteristic cohosting issue is absent.
- Differentiated requirements. State what each class must preserve: isolation, timing, deadline, control stability, performance, or other assurance properties. The exact obligations depend on the system; one universal certification rule cannot be read from these sources.
- Interference account. Show how a partitioning or scheduling design addresses the shared paths. The account must match the claimed property. Spatial noninterference evidence does not automatically prove temporal guarantees, and a feasible modeled schedule does not by itself demonstrate deployment.[1][3][2]
The account can take different forms. A kernel may partition applications, or a scheduler may allocate computation and communication slots. An overload mode switch that sheds less critical work is another possible technique, but neither cited positive depends on such a switch.
What It Is Not¶
- Not ordinary multitasking with different names. Multiple applications can share a machine without materially different assurance or failure stakes. Shared residence is only one role.
- Not scheduling priority alone. A high-priority task can be low-consequence, and a safety-critical function requires more than priority to establish its guarantee. Criticality describes requirements and assurance stakes; priority is one scheduling choice.
- Not a universal high-criticality overload mode. Some mixed-criticality models change modes and drop lower-criticality work, but the NASA partitioning and Goswami schedule cases here do not establish that as an invariant.[1][2]
- Not a proof that every application needs only its own assurance level. DiVito's formal model says partitioning kernel services and the ACR should be qualified at or above the highest criticality level admitted to the shared resource. That source-specific bound resists a simple “each partition alone” slogan.[1]
- Not evidence of a physical camera and infotainment ECU installation. The automotive paper models control and time-critical tasks, and reports a CPLEX solver run on an Intel i5 PC. It does not report deployment of the seed's illustrative camera scenario.[2]
Scope of Application¶
The abstraction is literal in shared computing architectures with different assurance stakes. In integrated modular avionics, applications can reside in operating-system partitions on a shared module. The critical question is which isolation properties the partitioning kernel supports and how the shared kernel itself is assured. DiVito's report formalizes spatial/logical noninterference for candidate designs; the Orion paper describes the application of IMA partitioning in a program design that still required adaptation.[1][3]
In automotive embedded design, control and time-critical applications may share modeled ECU and network resources. Goswami and colleagues used schedule synthesis to account jointly for timing, stability and control-performance requirements in a four-ECU/FlexRay model. Their fixed modeled system is a second literal setting because all four roles are present, although the evidence grade differs from an installed, certified vehicle.[2]
Clarity¶
Three claims that sound similar are different. Criticality difference concerns consequences or assurance obligations; cohosting concerns common resources; preservation evidence concerns what partitioning or scheduling actually establishes. A statement that two tasks “run on the same computer” proves only the middle claim. Conversely, a strict safety requirement for one task does not create a mixed system if it runs separately from all lower-stakes tasks.
The NASA formal result is especially instructive. The report addresses spatial/logical isolation and discusses assurance of common kernel services. It does not, from that result alone, prove every time-partitioning property. In the automotive model, a schedule meeting a set of constraints is a modeled feasibility and optimization result, not a safety certificate for physical ECUs. The claim must be stated at the same level as the evidence.[1][2]
Manages Complexity¶
Shared platforms can expose many possible interference paths: processor time, memory, kernel services and network slots. The four-role account compresses an initial review into practical questions: which functions, what distinct requirements, which shared paths, and what evidence controls each path? It prevents a design diagram's apparent separation from being mistaken for demonstrated noninterference.
The reduction must retain the property type. A partition can isolate address spaces yet leave timing contention. A time-triggered schedule can meet modeled deadlines while saying nothing about unmodeled failures. The entry manages complexity by pairing each promised guarantee with the resource and proof or analysis that supports it, rather than collecting every possible safety technique under one label.
Abstract Reasoning¶
Begin by removing each role in turn. If the applications have the same required assurance, the mixed nature disappears. If they share no carrier, cross-function interference through that carrier disappears. If a design lists partition names but provides no argument about isolation or schedule feasibility, the assurance conclusion has not been established. These counterfactuals distinguish the abstraction from generic embedded-system architecture.
Next trace a particular requirement through the shared resource. In DiVito's formal setting, ask whether an application can alter another's spatially isolated state through kernel services, and what qualification the common services require. In the Goswami model, ask which synthesized schedule satisfies stability, timing and deadlines, and how its control-performance cost compares with feasible alternatives. The reasoning moves from a declared obligation to an actual design argument; it does not promote modeled evidence into operational certification.[1][2]
Knowledge Transfer¶
The four-role test transfers from avionics to automotive software: differently critical applications use shared resources, with requirements and an interference account. The specific mechanism does not transfer unchanged. IMA partitioning and common-kernel qualification concern an avionics computing module; the automotive paper jointly synthesizes ECU and FlexRay schedules for a fixed application model.[1][3][2]
Outside computing, “mixed criticality” can be a metaphor for combining high- and low-stakes work. Unless the resource, interference path, and differing technical guarantees are specified, that analogy does not instantiate this computing concept or demonstrate a cross-domain Prime.
Examples¶
NASA integrated modular avionics partitioning¶
Differently critical functions: NASA's IMA work considers avionics applications with different criticality levels. Shared carrier: the applications use common module and kernel resources rather than separate computers for each function. Differentiated requirements: the applications have differing assurance obligations; the DiVito model places partitioning kernel services and the ACR at or above the highest criticality admitted to the shared resource. Interference account: formal spatial/logical partitioning and operating-system partitions are the mechanisms described. The formal result does not prove every temporal guarantee, and the Orion program paper describes design and adaptation rather than all final deployed details.[1][3]
Mapped back: different avionics assurances → shared IMA resource → application and common-kernel obligations → partitioning/noninterference argument, within the stated formal and program limits.
Modeled automotive ECU and FlexRay scheduling¶
Differently critical functions: Goswami and colleagues modeled three safety-critical control applications and two time-critical applications. Shared carrier: four modeled ECUs connected by FlexRay. Differentiated requirements: control stability/performance and real-time timing constraints. Interference account: a time-triggered schedule was synthesized with CPLEX under those constraints. The solver ran on an Intel i5 PC; the source does not document a physical ECU or vehicle installation.[2]
Mapped back: control and time-critical functions → modeled ECU/network resources → differing control and deadline constraints → joint feasible schedule synthesis. No burst-triggered emergency mode is part of this example.
Structural Tensions¶
- T1: Consolidation vs. isolation assurance. Sharing a platform can reduce separate-resource duplication, but it creates interference paths and a shared kernel whose assurance must cover the admitted applications. Favoring consolidation adds proof and qualification burdens; favoring physical separation forgoes some consolidation benefit. Diagnostic: Which common resources allow one function to influence another, and what evidence bounds each influence? DiVito's IMA motivation and kernel bound make the trade-off concrete.[1]
- T2: Modeled control performance vs. schedule feasibility. In the fixed automotive model, a more demanding sampling choice may improve the modeled control objective while tightening real-time ECU and FlexRay constraints. Favoring the target performance can leave no feasible schedule; choosing a feasible but less demanding schedule may worsen modeled control cost. Diagnostic: Among schedules that meet the stated stability, timing and deadline constraints, which minimizes the paper's control-performance objective? This is a modeling trade-off, not a claim that the study admitted fewer applications or optimized resource utilization.[2]
Structural–Framed Character¶
The entry is mixed, leaning framed. The relation between shared resources, interference and preserved guarantees is structurally inspectable. The words Criticality, assurance, partitioning and deadline travel among computing subdomains, but they do not have the same literal content in arbitrary organizations. Criticality also carries an evaluative design choice: one must assign consequences and obligations before the architecture can be judged adequate.
The carrier and interference can be technically analyzed, while safety requirements and acceptable evidence arise from human engineering and institutional assurance practice. The NASA and automotive papers show different such practices, not one universal certification rule. Recognizing the entry requires materially different obligations and a shared carrier with a protection account; merely importing a high/low priority label is insufficient. Its character: a domain-specific computing architecture problem with inspectable sharing and interference roles, and assurance requirements fixed by the application setting.
Structural Core vs. Domain Accent¶
The possible skeleton is coexisting functions with different constraints on a common resource. The computing accent is identity-bearing: functions execute on processors and networks; interference affects timing, memory or communication; safety and control obligations must be argued with partitioning, scheduling or another relevant method. A generic mixture of high- and low-stakes tasks lacks those technical relations.
The broad skeleton is a future-Prime question requiring unlike noncomputing literal cases and catalog ownership review. The cited avionics and automotive programs establish reuse inside computing only. Their analogy to general priority or resource allocation does not make the named entry a Prime.
Instantiates / Related Primes¶
The live Scheduling Prime concerns allocating work in time and helps describe the automotive synthesis step; it does not alone supply differing safety/assurance stakes. Interference and Contention concerns interactions over shared resources and helps pose the preservation question; it does not alone require a differentiated criticality argument. These are related structural components rather than asserted whole parents of the named computing architecture problem.
The distinction matters in practice. A system may have complicated scheduling with tasks all subject to one requirement, or severe resource contention without mixed assurance levels. Neither is mixed criticality merely because it shares a tool or word with the entry.
Neighborhood in Abstraction Space¶
Mixed Criticality sits in a sparse region of the domain-specific corpus (89th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2721 abstractions)
Nearest neighbors
- Shared memory — 0.80
- Dining philosophers problem — 0.79
- Parallel computing — 0.79
- Cache coherence — 0.79
- Real-time computing — 0.79
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
- Priority scheduling. Priorities express service order; they are not identical to failure consequences or assurance obligations.
- Ordinary cohosting. Several applications on one device, without differentiated guarantees and an interference account, do not suffice.
- Separate systems of different importance. No shared computing carrier means no cohosting problem under this identity.
- Mandatory overload switching. Dropping lower-criticality work in a high-criticality mode is a possible design variant, not a necessary feature of the two cases here.
- Certified deployment. A formal proof of one property or a modeled feasible schedule cannot be restated as certification or physical installation without additional evidence.
References¶
[1] Ben L. DiVito, "A Formal Model of Partitioning for Integrated Modular Avionics" (1998), NASA/CR-1998-208703, official full report, PDF pp. 6, 8, 10 (printed pp. 1, 3, 5). The report treats different-criticality applications on shared resources, a highest-admitted-application qualification bound for kernel services and ACR, and spatial/logical noninterference; its formal result is not proof of all temporal properties. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k
[2] Dip Goswami et al., "Time-Triggered Implementations of Mixed-Criticality Automotive Software" (2012), DATE conference paper, DOI 10.1109/DATE.2012.6176680, full original author-uploaded text, Abstract, §I, §V Table I and Results, Conclusions. The evaluated four-ECU/FlexRay setting is a model, with solver execution on an Intel i5 PC rather than reported deployment in a vehicle. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k
[3] Mark L. Mangieri and Jason Vice, "Kedalion: NASA’s Adaptable and Agile Hardware/Software Integration and Test Lab" (2011), AIAA Space 2011, full NASA-hosted paper, PDF p. 0 full title and authors, pp. 2–3, section “Orion Avionics Instantiation: Integrated Modular Avionics.” The section discusses different-criticality applications in operating-system partitions; further adaptation was contemplated. registry ↩a ↩b ↩c ↩d ↩e