Reducing the risks of using Ada onboard the Space Station

The Ada programming language was chosen by NASA as the primary computer programming language for the development of new software for the US Space Station. Ada was selected based on the results of investigations coordinated through Johnson Space Center (JSC) and that resulted in the identification of a set of problems and risks associated with using software developed in Ada. Some of the specific solutions to problems identified through these investigations are described. Three areas in which Ada's use poses risks are discussed: real-time process control; the testing and verification of flight software for man-rated systems; and software error detection, identification, and recovery required in safety-critical systems     

假如使用Ada语言

介绍了Ada语言的应用现状及其前景,并通过一项实验说明Ada语言比C语言更适合于航空电子软件开发。     

Spiral evolution applied to legacy avionics systems

The US Department of Defense (DoD), through the Office of the Secretary of Defense (OSD), has determined that evolutionary acquisition is their strategy of choice for future software-intensive systems, and that the spiral development model (SDM) is the preferred method/process for software-intensive development life cycles. Electronic Systems Command (ESC) at Hanscom AFB, Massachusetts, has written a draft handbook on the use of Spiral Development for all future Command and Control (C2) systems, including reference to the DoD 5000 series and Air Force Program Directive 63-1, Acquisition System, which deploys this OSD mandate for future C2 systems. Barry Boehm's continued work on SDM which he conceived in the 1980s, is heavily biased toward development of new systems that are software-intensive, as noted in a workshop he gave at the Software Engineering Institute (SEI) in 2000.     

Embedded information system re-engineering

Currently fielded embedded information systems face readiness challenges imposed by evolving missions and extended service lifespans. The ability to overcome these challenges is constrained by such factors as shrinking budgets, limited computational capacity and diminished manufacturing sources effects that impact both hardware and software options. Wholesale redevelopment is often cost prohibitive, particularly since large portions of embedded applications continue to fulfil mission requirements. Solutions must preserve prior investments while providing efficient pathways for continued technology refresh. A technology solution for affordable modernization of legacy system software is being development. The Embedded Information System Re-engineering (EISR) project is developing an automation-assisted JOVIAL-to-C re-engineering capability that permits simultaneous modernization of both the structure and source language of legacy embedded applications. Engineers will be able to apply the proven labor-saving visualization and analysis features of modern CASE tools to legacy JOVIAL applications. EISR will thus allow the DoD to recapture previous investments in proven legacy algorithms and mission capabilities while permitting the full exploitation of COTS economies of scale. This paper describes in brief the goals and objectives of the EISR project, and provides the current status of the EISR capability.     

Sole means navigation in US Navy aircraft

The current edition of the US Federal Radionavigation Plan, issued in 1984, presents a consolidated federal plane on the management of those radionavigation systems which are used by both the civilian and military sectors. It states the US Dept. of Defense (DoD) goal to phase out the use of TACAN, VOR/DME, OMEGA, LORAN C, and TRANSIT in military platforms and for Global Positioning System (GPS) to become the standard radionavigation system for DoD. This would eliminate all the current sole-means air navigation systems (TACAN and VOR/DME) aboard military aircraft. Instrument Flight Rule (IFR) operations within controlled airspace requires an operating sole-means air navigation system to be aboard the aircraft. The authors investigate the requirements for GPS certification as a sole means air navigation system in the US National Airspace System (NAS); discuss the implication for GPS user equipment (UE) hardware and software; describe the actual UE implementation; and discuss approaches for UE integration with flight instruments on US Navy aircraft     

Software architecture requirements for DoD automatic test systems

The DoD has achieved success with recent automatic test equipment (ATE) families, as evidenced by the navy's consolidated automated support system (CASS) and the army's integrated family of test equipment (IFTE) programs. However, as these systems age, the increased requirements for technology insertion due to instrument obsolescence and the demands of advanced electronics are becoming evident. Recent advances in test technology promise to yield reduced total ownership costs (TOC) for ATE which can incorporate the new technology. The DoD automatic test system (ATS) executive agent office (EAO) objective is to significantly reduce total ownership cost. Several objectives have been identified including use of synthetic instruments, support for legacy test product sets (TPSs), and more efficient ways of developing TPSs. The NxTest software architecture will meet the objectives by providing an open systems approach to the system software. This will allow for the incorporation of commercial applications in the TPS development and execution environments and support current advances in test technology     

Methodology for cost-effective software fault tolerance formission-critical systems

A computing capabilities continue to advance, there will be a concurrent rise in the number of both hardware and software faults. These will be caused by the greater volume of more complex software, by the increased number of untested software states, and by more incidents of hardware/software interaction faults as a result of increased hardware speed and density. The traditional software implemented fault tolerance: approaches have been successfully utilized in life-critical systems, such as digital flight controls, where their additional costs can be easily justified. Examples include N-Version Programming and Recovery Block approaches. However, there is still a need for dependable computing for mission-critical applications as well. Often, these traditional techniques are avoided for mission-critical systems due to the difficulty in justifying their extra up-front development cost. We provide an alternative for the high “sunk cost” of traditional software fault tolerance techniques. The methodology, called data fusion integrity processes (DFIPs), is a simple, yet effective technique for mission-critical systems. In addition, the approach establishes a framework from which other costlier, more extensive traditional techniques can be added. We present details of the DFIP methodology and a DFIP framework for Ada programs. We also briefly discuss development of a DFIP code generation system which exploits Java that will enable users to quickly build a DFIP framework in Ada, and select reusable DFIP component methods     

VLSTA: virtual instrument standard test architecture

Diagrammatic programming environments provide a unique challenge for the developers of test software. These cost effective environments facilitate access to technologies such as VXI, provide speedy development of highly effective user interfaces, and eliminate many of the tasks often associated with hardware integration in complex test systems. Nonetheless, difficulties can arise when designing functional and diagnostic test software in this environment. This paper introduces VISTA, a promising new architecture which allows users to elude most of the difficulties of building detailed functional and diagnostic Test Program Sets (TPSs), while taking full advantage of the benefits of diagrammatic programming environments. Here we examine an implementation of the VISTA architecture, the integration of advanced diagnostics, and the use of diagrammatic programming as a test language cross compiler     

Rationale for the development of the UK defence standards forsafety-critical computer software

Changes in the procurement environment and developments in technology that will require the adoption of new development certification procedures within the next few years are examined. Characteristics of safety-critical computer systems and the safety problems posed by digital computers are described. The way in which the changes have influenced the preparation of the new draft defence standards offered for public debate in the UK prior to their formal adoption by the Ministry of Defence is discussed. Principle features of the future safety-critical systems policy are outlined. The use of Ada for safety-critical software is considered     

Surveillance through walls and other opaque materials

The Department of Defense (DoD) has funded a dazzling array of “high tech” solutions for many of the problems facing our military forces. Many of these “solutions” have been effective for long range mass destruction but have not been applicable for the close-in hand-to-hand combat that is on our streets. Our goal at the Hughes AET Center has been to convert “high tech” DoD capabilities into cost effective tools to help law enforcement agencies do their jobs better. Surveillance systems presently used by law enforcement officers make extensive use of television, infrared and other Line-of-Sight (LOS) surveillance systems. However, these systems cannot tell what is happening on the other side of a wall, behind bushes, around the corner, in the dark or through a dense fog. A new sensor has been developed that uses technology developed by the DoD for missile warhead fuzing. This small, light weight, low power “Radar” is based upon the fact that radio waves can penetrate nonmetallic materials. This new surveillance capability can help provide information about what is in a wall, ceiling or floor or on the other side of a door or concrete wall. Real field scenarios are used in this paper to show how this radar works and how field users can tell if someone is moving inside a building, even from remote locations     

A Survey of Software Quality Assurance

This summarizes the authors' research into the state-of-the-practice of software quality assurance (SQA) in software organizations throughout the Department of Defense (DoD). Information was obtained through personal visits to a limited number of software facilities and by utilizing a SQA questionnaire that was mailed to 27 DoD software organizations. Twenty questionnaires were returned from Army, Navy, Marine Corps, and Air Force organizations involved in the Life Cycle Software Support (LCSS) process. The survey developed information regarding such topics as: staffing; personnel qualifications; quality standards used; SQA responsibilities; error data collection; adequacy of existing documentation; staff composition; distribution of SQA effort; and workforce mix. In addition, a list of SQA ``Lessons Learned' was developed from comments made by DoD quality managers. The results of this study indicate a wide variance in the application of SQA within the DoD.     

The defense acquisition system too late for the scalpel; bring outthe meat axe!

The problems discussed include that associated with the requirements process which leads to overspecification and an overly rigid approach to development, and a procurement system which is bloated and grossly inefficient. The bureaucracy in the DoD acquisition system has grown steadily from the 1960's to 1990's. Each problem encountered, and there have been serious ones, has resulted in the addition by the DoD or Congress of another wicket to get through, another set of unended peripheral tasks, another layer of checks, meetings, reports. Each addition was an intended improvement which in the long run has only made things worse. The DoD rightly asked for greater reliability and the reliability/maintainability/availability RMA, cult was born. Recommendations dealing with these problems are discussed     

Sustainment of legacy automatic test systems: lessons learned on TPS transportability

Sustainment of legacy automatic test systems (ATS) saves cost through the re-use of software and hardware. The ATS consists of the automatic test equipment (ATE), the test program sets (TPSs), and associated software. The associated software includes the architecture the TPSs run on, known as the control software or test station test executive. In some cases, to sustain the legacy ATS, it is more practical to develop a replacement ATE with the latest instrumentation, often in the form of commercial off-the-shelf (COTS) hardware and software. The existing TPSs, including their hardware and test programs, then need to be transported, or translated, to the new test station. In order to understand how to sustain a legacy ATS by translating TPSs, one must realize the full architecture of the legacy ATS to be replaced. It must be understood that TPS transportability does not only include translating the original TPS from an existing language (such as ATLAS) to a new language (such as "C") to run on a new test station, but includes transporting the run-time environment created by the legacy ATS. This paper examines the similarities and differences of legacy ATE and modern COTS ATE architectures, how the ATS testing philosophy impacts the ease of TPS transportability from legacy ATE to modern-day platforms, and what SEI has done to address the issues that arise out of TPS transportability.     

Electrodeless ultraviolet communications system

The Laser Communications Laboratory (LCL) of the Wright Laboratory Avionics Directorate is heavily involved in designing optical communications systems covering the full optical spectrum to meet our current and future military communications requirements. This paper summarizes the in-house designed and built solar blind ultraviolet communications system used in the LCL to investigate non-line-of-sight data and voice links. It also summarizes some of the previous DoD work accomplished to exploit free space communications via ultraviolet radiation. In addition, safety factors peculiar to ultraviolet radiation in a closed cockpit environment are addressed. An evaluation of the current electrodeless ultraviolet communications system and a synopsis of planned future projects to improve the system are included in the paper     

捷联惯导系统的软件开发

本文介绍在PC机上开发捷联惯导系统软件并进行数字仿真的方法,讨论了从分配软件任务,到开发实时软件、管理软件、仿真软件,直至固化运行的全过程。还介绍了ASM-86语尔、PL/M-86语言与C语言混合编程的技巧与优点。该方法与传统的在86/380开发系统上开发捷联系统软件的方法相比,具有良好的经济效益与实用价值。同时,本方法具有通用性,可用在以8086为基体的单板机软件开发上。     

COTS based open systems for military avionics

The DoD has many acquisition programs that are aggressively implementing open architecture principles in new avionics systems. Since “open” is an unclear attribute, projects eventually give in to a point solution that has no flexibility to cost effectively keep up with rapid changes in technology. The Open Systems Development Initiative (OSDI) project utilized COTS products to study the feasibility of building an open system that has plug-and-play capabilities. Lessons learned from the AV-8B Open Systems Core Avionics Requirements (OSCAR) and the F/A-18 Advanced Mission Computers and Displays (AMC&D) programs clearly indicated that understanding the underlying interfaces is crucial to keeping the system as open as possible to take advantage of the rapid changes in technology. A matrix of Key Open Standard Interfaces (KOSI), called the KOSI matrix, was developed and an applicable standard was identified for each interface. A list of non-conforming interfaces was also identified and the use of extensions or wrappers was investigated in an attempt to comply with standards. Standardization, rather than optimization of such interfaces, was considered more beneficial. It became evident that, with the exception of ruggedization, there is no difference in the use of COTS products for either commercial or military systems. Performing a KOSI analysis helped identify the key interfaces and standards, thus enabling the OSDI system to be scalable, portable and interoperable. A good KOSI matrix provides a vehicle for clear communication and helps systems integration and technology insertion to be less painful than what it is today. It helps reduce time-to-market and provides guidance to systems engineers and vendors to keep the system open     

A safety kernel for traffic light control

The success of kernels for enforcing security in software systems has led to proposals to use kernels for enforcing safety. This paper presents a feasibility demonstration of one particular proposal for a safety kernel via the application of traffic light control. The paper begins with the safety properties for traffic light control and specifies a kernel that maintains the safety properties. An implementation sketch of the kernel in Ada is given and use of the kernel is discussed. The contribution of the paper is a demonstration that a kernel is a feasible and desirable technique for software in a realistic, safety-critical application. The paper also illustrates how formal methods aid the software engineer in constructing and reasoning about such software     

Automated testing

Since the DoD was the leader in incorporating transistors, ICs and embedded processors, they also were on the forefront in developing automatic test equipment. The term automatic test equipment (ATE) encompasses all phases of computer controlled testing. It is based on the integration of instruments, computers and software. These systems generally include five basic elements: control, stimulus, measurement, switching and software. A special interface device or interface test adapter connects the unit under test (UUT) to the ATE. Test program software connects the ATE to the appropriate UUT test points, programs the input stimulus and monitors the output response     

The J-MASS Marketplace: a new way for DoD to do business

It is current DoD policy to use commercial off-the-shelf software whenever it meets DoD requirements. The application of this policy to modeling and simulation has resulted in the concept of “The Joint Modeling and Simulation System (J-MASS) Marketplace.” J-MASS is designed as an Open Systems Architecture with the capability for the Simulation Support Environment (SSE) to be expanded by the addition of site specific software. In the “J-MASS Marketplace” industry will build commercial tools to work with J-MASS and individual organizations will license what they need for their particular site. The J-MASS SSE is a framework or backplane into which everything else plugs. A J-MASS product release would have the core capabilities, but the unique needs of various organizations would be satisfied by industry. This paper addresses how the J-MASS Marketplace could work and how compliance can be defined. It will outline opportunities for industry in both building software for the Marketplace and in defining the Marketplace concept     

Proposal to TPS delivery in 4 months?

Decreasing the often lengthy Test Program Set (TPS) development time is a high priority for both DoD and commercial industry. A protracted test development time for a commercial product can make or break its success. It can impact time-to-market goals for a product, which in turn, can result in a loss of market share. Though the DoD world has different objectives, they, too, are concerned with long test development times which can increase costs and jeopardize a weapon system's mission readiness. The case study for this paper is a test system developed by BAE Systems in less than four months to meet a commercial customer's stringent schedule requirements. The factors that contributed to the success of this project are examined, as is their relevance to the DoD world. The desire is to apply relevant lessons learned from the commercial industry to DoD programs, yielding a decrease in TPS development time