Slack Stealing

Honeywell is working to solve a number of open processing problems critical to maintaining our technology advantage in real-time safety critical systems, such as those found in avionics and automotive platforms.

Slack stealing efficiently allocates unscheduled and reclaimed CPU time for aperiodic task execution. Slack servers provide this rapid response to non-critical aperiodic tasks (when generalized rate monotonic scheduling (GRMS) is used for safety critical periodic tasks) by favoring a high-priority, event-driven aperiodic task when all critical deadlines for periodic tasks can be guaranteed.

Slack Stealing also reclaims compute time from periodic tasks that complete early for reassignment to aperiodic tasks. This reclamation capability is particularly useful in safety-critical systems where worst-case execution time bounds are often highly conservative.

Time partitioning with slack stealing offers significant benefits over an ARINC 653 partitioned RTOS.

	More rapid response times for event-triggered processor tasks layered on time-triggered safety critical task traffic. Host mixtures of application tasking models: periodic, event-driven, client/server (e.g., Host critical vehicle control and C4ISR applications on the same system).
	Improved network bus integration - slack server implemented in Honeywell's DeosTM RTOS yielded >3X improvement in bus throughput for a COTS FTP protocol.
	Increased system configuration flexibility for reduced system development and certification costs - slack server on Honeywell's Primus DeosTM RTOS cut in half the "certified" application configurations required to support customers.

Reduction of hardware requirements - slack stealing optimizes processor usage, allowing hosting of more applications without increasing CPU space. Honeywell's Deos^TM implementation obtained a 7X reduction in reserved processor utilization for an FTP stack, allowing >90% allocation for critical periodic tasks, with sufficient slack for aperiodic tasks to run in unscheduled and reclaimed time. Additionally, an avionics Communication Management Unit written in SDL (System Design Language) hosted on a Deos^TM implementation required no additional hardware. The CMU added to an ARINC 653 architecture did.

	Slack stealing can be implemented on top of COTS RTOS - in testing, a thin middle layer implementation on a COTS RTOS proved fully functional.
	Better incremental processing performance - improves display refresh rates, delivering above the guaranteed minimum whenever processor space is available.

Event triggered aperiodic messages ping-pong between a PC and two embedded target VME/VMIC boards, each co-hosting a time triggered, safety-critical workload and a COTS IP/UDP ack/nak message stream for display update flow control. Potential applications of Slack Stealing Protocol include:

	Tactical Internet access for helicopters.
	Integration with SDL applications.
	Valuable "plug and play" enabler technology - configuration flexibility provided by slack stealing makes the protocol valuable in modular applications.
	Performance degradations from slack overheads are often offset for interactive applications with short exchanges.

Honeywell has also redefined and extended slack stealing to support advanced time partitioning concepts such as selectively sharing slack both within and between time partitions. Additional extensions include support for:

	dynamic tasks
	dynamic time partitions
	incremental and design-to-time tasks
	overhead accounting policies
	slack priority semantics for non-monotonic task criticality assignments

Slack stealing for event driven processes has been demonstrated in MetaH, the foundation for AADL (an emerging SAE standard). Adaptations for dynamic time partitions have been implemented and flown in Honeywell's Primus Epic® RTOS Deos^TM.