!standard D.7(14) 09-10-22 AI05-0172-1/01 !standard D.13.1(4/2) !class Amendment 09-10-22 !status work item 09-10-22 !status received 09-10-22 !priority Medium !difficulty Easy !subject Extension to Ravenscar Profile !summary Use experience with the Ravenscar Profile in real-world embedded systems indicate that a disciplined use of execution time timers would be a very useful extension to the profile. The use of execution time timers should be limited to at most one timer per task, to be sanctioned by adding the relevant restriction to the set of restrictions subsumed by the pragma Profile (Ravenscar). !problem Industrial experience with implementations of the Ravenscar Profile for real-world embedded targets has highlighted the need for execution time timers to be included in the profile. Evidence of that need arises from three escalating observations: 1) the essential motivation of the Ravenscar Profile is to serve the needs of high integrity systems whose development processes require static analysis, including for schedulability, and, possibly, total or partial certification. One fundamental input to schedulability analysis is the worst-case execution time (WCET) of tasks 2) establishing safe and yet tight bounds for WCET values still is a very tough challenge for current industrial practice, which may result in optimistic values being chosen, which may fail in extreme circumstances at run time thus causing the system execution behavior to deviate from what stipulated by static analysis: this violation could be detected by allowing the use of execution time timers in Ravenscar-based systems 3) in the light of 1) and 2) above, execution time timers are the most practical, economic and trustworthy way for industrial developers to obtain accurate execution time measurements from running representative test cases of the system on the real hardware. The exclusion of execution time timers from the Ravenscar Profile was initially based on the perception that their implementation would complicate the run-time support, thus hindering certification, and also incur heavy run-time overhead, thus causing unacceptable performance penalties. In the meanwhile, some industrial-quality implementations of the Ravenscar Profile were experimentally extended with support for execution time timers, restricted to at most one timer per task. The lesson to be learned from those endeavors is that the implementation cost is not significant (so long as the target hardware has adequate provision for timer registers) and the time overhead is also acceptable, but most of all fully boundable. !proposal We propose to allow execution time timers to be included in the Ravenscar Profile, but restricted to at most one timer per task. !wording Clause D.7 should be modified to include a new pragma Restrictions with restriction_parameter_identifier Max_Execution_Time_Timers. Clause D.13.1(4/2) should be modified to include restriction Restrictions (Max_Execution_Time_Timers => 1) and to remove restriction No_Dependence => Ada.Execution_Time.Timers in the specification of the run-time profile Ravenscar. !discussion This AI was raised by an industrial user of non-preemptive scheduling, and was discussed and endorsed by the 14th IRTAW. Details are contained in the workshop paper: Providing Additional Real-Time Capability and Flexibility for Ada 2005, by Rod White. !example ** TBD ** --!corrigendum D.13.1(4/2) !ACATS test Add an ACATS B-Test of the new restriction, and a test to check that it is included in the Ravenscar profile. !appendix ****************************************************************