Run-time implementation issues for real-time embedded Ada

A motivating factor in the development of Ada as the department of defense standard language was the high cost of embedded system software development. It was with embedded system requirements in mind that many of the features of the language were incorporated. Yet it is the designers of embedded systems that seem to comprise the majority of the Ada community dissatisfied with the language. There are a variety of reasons for this dissatisfaction, but many seem to be related in some way to the Ada run-time support system. Some of the areas in which the inconsistencies were found to have the greatest impact on performance from the standpoint of real-time systems are presented. In particular, a large part of the duties of the tasking supervisor are subject to the design decisions of the implementer. These include scheduling, rendezvous, delay processing, and task activation and termination. Some of the more general issues presented include time and space efficiencies, generic expansions, memory management, pragmas, and tracing features. As validated compilers become available for bare computer targets, it is important for a designer to be aware that, at least for many real-time issues, all validated Ada compilers are not created equal

Ada (trademark) projects at NASA. Runtime environment issues and recommendations

Ada practitioners should use this document to discuss and establish common short term requirements for Ada runtime environments. The major current Ada runtime environment issues are identified through the analysis of some of the Ada efforts at NASA and other research centers. The runtime environment characteristics of major compilers are compared while alternate runtime implementations are reviewed. Modifications and extensions to the Ada Language Reference Manual to address some of these runtime issues are proposed. Three classes of projects focusing on the most critical runtime features of Ada are recommended, including a range of immediately feasible full scale Ada development projects. Also, a list of runtime features and procurement issues is proposed for consideration by the vendors, contractors and the government

Applying Ada to Beech Starship avionics

As Ada solidified in its development, it became evident that it offered advantages for avionics systems because of it support for modern software engineering principles and real time applications. An Ada programming support environment was developed for two major avionics subsystems in the Beech Starship. The two subsystems include electronic flight instrument displays and the flight management computer system. Both of these systems use multiple Intel 80186 microprocessors. The flight management computer provides flight planning, navigation displays, primary flight display of checklists and other pilot advisory information. Together these systems represent nearly 80,000 lines of Ada source code and to date approximately 30 man years of effort. The Beech Starship avionics systems are in flight testing

Debugging tasked Ada programs

The applications for which Ada was developed require distributed implementations of the language and extensive use of tasking facilities. Debugging and testing technology as it applies to parallel features of languages currently falls short of needs. Thus, the development of embedded systems using Ada pose special challenges to the software engineer. Techniques for distributing Ada programs, support for simulating distributed target machines, testing facilities for tasked programs, and debugging support applicable to simulated and to real targets all need to be addressed. A technique is presented for debugging Ada programs that use tasking and it describes a debugger, called AdaTAD, to support the technique. The debugging technique is presented together with the use interface to AdaTAD. The component of AdaTAD that monitors and controls communication among tasks was designed in Ada and is presented through an example with a simple tasked program

Steps to an advanced Ada programming environment

Conceptual simplicity, tight coupling of tools, and effective support of host-target software development will characterize advanced Ada programming support environments. Several important principles have been demonstrated in the Arcturus system, including template-assisted Ada editing, command completion using Ada as a command language, and combining the advantages of interpretation and compliation. Other principles, relating to analysis, testing, and debugging of concurrent Ada programs, have appeared in other contexts. This paper discusses several of these topics, considers how they can be integrated, and argues for their inclusion in an environment appropriate for software development in the late 1980's

The implementation and use of Ada on distributed systems with reliability requirements

The issues involved in the use of the programming language Ada on distributed systems are discussed. The effects of Ada programs on hardware failures such as loss of a processor are emphasized. It is shown that many Ada language elements are not well suited to this environment. Processor failure can easily lead to difficulties on those processors which remain. As an example, the calling task in a rendezvous may be suspended forever if the processor executing the serving task fails. A mechanism for detecting failure is proposed and changes to the Ada run time support system are suggested which avoid most of the difficulties. Ada program structures are defined which allow programs to reconfigure and continue to provide service following processor failure

The flight telerobotic servicer: From functional architecture to computer architecture

After a brief tutorial on the NASA/National Bureau of Standards Standard Reference Model for Telerobot Control System Architecture (NASREM) functional architecture, the approach to its implementation is shown. First, interfaces must be defined which are capable of supporting the known algorithms. This is illustrated by considering the interfaces required for the SERVO level of the NASREM functional architecture. After interface definition, the specific computer architecture for the implementation must be determined. This choice is obviously technology dependent. An example illustrating one possible mapping of the NASREM functional architecture to a particular set of computers which implements it is shown. The result of choosing the NASREM functional architecture is that it provides a technology independent paradigm which can be mapped into a technology dependent implementation capable of evolving with technology in the laboratory and in space

Model-driven engineering approach to design and implementation of robot control system

In this paper we apply a model-driven engineering approach to designing domain-specific solutions for robot control system development. We present a case study of the complete process, including identification of the domain meta-model, graphical notation definition and source code generation for subsumption architecture -- a well-known example of robot control architecture. Our goal is to show that both the definition of the robot-control architecture and its supporting tools fits well into the typical workflow of model-driven engineering development.Comment: Presented at DSLRob 2011 (arXiv:cs/1212.3308

An Ada implementation for fault detection, isolation and reconfiguration using a fault-tolerant processor

The design and implementation, in Ada, of the Fault Detection, Isolation, and Reconfiguration (FDIR) Manager for the triply redundant, tightly synchronized, Fault Tolerant Processor (FTP) are covered. It also examines the suitability of Ada, in the context of the FTP, for real time control tasks. The operational concepts behind the FTP are explained, and the structure of the resultant Ada code is discussed

Distributed Ada: Methodology, notation and tools

The task of creating software to run on a distributed system brings with it many problems not encountered in a uni-processor environment. The designer, in addition to creating a solution to meet the functional requirements of the applicaiton, must determine how to distribute that functionality in order to meet the nonfunctional requirements such as performance and fault tolerance. In the traditional approach to building distributed software systems, decisions of how to partition the software must be made early in the design process so that a separate program can be written for each of the processors in the system. This design paradigm is extremely vulnerable to changes in the target hardware environment, as well as being sensitive to poor initial guesses about what distribution of functionality will satisfy the nonfunctional requirements. The paradigm is also weak in that no compiler has a complete view of the system. Many of the advantages of using a powerful language system are lost in a one-program-per-processor environment. Another approach to the development of distributed software systems, Honeywell's Distributed Ada program, is presented