Rationale of Ravenscar Profile Executive Summary

1. Rationale of RavenscarProfileExecutive Summary Adapted from A. Burns, B. Dobbing, T. Vardanega: Guide for the use of the Ada Ravenscar Profile in high integrity systems, Univ. of York Tech. Report YCS-2003-348, January 2003

2. Motivation Software components of critical real-time applications must be provably predictable Software development methodology of complex applications focuses mainly on functionality, and so is inadequate, because non-functional issues (viz. safety, reliability, timeliness, memory usage, dynamic change management, etc.) are left until too late in the development cycle Traditional approach to formal verification and certification of critical real-time systems is to use a cyclic executive calling a series of procedures in a deterministic manner Such a system is easy to analyze, but difficult to design if even a moderate complexity is called for, not suited for sporadic activities occurring, or error recoveries Ada has proven useful in creating systems of integrity and real-time applications, albeit by use of Ada subsets of deterministic constructs, thus ensuring code analyzability

3. Ravenscar Profile … … is an Ada subset of its tasking model, restricted to meet real time requirements for Determinism Schedulability Analysis Memory Boundedness Mapping into a small and efficient run-time system, Supporting task synchronization and communication Certifiable to the highest integrity levels Potential verification techniques include: Information flow analysis Schedulability analysis Execution-order analysis Model checking RavenscarProfile is silent on the non-tasking (i.e. sequential) aspects of Ada, like Exception handling (or not handling) Constraints on the sequential part of the language (static analysis, worst-case execution time, etc.)

4. Scheduling Theory Recent research findings: Accurate analysis of real-time behaviour is possible with a careful choice ofscheduling / dispatching methods + careful restrictions on task interactions Priority-Based Preemptive Scheduling is usually used with Priority Ceiling Protocol (PCP) to avoid unbounded priority inversion and deadlock This approach supports Cyclic activities Sporadic activities The idea of hard, soft, firm, and non-critical components Controlled inter-process synchronization and communication Scalability to distributed systems

5. Task Characteristics Tasks in an application have timing constraints Critical tasks must meet deadlines Four basic levels of criticality in terms of importance of meeting a deadline: Hard: A hard deadline task MUST meet its deadlines. The failure to do so may result in unacceptable failure at the system level Firm: A firm deadline task must meet its deadlines under “average” or “normal” conditions. An occasional missed deadline may be tolerated (but perhaps at cost of degraded performance). There is no value of completing the firm task after a deadline has been missed (thus system-level degradation of service) Soft: A soft deadline task also must meet its deadlines under “average” or “normal” conditions. An occasional missed deadline may be tolerated (but perhaps at cost of degraded performance). There is value of completing the soft task even after a deadline has been missed Non-Critical: A non-critical task has no strict deadlines. Typically it is used to perform background duties. Task failure does not endanger the performance of the system

6. Scheduling Model At any moment in time, some tasks may be: Ready to run: i.e. are ready to execute if processor time became available Suspended: they cannot run until some event occurs Blocked: they await resource currently owned by another task Suspended tasks may become ready: Synchronously: as a result of action taken by currently running task Asynchronously: as a result of an external event Ravenscar requires priority-based preemptive scheduling on a single processor: Scheduler ensures that highest priority ready task is always executing Scheduler performs context switches Preemptivemeans that context switches can occur due to asynchronous events Tasks are required to interact as a result of: Contention to shared resources Exchange of data Synchronization needs

7. Scheduling Model Tasks interactions, if uncontrolled, pose risks of: Unbounded Priority Inversion / Blocking: when a high priority task is blocked by a low priority task using a certain resource, thus blocking the high priority task. In this case intermediate priority tasks can run “amok”, starving the high priority task for access to processor Deadlock: when group of tasks (perhaps the entire system) block each other permanently due to the circular ownership and contention for resources Livelock: when group of tasks (perhaps the entire system) do indeed execute but fail to make progress due to circular dependencies between them Missed Deadline: when a task fails to meet its deadline due to factors such as system overload, cost of context switching in excessive preemptions, excessive blocking, deadlocks, livelocks, or CPU overrun Ravenscar Profile is designed to minimize those risks In Ravenscar Profile tasks do not interact directly, but only via shared resources known as protected objects

8. Ravenscar Profile pragmaTask_Dispatching_Policy (FIFO_Within_Priorities); pragmaLocking_Policy (Ceiling_Locking); pragmaDetect_Blocking; pragma Restrictions ( No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_Priorities, No_Implicit_Heap_Allocations, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Relative_Delay, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Simple_Barriers, Max_Entry_Queue_Length => 1, Max_Protected_Entries => 1, Max_Task_Entries => 0, No_Dependence => Ada.Asynchronous_Task_Control, No_Dependence => Ada.Calendar, No_Dependence => Ada.Execution_Time.Group_Budget, No_Dependence => Ada.Execution_Time.Timers, No_Dependence => Ada.Task_Attributes); Or, in short: Pragma Profile (Ravenscar);