Open systems architecture solutions for military avionics testing

Raytheon makes extensive use of open systems architecture methods in developing special test equipment (STE) for testing military avionics equipment. Such use has resulted in significant cost and schedule savings in the development of production test equipment for radar and infrared systems. With open systems architectures, a test system can be assembled using COTS products. This brings economies of scale to test equipment, which is normally built in very low quantities. Therefore, the potential cost savings due to COTS usage is proportionately greater in STE than in the higher volume avionics systems that are tested. A second major benefit of using COTS products is that test system development schedule cycle time is greatly reduced. This paper describes the application of Open Systems Architectures (OSA) to avionics testing. The following major architectures are surveyed: VME bus, VXI bus, IEEE GPIB, IEEE 1149.1 JTAG test bus, 1553 Military Bus, Fibre Channel, and COTS Test Applications Software. We describe how the benefits of OSA have been extended at Raytheon into achieving vertical test commonalities. The flexibility of OSA can be exploited to provide an overall optimum test solution, taking all levels of test into account. For example, test systems can be tailored with COTS products to provide integrated methods for avionics tests at the module, unit, and system levels. Test systems can be configured to maximize the reuse of COTS hardware over all test levels. Test software can also be programmed to optimize such reuse over levels of test. Additional test verticality synergies derived from such OSA usage are described, including: test false alarm avoidance; test cones of tolerance optimization; and efficient test of field returns     

COTS器件管理要求研究

通过对COTS 器件使用风险和管理现状进行说明,对国内外电子器件管理要求的分析和研究,提出 了针对COTS 器件管理的适航要求建议,期望能达成限制机载设备中COTS 器件使用的风险,提升机载设备可 靠性及民用飞机安全性的目的。     

The cost of COTS

Fairchild Defense, a division of Orbital Sciences Corporation, has been a pioneer in the use of Commercial-Off-The-Shelf (COTS) hardware, software, and tools in military equipment. Fairchild has developed a cost and schedule effective approach to the use of COTS elements. This paper discusses Fairchild's experience with the use of COTS in military equipment and special considerations imposed because of the military environment     

Development of a TPS reuse library using COTS tools

In the past, functional test requirements (FTR) or test requirement documents (TRD) and test program sets (TPS) were standalone items developed by individual engineers. In some cases, one engineer would write the FTR/TRD and another would develop the TPS. Commercial ATLAS FTRs are prepared in ARINC 616 and 626 ATLAS. Military TRDs are written in IEEE ATLAS 716 versions. Previous test reuse attempts have not been successful because additional software, like browsers, is required to support these efforts. It was difficult to justify writing new software; for example, browsers to manage the application software. Today, commercial-off-the-shelf (COTS) tools are in place to browse and view information from circuit diagrams to documents to source code. These tools can develop hierarchies to organize the information. These COTS tools are available throughout Boeing on many types of workstations and personal computers on every engineer's desk. This paper discusses how a reusable test library (RTL) is being developed using commercial-off-the-shelf (COTS) tools, such as Mosaic, to address commercial and military test applications. It describes each of the tools and the process to develop TPSs using the reuse library. It defines the metrics and benefits achieved     

ROSA Rotorcraft Open Systems Avionics

Commercial standards adopted from the volume-driven electronics markets provide improved processing capacities over those widely used military standards and at reduced cost. Desired future capabilities and advanced functions, such as RPA, require the throughput, bandwidth, and memory provided by commercial processors and data buses. The primary issues needing resolution prior to implementation are related to operations in military rotorcraft environment, reliability, redundancy management, and fault and battle damage tolerance. In addition, some required network components presently do not exist in the preferred form factors. The ROSA project is providing effective laboratory demonstrations of COTS products and open systems specifications and standards to rotorcraft avionics. Preliminary cost estimates forecast large potential savings and create a compelling business case for follow-on research and transition to production systems. In addition, the project is developing a Rotorcraft Technical Architecture with the participation of many industry partners and will promote the resulting documentation as background materials for the JTA-A     

Continuing challenges in lithium battery development

In these days of emphasizing standardization, Acquisition Reform, Non-Developed Items (NDI) and Commercial-Off-The-Shelf (COTS) technologies, we are facing new challenges associated with these trends. Program managers are pressured to use a standard or COTS battery, while simultaneously, the new systems being developed have increasingly complex and demanding power requirements. Hardware must be developed with shorter schedules, and policies of Acquisition Reform limit the amount of control the government has over the development of a given item. In this paper, we review battery development efforts that have resulted in unexpected problems. Relevant data from both current and past test programs are presented. Recommendations are provided concerning how to best avoid duplication of effort, while ensuring that the final product will have the best chances of succeeding     

Reconfigurable COTS test systems

Automatic Test Equipment (ATE) systems are used to qualify, accept, and troubleshoot electronic products. ATE systems may be in the form of large general-purpose systems that can test a wide variety of products or the more commonly used custom, turnkey systems that are designed for specific test application(s) and requirements. Turnkey ATE systems are labor-intensive; as a result, even a relatively simple turnkey tester is costly and may take months (or even years) to develop, integrate, and deploy. The main reason for this aspect of turnkey ATE systems is that even though the instrumentation may be off-the-shelf components, most everything else is custom and requires design, development, extensive debug and integration. Time and again, systems integrators have tried to find a solution that would combine the cost effectiveness of COTS systems with the flexibility of custom ATE. This paper suggests a solution to this problem and that it is feasible to combine COTS testers with custom requirements. This solution, called CreATE, provides a flexible architecture using COTS components (including instruments, cabling and interfacing products)     

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     

Vertical test integration

Today, most every weapon system is electronics intensive. Digital computers are at the core of military aircraft, ship, and vehicle weapons systems. Indeed, each weapon system's performance is largely determined by its digital computers and other electronics. This electronics dependency is necessary in order to provide the speed, functional compliance, and accuracy to achieve the required weapon system performance. Historically, test systems required for the various maintenance levels and also at the manufacturing site have each been uniquely developed, employed, and sustained for only one area of weapon system electronics support. There are a number of reasons for this situation including different organizations responsible for the levels of support, different funding sources, timing limitations, and technical feasibility. In recent years, however, commercial-off-the-shelf (COTS) advances in measurement and stimulation hardware, personal computers, Windows operating systems, flexible test programming languages, and more, have made it technically feasible to develop a family of test systems that provide common weapon system electronics support at all levels. Some use the phrase Vertical Test Integration to describe this concept of factory/field/depot integration     

Next generation space avionics: layered system implementation

Advances in electronics over the past decade have produced major improvements in the power and flexibility of computer systems. Unfortunately current avionics systems for space applications typically have not leveraged these COTS advantages. A decade ago, the state-of-the-art for avionics systems made a step change to the Integrated Modular Avionics (IMA) used in the Boeing 777. This next generation avionics architecture is not based upon traditional Byzantine redundancy structures, but on a truth-based scheme where each element knows when an internal failure occurs and removes itself from the system. IMA utilizes a lock-step microprocessor design that communicates to a COTS Backplane for input/output, and to a Virtual Backplane/spl trade/ (a reliable high-speed serial bus) for intra-system communication. The system functions are implemented using a time and space partitioned operating system. The entire system provides the simplicity of a simplex system, implements the highest level of reliability providing complete flexibility to reconfigure both software applications and hardware interfaces, allows for rapid prototyping using low-cost COTS hardware, and is easily expandable beyond the initial point implementation. As the only 5/sup th/ generation avionics architecture, the concepts incorporated into Honeywell's IMA are ideally suited to be the backbone of the next generation Space Exploration Program avionics architectures.     

IMA aircraft improvements

Integrated modular avionics (IMA) is being suggested as the means by which new capabilities can be deployed on aircraft at an affordable cost. RTCA SC-200 is presently considering the guidance document for IMA. All of the functionality that IMA offers can be achieved through a conventional federated architecture; however, the cost, size, and weight penalties of the federated solution make it economically infeasible. IMA is seen as the way forward. It is assuming greater importance as the aircraft industry transitions to commercial-off-the-shelf (COTS) technology with its attendant obsolescence and reliability concerns. IMA may be one of the most cost-effective ways by which rapid obsolescence can be managed. Ironically, this move to COTS is also the greatest threat to IMA systems. IMA achieves reductions in size, cost, and weight by providing a set of flexible hardware and software resources that can be statically or dynamically mapped to a set of required avionics functional capabilities. This introduces a number of new complexities such as mixed criticalities and reconfiguration. We do not address these issues herein. Rather we discuss the mechanisms by which electronics degrades and how a classical safety assessment of a reconfigurable IMA system can be ified by this degradation. We argue that, with the advent of COTS, it is no longer justifiable to consider that electronics has an effectively constant failure rate. Physical considerations suggest that electronics failure occurs when environmental and operating stress causes the accumulation of damage to the underlying structures to exceed the threshold strength of the constituent materials and interfaces. Finally, we suggest how finite-life electronics effects may be mitigated.     

Potential defense applications of expert systems

The authors provide an overview of expert systems and how they may effect the development of future defense applications. Military uses of computers are outlined, and expert-systems fundamentals are described. Artificial research and development efforts by the military are examined, and potential military applications are discussed. Expert systems efforts at NASA, by the US Air Force, and for the Strategic Defence Initiative are considered     

Use of service history for certification credit for COTS [avionic software]

Much has been written in the last ten years about how the use of commercial-off-the-shelf (COTS) components would revolutionize the aerospace industry avionics, communication, navigation, surveillance/air traffic management (CNS/ATM) as well as global air traffic management (GATM). Civil aviation authorities around the world have been faced with numerous requests to certify aircraft containing increasing percentages of COTS components, much of it never designed or intended for use in the safety critical environment of an aircraft. Product service history is one method for demonstrating that such software is acceptable for use. In theory, product service history would seem to be a fairly simple concept, both to understand and to apply. However, in practice, such use has proven extremely problematic, as questions of how to measure the historic performance and the relevance of the provided data have surfaced. This paper elaborates a research effort funded by the United States Federal Aviation Administration to collect, analyze, and synthesize what is known and understood about applying product service history. The effort is limited to the topic of software product service history as applied in the certification of airborne systems and equipment.     

Safety tests of lithium 9-volt batteries for Navy applications

COTS batteries are relatively inexpensive, readily accessible, and extremely versatile. These attributes allow the military to save time and money during the research and development stages. Of these COTS batteries, a 9-Volt (9 V) lithium/manganese dioxide battery is the subject of this paper. This 9 V battery has the ability to provide a low magnetic signature, which is very important to the Navy for many applications, Also, it is Underwriters Laboratories (UL) listed at the unit level; however, these UL tests cannot be directly related to the safety of these 9 V batteries when they are combined in various series and parallel configurations. Naval Surface Warfare Center (NSWC) Carderock was tasked to rate the safety of several such specialized battery packs. It was found that packs consisting of two 9 V batteries in parallel were relatively safe, experiencing no violent behavior. Battery packs with six 9 Vs in parallel vented and deformed the 9 V batteries, but no smoke or flames were noticed. A battery pack with thirty 9 V batteries, 2 in series with 15 legs, experienced venting, smoke, and flames under certain circumstances, After testing, the six and thirty 9 V packs were required to include the addition of various safety devices     

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.     

可实时重构的国际C站卫星模拟器

我国自行研制的国际标准C频段统一测控系统,配置了功能齐全的卫星模拟器,但其一星一模拟器的方式已不能适应当前多星管理和未来星座管理的需要。本文旨在探讨利用现有的微波宽带器件技术和软件无线电技术,用一套硬件系统,根据需要实时重构成所需卫星的模拟器,达到多星共用一套模拟器,实现小型化、实时性的目的。     

Multi-computer VXIbus system set up and use

VXI has matured into a flexible bus architecture with which to develop various types of instrumentation systems. This paper details the multi-computer approach used in the VXI-based system that CACI developed for the Air Force. The system, the Engine Test/Trim Automated System II (ETTAS II) is designed to test: all Air Force jet engines. The paper discusses how to integrate multiple computers in a VXI-based system, including discussions on: setting up the computers; selecting register-based versus message-based computers; setting up and using shared-memory; defining and separating tasks for each computer. The shared memory discussion talks about different ways to structure the shared memory, including setting up a system-level “Current-Value Table” (CVT) for all instruments, as well as how other devices, including another computer can access the shared memory space. The paper shows how Commercial-Off-the-Shelf (COTS) software products NI-VXI, LabVIEW, and NI-VISA (National Instruments) can be used to satisfy all these requirements. The paper shows how the multi-computer approach can be cost-effective in many cases     

Selecting a programming language for your project

Since the mandate was dropped that the Ada language had to be used in all DoD projects, software managers have had more freedom to choose which programming language to use on their DoD projects. For most new DoD software projects that need a general purpose high-level language, Ada, C, or C++ are the main contenders, with increasing attention paid to the new language celebrity, Java. Furthermore, multilanguage systems seems to be getting increasingly popular. As a result, companies offer integrated multilanguage programming environments. Although each programming language has its own strengths and weaknesses, the reason for choosing a particular language may ultimately be based on factors having nothing to do with the technical merits of the language itself. Such factors may include the availability of compilers for the host/target, the maturity and efficiency of available compilers, the availability of programmers who already know the language, whether the language can easily interface with existing systems such as graphical user interfaces or data bases, the existence of legacy software written in a specific language, or how well the language fits in with adopted COTS products. A few common misconceptions that may affect the choice of a programming language are listed     

Open systems-a process for achieving affordability [in avionicssystems]

A major factor that will drive the definition and design of future avionics systems is affordability. Affordability is being addressed on numerous fronts such as hardware re-use, software re-use, COTS leveraging, and reduced cycle times. Each of these thrusts provide potential cost savings along with unique challenges. What is needed is a process that integrates these initiatives while ensuring the overall system objectives are achieved. An Open Systems-based process is key to integrating these initiatives and balancing affordability and system performance goals. Although Open Systems are being widely recognized as a key to affordability, most interpret Open Systems as a set of system attributes that need to be achieved. There are numerous claims of vendors saying they have an Open Systems architecture or how their system will evolve to an Open Systems architecture. This emphasis is not on increasing affordability but on attaching a politically correct label to their product. In this paper, we focus on the Open Systems process as the key to affordability. An Open Systems process is based on Open Systems principles. This paper discusses the Open Systems principles and process in detail and shows how this process integrates numerous affordability initiatives     

基于COTS的航空电子软件开发

介绍了商用货架产品(COTS)在航空电子软件开发中应用的优点和缺点,和基于COTS的航电软件构架;并给出了一个开发过程和部分开发工具。最后通过一个实例说明基于COTS的航电软件开发是实际可行的。