RapiTime BAE Systems Experience Report

- Hundreds of thousands of lines of Ada
- Worst-case hot spots identified using RapiTime
- Targeted optimisation effort
- Examined just 1.2% of the code
- Achieved 23% reduction in execution time
- Significant cost saving
BAE Systems Hawk Mission Computer
In November 2006, Rapita Systems Ltd was awarded a contract by BAE Systems to identify opportunities for worst-case execution time reduction in the Operational Flight Program software of the Hawk Mission Computer.
Hundreds of thousands of lines of Ada code
The Hawk Mission Computer Operational Flight Program (OFP) software comprises hundreds of thousands of lines of Ada source code, executing on a PowerPC (MPC7410) as 25 separate software partitions.
The key objective of the project is to reduce the overall execution time of the OFP Software by 10%. Phase 1 of the project focused on 4 partitions that make up approximately 25% of the schedule. The RapiTime worstcase execution time analysis tool set was used to identify opportunities for reducing the overall execution time of code in these partitions.
Worst-case hotspots
Unlike conventional code profiling techniques, RapiTime identifies worst-case hotspots from the point of view of worst-case execution time. That is the Ada sub-programs and lines of source code that contribute most to the overall worstcase execution time. Conventional profiling techniques identify the lines of code that execute the most on average, which is very different.
Execution time contribution
By combining static analysis of the program structure with timing trace information generated via extensive testing, RapiTime was able to provide information about the contribution of every subprogram to the overall worst-case execution time thus identifying candidate sub-programs for optimisation.

What If?
Next RapiTime was used to answer what-if questions about the effects of potential reductions in the execution time of these subprograms. This showed that optimising some candidate sub-programs would result in a commensurate reduction in the overall worst-case execution time; whilst for other subprograms, optimisation would bring little benefit as the worst-case path shifted to other code.
Code optimisations
Optimisations included: removing code that created redundant copies of large data structures; re-writing bit unpacking code, enabling the compiler to produce much more efficient object code (in a sub-program that was called over 700 times on the worst-case path); and re-writing case statements using look-up tables (called over 450 times on the worst-case path).
23% reduction in worst-case execution time
Overall, RapiTime accurately identified worst-case hotspots enabling a 23% reduction in the worst-case execution time of the analysed partitions. This reduction was achieved via a targeted and highly focused optimisation effort. This minimised the software development and validation/verification effort required whilst ensuring that the improvements had the maximum possible impact.
By examining 1.2% of the code
The sub-programs that needed to be examined to achieve this reduction represented just over 1% of the code in the selected partitions.
The reductions in worst-case execution time achieved in phase 1 mean that the project is well on track to meet its objectives. Successful conclusion of the project will enable significant extra functionality to be added to the Mission Computer without the need for an extremely costly hardware upgrade.
"We are delighted with the schedule reductions achieved in phase 1" said Dean Armstrong, Software Engineering Manager at BAE Systems Brough. "The integration team are now looking at how RapiTime can be used as an integral part of the software development process for future Hawk developments".
Download the RapiTime BAE Systems Experience Report for more information.
For more information, please contact us to request a copy of the paper, "Identifying Opportunities for Worst-case Execution Time Reduction in an Avionics System (G. Bernat, R.I. Davis, N. Merriam, J. Tuffen, A. Gardner, M. Bennett, D. Armstrong)" Ada User Journal pp. 189-194, Volume 28, Number 3, Sept. 2007.

