ARINC 653 Temporal and Spatial Partitioning

Temporal and Spatial Partitioning Solve Different Problems

In ARINC 653, temporal partitioning controls when a partition can use processor time, while spatial partitioning prevents one partition from accessing another partition's memory and protected resources. The first is fundamentally a scheduling and budget problem; the second is a protection and address-space problem.

Deterministic partition windows inside a major time frame prevent one application from consuming all processor time. A correct schedule, however, does not provide memory isolation by itself. Reliable IMA design treats time, memory, and inter-partition communication as separate verification boundaries.

In a safety-critical computer, memory isolation alone is not sufficient. If a lower-criticality application consumes CPU at the wrong time, a more critical function can miss its deadline. Isolation therefore has both spatial and temporal dimensions.

My early avionics experience made the difference between “runs fast” and “runs at a predictable time” especially concrete.

Why IMA needs partitions

Integrated Modular Avionics consolidates applications on shared computing platforms. Hardware can be reduced, but CPU, memory and communication resources must be isolated explicitly.

Spatial partitioning

A partition must not read or modify memory assigned to another partition. This boundary is enforced by the platform and configuration, not only by application discipline.

Temporal partitioning

Partitions receive execution windows inside a repeating major frame:

major frame
| P1 | P2 | P3 | P1 | ...

The important property is whether each partition receives its configured time window predictably.

A second scheduler exists inside the partition

The platform schedules partitions; each partition then schedules its own processes. These are different levels of timing analysis.

Controlled communication

Sampling and queuing ports provide explicit communication paths. Isolation would be incomplete if applications could bypass partition boundaries through uncontrolled shared state.

Health monitoring is more than logging

Health-monitoring policy can map faults to process-, partition- or module-level actions. The question is not only whether an event is recorded, but what recovery action follows.

Configuration is part of correctness

Time windows, memory regions, ports and health-monitoring rules are configuration artifacts that can invalidate an otherwise correct application if they are wrong.

Worst-case behavior over average throughput

A real-time partition is evaluated against execution budget and interference under worst-case assumptions rather than average requests per second.

The broader lesson is that shared hardware can still provide strong isolation when memory, time, communication and failure handling are designed together.

References

• ARINC653P1-6, Avionics Application Software Standard Interface

• TÜBİTAK BİLGEM real-time operating-system adaptation publications

Concept Layer

A concise definition of the partition model used here is maintained under ARINC 653. This article keeps the deeper treatment focused on temporal windows, spatial isolation, health monitoring and their combined effect on real-time system behaviour.