Using Analytical Approaches for High Integrity Ada95 Systems Stephen Michell Maurya Software 29 Maurya Court, Ottawa, Ontario K1G 5S3 Canada Email: steve@maurya.on.ca Dan Craigen, Mark Saaltink ORA Canada 100-267 Richmond Road Ottawa, Ontario K1Z 6X3 Canada Email: dan, mark@ora.on.ca Abstract The paper reports on a recently completed analysis of the suitability of Ada95 for use in high integrity systems, describes the status of real-time features in this analysis, and identies how the analysis could be extended to admit more features needed for real-time programs. 1. Introduction The authors have recently completed an analysis of Ada95 for use in high integrity systems. This work used an analytical approach to assess Ada95 language features according to a specic set of criteria. When considering the results of the analysis, one nds that much of the Ada95 language that is of interest to realtime and embedded systems is excluded. We believe that, even with further traditional analysis, many of the desired constructs would be unsuitable for a variety of reasons. In order to consider the incorporation of such features, it is necessary to rethink the premises on which the original analysis was based, and to nd ways of extending the language analysis to include the implementation and the application. 2. The Analysis Framework Our analysis of Ada95 began with a review of several signicant standards for critical systems: DO-178B, MoD 00-55, MoD 00-56, and the Canadian Trusted Computer Product Evaluation Criteria. In this review, we identied four themes that are required of software for high integrity software, and further developed ten analytical categories and ratings in each category to enable us to evaluate any language used in the development of such systems. These categories and ratings within the categories are described in detail in [3] and summarized below. 2.1. Themes The suitability of any language to ll a specied role is determined by its ability to meet the criteria that role imposes. For high integrity systems, our analysis of various development standards identied four broad criteria: predictability, analysability, traceability, and engineering. These criteria provide the litmus test of suitability for any language to be used in the development of high integrity systems. As described in detail in [3], these criteria demand: Predictability: The language must be well-dened, so that the eect of a program can be determined.
The language should have few implementation dependencies and should be simple, so that interactions between language features do not give unexpected behaviours. Analysability: To support tractable analysis, the language should provide encapsulation and protection mechanisms that allow parts of programs to be analysed independently. Traceability: At the highest levels of integrity, it is necessary to trace source code to object code. This discourages the use of sophisticated language features that require extensive run-time support or that may be implemented by discontiguous code. Engineering: The safety standards we reviewed all stress the importance of good software engineering practices, and furthermore allow for the use of engineering approaches that contain the most critical parts of a system within a subsystem. An ideal language for use in high integrity systems therefore supports encapsulation, and supports software engineering by preventing or detecting programming errors, providing abstraction and encapsulation mechanisms, and restricting the use of any \loopholes" such as potentially unsafe operations or violation of encapsulation mechanisms. 2.2. Categories and Ratings In order to determine if an individual language feature is suitable for use in high integrity systems, the feature is evaluated in ten categories which represent the needs of high integrity software. Each category has a three-way scale that evaluates a feature's \goodness" in that category. Each language feature was rated in two ways. The feature was restricted to achieve the best possible ratings, and the feature was evaluated as part of the full and unrestricted language. The detailed analysis of Ada95 features follows the organization of the Ada95 Reference Manual [1]. The categories used during the analysis phase are discussed below. We have not included the possible ratings for each category; these are available in [2], in [3], and at http://www.ora.on.ca/ada95.html. 2.2.1 Run-time Support Needed This category attempts to assess the run-time support needed for each topic area. Support code makes traceability more dicult to achieve, because it is dicult to determine from the source code where such code would exist in the object code. The run-time support code used by an Ada system can be additional code generated by a compiler to implement language requirements while a module is being compiled, or additional (pre-compiled) code which is linked into the execution module. 2.2.2 Functional Predictability This category rates the predictability of the values of outputs or, for concurrent systems, the sequence of interactions or outputs. 2.2.3 Timing Predictability This category rates the predictability of the time required for certain computations. It is important to know whether a given operation will nish before its deadline. This is aected by data-dependent calculations, such as series expansions, complexity of an algorithm, or inexact schedulability due to tasking or interrupts. 2.2.4 Space Usage Predictability This category rates the predictability of the amount of storage space required for a computation. This includes stack space, heap space, statically allocated space, and any other storage used in the implementation. 2.2.5 Formal Denition A formal denition of a language (or language subset) provides an unambiguous description of the eect of each language construct, and can be used to determine the result of executing a program. Formal denitions promote predictability of language features. 2.2.6 Integrity and Security Issues There are two major areas of concern. First, integrity violations occur when a user gains access to a module which was intended to be hidden, in order to update or alter data. Examples are the private child library package, written by the user after the system is written, gaining unintended access to parent \private" components; and erroneous execution violating the integrity of the program, data, or les. Secondly, security or access violations occur when data can be covertly copied from a protected area to a less restricted area without going through normal checks.
2.2.7 Reliability and Engineering Support This category attempts to rate the contribution of each language feature, or combination of features, to reliability and safe software design. Some language constructs enhance the safe construction of software systems. Language features such as the enforcement of type conformance rules in assignment and subprogram calls, or the modularity enforced by packages, package bodies and private parts, reduce errors and improve the compiler's ability to detect the misuse of objects, parameters, or attempted access to non-local items. Other language constructs are believed to be error-prone in that they are hard to use, dicult to understand, or complex (e.g., the \goto" statement and unchecked conversion). 2.2.8 Robustness Robustness is the ability to proceed with the primary functions of an application, despite errors in portions of the application. The opposite of robustness, fragility, is the susceptibility of the primary software functions to errors in data, time (such as an overrun in a real-time application) or subcomponents. Some language constructs are intended to assist in developing code which tolerates faults or bad data. For example, protected types control the access to shared data structures, hence prevent errors associated with reentrant code and shared variables. Some language constructs contribute to the fragility of a program. Global variables in the presence of tasking or interrupts may become corrupted unless they are further constrained by mechanisms to serialize access. Similarly, a composite object can be corrupted by an exception during assignment. 2.2.9 Static Analysis Static analysis is the process of evaluating software without executing the software. It comprises a range of analyses, such as subset analysis, metrics analysis, control ow analysis, data use analysis, information ow analysis, and semantic analysis or path function analysis. Static analysis is usually performed, using software tools, on source code to verify each software component against the lowest levels of the design. It may require annotation of the source code. In many cases, analysis is theoretically possible, but may be intractable in the general case. We therefore evaluate the tractability of analysis in the major static analysis domains. 2.2.10 Dynamic Analysis Dynamic analysis is the verication of software through the examination of the computer system (inputs, outputs, memory, processor states, and timing) as the program is executing. Tools are used to examine many aspects against predictions made before execution. Coverage analysis, memory usage, data monitoring, output monitoring, resource monitoring, and intrusive testing are some of the techniques used in dynamic analysis. As with static analysis, analysis may be theoretically possible, but intractable in the general case. We therefore evaluate the tractability of analysis in the major dynamic analysis domains. 3. Results of Analysis The analysis of Ada95 employed a section-by-section study of the Ada Reference Manual, analysing each language feature in all categories identied in the framework phase. Most features were given two ratings: rst, the best possible rating (with an explanation of what restrictions allow this rating to be attained), followed by the rating for the unrestricted feature. Where there are many interactions involving a feature, it was sometimes given additional intermediate ratings. The detailed analysis is described in [4]. We conclude that Ada95 is suitable for the development of high integrity systems, if its use is restricted to those features (and combinations of features) that achieved good ratings in our analysis. The language features identied result in a subset of Ada95 that we believe is suitable for the development of high integrity systems. This subset retains support for good software engineering practice while eliminating those features or combinations of features that impede the predictability, analysability, or traceability of programs. The details of this subset are described in [4] and briey as follows: Objects: Types: { Use static initializing expressions whenever possible. { Do not declare stand-alone objects with indenite subtypes (e.g., class-wide types or unconstrained composite subtypes). { Avoid access types. { Avoid discriminants. { Derived types can be used with restrictions. { Floating point must be used with caution; precision analysis is dicult.
{ Record types are acceptable. { Arrays can be used if their bounds are static. { Tagged types can be used if derivation is con- ned to a single scope. Expressions: { Avoid most type conversions, allocators, concatenation. { Analyse numeric operations for overow and precision. Statements: { Other than \for" loops, timing of loops is hard to analyse. { Avoid \return" or \exit" from any block with an exception handler or local declaration requiring nalization. { Avoid tasking statements (\abort", \select",...) and \goto" statements. Subprograms: { Avoid aliased parameters, indenite return types, propagation of exceptions, default expressions, anonymous access types, and sideeects in functions. Packages: Tasks: { Private types and operations are usable with slight restrictions. { Child packages can be used, but slightly complicate analysis. { Avoid controlled types. { Tasks cannot be used, but research is suggesting a very limited subset. { Entryless protected objects might be usable for interrupt handling. Program Structure: { Avoid dependence on elaboration order. { Keep bodies close to declarations. { Use pragma Elaborate_Body. Exceptions: { Explicitly raised exceptions can be used, but at a cost. { Exceptions raised by failures of languagedened checks should be avoided. Generics: { Usable in limited ways in some implementations (but not in \shared" implementations). Representation Clauses: { Avoid if possible. If needed, conne their effects to a small region of code (ideally, in a subprogram or package body). As can be seen, many features needed for real-time systems are not allowed or are highly restricted in this subset. Annexes D and H of the Ada Reference Manual provide various restrictions that can be imposed on a partition. These restrictions are not fully in agreement with the restrictions suggested by our analysis, although there is signicant overlap (such as Max_Tasks=>0 and No_Implicit_Heap_Allocation). 4. Application to Real-time Systems The analysis that we did on this project leads us to conclude that signicant portions of the language must be avoided or severely restricted for high integrity real-time or embedded systems. Nevertheless, the recommended portion of the language includes many of the features needed by in real-time programs (although sometimes in a restricted form): representation clauses are permitted so long as their denition is kept inside a package body or subprogram body and composite objects that have representations applied are not type-converted to a related type using the predened language mechanisms. generalized access types can be used along with aliased arrays of records to implement user-dened storage management, as long as aliased objects are not also subjected to other representation specications and the algorithms that access and manipulate the objects can be statically analysed. a limited form of OOP is permitted, as long as there are no partial views of tagged types, no derivation outside the package that contains the ultimate ancestor, and no private dispatching operations. The language subset we dene is larger than SPARK, Penelope, or any other one dened for Ada83.
This is because Ada95 is more static, has tightened language rules and made language syntax more independent of other features, and because Ada95 provides explicit mechanisms, such as pragma Restrictions, to eliminate language features and their run-time effect from a program. Timing of program segments and the static prediction of timing bounds are important considerations in real-time systems. The constructs recommended in our guidance document have bounded behaviours that assist in such analysis. Many constructs can have hardto-predict behaviours, such as recursive calls or loops based on dynamically bounded ranges, but the language features recommended have well-dened timing behaviours in themselves, hence should not introduce surprises. 5. Outstanding Challenges In many ways, the recommended language subset falls short of the requirements of real-time systems. There are several challenges to be faced in expanding this subset. 5.1. Restrictions too Heavy The pragma Restrictions choices were often directly applicable to the constraints that we recommended. Sometimes, however, we had to conclude that the restriction was too heavy to be as useful as we wanted. For example, the restriction No_Unchecked_Conversion must be applied as a conguration pragma, forbidding the generic routine Unchecked_Conversion in any user code. Many projects will decide that they need to use Unchecked_Conversion in a very limited way under tight management controls. Such projects will be forced to drop the restriction, and develop sourcebased analysis tools to monitor the usage on their own. There are several restrictions, such as No_Exceptions or No_Nested_Finalization, that could be applied to individual compilation units, possibly simplifying the implementation. There should be some mechanism to allow for such \local" application of the restriction pragmas. 5.2. Syntax Extension The analysis done was performed in the context of the Ada language as dened by the Ada95 ARM. When the underlying implementation is known, it is possible to permit more of the language to be used. For example, if one knows how objects of indenite types are handled, it may be possible to permit some classes of unconstrained or indenite types, such as unconstrained function returns or type conversions of composite objects with dierent representations. The detailed analysis done on Ada95 is publicly accessible and projects thinking about using features that we did not recommend can examine our premises and conclusions in light of the known implementation. 5.3. Concurrency The management of concurrency is a major challenge for most real-time or embedded systems. Realworld inputs are almost always faster than, or asynchronous to, the coding cycles of the program. Handling them requires interrupt service routines, completion routines, threads, or tasks, although current high integrity language subsets forbid all expressions of concurrency. There appear to be a number of ways that concurrency can be introduced into high integrity Ada programs: 1. Permit protected objects with no Ada tasks. Protected objects are the Ada language-dened mechanism to capture interrupts and deliver them safely to the program's execution environment. When an interrupt-based protected object is used without tasking or protected entries, the main procedure must poll a protected subprogram to collect data deposited by interrupt-level protected subprograms. The protected object semantics guarantee sequential access to the critical region and provide the facility to express the interrupt service routine code in a high level language. 2. Minimal Ada tasks. A subset tasking environment appears possible where the following scenario is provided. Library-level tasks are declared. Each task has its own unique priority, and will run until blocked at that priority level. No preemption is permitted; priority only serves to control the choice between tasks becoming unblocked and competing for a resource. All tasks voluntarily block within a bounded time, which is statically predictable or bounded. The maximal wait time for any task is then predictable. Communication with other tasks or ISRs is through protected subprograms and variables declared inside protected objects.
This scenario will require a minimal Ada95 tasking run-time system. It is anticipated that a specialpurpose task dispatching policy will be required. 5.4. Examination of Other Pragmas Pragmas Restrictions, Task Dispatching - Policy, Locking Policy, and others dened in the appendices of the Standard, furnish ways to constrain an implementation or a program's use of features. An implementation might take advantage of such a pragma to eliminate some run-time calls or simplify the implementation of the restricted features. An analysis tool could take advantage of such a pragma to reduce the number of cases that must be considered. This simplied implementation and easier analysis might allow some features needed for real-time programs to be allowed in high integrity systems when the appropriate pragmas are applied. We recommend studying classes of features needed in real-time systems, studying the restrictions needed to allow the corresponding Ada construct in a critical system, and assessing the ability of the languagedened pragmas to enforce these restrictions. We expect our analysis framework to be applicable to such a study. References [1] ANSI/ISO/IEC 8652 International Standard. Ada95 Reference Manual, Intermetrics, January 1995. [2] Dan Craigen, Mark Saaltink, and Steve Michell. Ada95 and Critical Systems: An Analytical Approach. Ada Europe, 1996. [3] Dan Craigen, Mark Saaltink, and Steve Michell. Ada95 Trustworthiness Study: A Framework for Analysis. ORA Canada Report TR-95-5499-02, November 1995. [4] Mark Saaltink and Steve Michell. Ada95 Trustworthiness Study: Analysis of Ada95 for Critical Systems. ORA Canada Report TR-96-5499-03, July 1996. [5] Mark Saaltink and Steve Michell. Guidance on the use of Ada95 in the Development of High Integrity Systems. ORA Canada Report TR-96-5499-04, August 1996. 5.5. New Pragmas An interesting possibility also exists to propose new pragmas, or restrictions to pragmas, that would permit the inclusion of functionality which we currently exclude. An example is the denition of a new category of run-time dispatching policy for pragma Task_Dispatching_Policy, as described in Section 5.3. Several other new restriction pragmas are suggested by the results of the analysis. 6. Conclusions High integrity real-time systems are challenging; for high integrity, one needs a simple, predictable, welldened, and easily analysed language; for real-time systems, one needs features that give access to the underlying hardware, allow external devices to be controlled, and support concurrency or interrupts. Our analysis of Ada95 systems has identied portions of the language that are suitable for the construction of high integrity systems. This subset includes some, but not all, the features required for real-time systems. We have discussed several approaches to expanding this subset. Further analysis and research is required.