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     

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     

IEEE 1394: a growing computer connectivity standard for automatedtest

This paper describes the latest trends in the IEEE 1394 (“firewire^TM” or “iLink^TM”) standards and why it is becoming the connectivity standard of choice for automatic test applications. Why move to IEEE 1394, what are the possible risks with doing so, what are some of the myths associated with IEEE 1394 and a practical example of an automatic test application will all be presented with the prime emphasis on giving the latest information that will help you get IEEE 1394 integrated into your automatic test system     

Rapid development of tightly-coupled GPS/INS systems

This paper addresses the question: “Why aren't tightly-coupled OPS/INS systems everywhere, on aircraft, ships and land vehicles?” Two barriers to the widespread use are cited. One is the high cost of the INS, and the other is the cost and complexity of tightly-coupled OPS/INS integration. One of those two barriers has recently been diminished drastically with the development of a standardized software package for tightly-coupled integration. In the past, only the largest corporations have been able to pay the initial development cost for tightly-coupled OPS/INS integration, usually with funding from a large defense program. Using the new software package, integration and van test can be accomplished in a matter of days, and this has been demonstrated with field trials. The package is intended primarily for small companies that otherwise would not be able to build tightly-coupled OPS/INS systems at all. What would have been a prohibitive 3- or 4-man year development effort is reduced to a few man weeks. To accomplish an integration, the system integrator has to find a way, through serial interfaces or by some other means, to get the INS measurements of acceleration (accumulated velocity change ΔV) and attitude rate (accumulated angle change Δ&thetas;) into a processor, along with the raw data of a GPS receiver. He also has to find a way to time tag the INS ΔV, Δ&thetas; with GPS time. The rest of tightly-coupled OPS/INS integration is predominately accomplished in the standardized software package. That leaves the cost of the INS as the only remaining barrier to the very widespread use of OPS/INS, and invites new development of low cost inertial sensors. The focus of this paper is on the software package, and how it achieves standardization and ease of use while retaining the flexibility to produce optimal results with a variety of INS and GPS receiver types     

IVI comes of age: An overview of IVI specifications with current status

IVI stands for Interchangeable Virtual Instruments; the IVI Foundation was formed in 1997 and is a consortium founded to promote standard specifications for programmable test instruments. The foundation focuses on the needs of users who build high performance test systems. By building on existing industry standards, such as VXIplug&play driver concepts, the Foundation's goal is to deliver specifications that simplify interchangeability, provide better performance, and maintainable test programs. To date, only a few IVI drivers have been available. In the past year, the IVI Foundation finished a major revision of it's architecture and has released a blizzard of specifications, increasing its IVI Class specification by 80% and dramatically improving the consistency and quality of released drivers. The DoD has expressed major interest in IVI's success. With the recent successful completion of the current set of specifications, DoD is interested in becoming involved in defining the next set of Class Specifications. The NxTest Working Group lists IVI as a key technical element, and DoD has recently requested that the IVI Foundation consider Electro Optical equipment for their next set of Class Specifications; a Working Group has been formed to more clearly define this activity.     

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     

CALCM-the untold story of the weapon used to start the Gulf War

The Conventional Air Launched Cruise Missile (CALCM) was developed from the strategic ALCM, AGM-86, by integrating GPS navigation into the missile in place of terrain correlation (TERCOM). In addition, the nuclear warhead was replaced by conventional explosives. The CALCM was developed, tested, and fielded in a single year (mid-1986-mid-1987) by the Boeing Company where the author was then employed. Although the GPS technology used, a Rockwell single channel aided receiver, has been eclipsed by newer receivers with additional capabilities and newer technology, many innovative things were done in completing the CALCM integration: the external loading of almanac data along with other mission data, three satellite navigation capability, and the use of a single channel receiver in a dynamic flight environment. This effort demonstrated that GPS outputs can be integrated quickly into an existing weapon system using the traditional loosely coupled “cascaded filter” approach. Although this approach is not as ideal as a tightly coupled integration using raw GPS data, the use of cascaded filters resulted in a weapon that was able to be rapidly fielded. The Air Force had sufficient confidence in the missile, that after four years of operational testing, 35 of these missiles were targeted at key sites at the start of the Gulf War in 1991. This effort, which was declassified in 1992, resulted in the first weapon in the DoD inventory to be operational using GPS navigation. The effort deserves consideration as a model as to how GPS integration can be performed     

The Role of Magnetic Fields in the Interstellar Medium of the Milky Way

Synchrotron radiation is generated throughout the Milky Way. It fills the sky, and carries with it the imprint of the magnetic field at the point of origin and along the propagation path. Observations of the diffuse polarized radio emission should be able to provide information on Galactic magnetic fields with detail matching the angular resolution of the telescope. I review what has been learned from existing data, but the full potential cannot be realized from current observations because they do not adequately sample the frequency structure of the polarized emission, or they lack information on large-scale structure. I discuss three surveys, each overcoming one of these limitations, and show how use of complementary data on other ISM tracers can help elucidate the role of magnetic fields in interstellar processes. The focus of this review is on the small-scale field, on sizes comparable with the various forms of interaction of stars with their surroundings. The future is bright for this field of research as new telescopes are being built, designed for the survey mode of observation, equipped for wideband, multichannel polarization observations.     

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     

Automatic CCTV surveillance-towards the VIRTUAL GUARD

The VIRTUAL GUARD is a general-purpose computer-based CCTV surveillance system for detecting potential criminal activity in public areas. The system monitors all activity in the surveillance area, the vast majority of which is people innocently going about their normal business. It will alarm when the observed activities of particular pedestrians and vehicles match any of the pre-defined “suspicious behaviour criteria” programmed into the system. At the same time as analysing movement behaviour, the system uses computer-controlled pan tilt zoom cameras to obtain close-up video recordings of any pedestrians and vehicles at the scene. The system can provide automatic surveillance in many different situations, from parking areas and commercial districts, to housing, recreational and transport facilities. It is particularly suited to the protection of government or commercial buildings located on city streets or other public areas where it is not possible to install perimeter fences     

如何爱上威士忌

威士忌是真正属于男人的酒,尘世的烟火气味掩饰不了它的天生神韵,如果你从心里接受了它,一生都会是它的信徒,因为它能渗透到你的生命里去。如何鉴别优质威士忌1色泽:拿酒杯时应该捏住杯子的下方杯脚,而不能托着杯壁。因为手指的温度会让杯中的酒发生微妙的变化。在灯光下仔细观察,可以在酒杯的背后衬上一张白纸作为背景。威士忌的颜色有很多种,从深琥珀色到浅琥珀色都有。酒的色泽和威士忌在橡木桶里存放时间的长短密切相关。一般来说,存放时间越长,威士忌的色泽就     

New approaches to weapon system testing or “back to thefuture”

This paper proposes abandoning the use of multipurpose ATE for “horizontal” support of weapon systems in favor of returning to “vertical” support. An R&D effort is proposed to develop a software “hot mock-up” system for field testing weapon system assemblies     

Battlefield awareness via synergistic SAR and MTI exploitation

“Battlefield awareness” is critical to the success of future military operations. Existing and new sensor platforms will provide the necessary surveillance data; DARPA is developing the systems needed to turn the sensor data into meaningful information for the commanders. A central thrust of these efforts exploits the synergistic relationship between SAR and MTI radar. Used together, they offer comprehensive coverage of the battlefield     

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     

On measurement of operational security

Ideally, a measure of the security of a system should capture quantitatively the intuitive notion of “the ability of the system to resist attack.” That is, it should be operational, reflecting the degree to which the system can be expected to remain free of security breaches under particular conditions of operation (including attack). Instead, current security levels at best merely reflect the extensiveness of safeguards introduced during the design and development of a system. Whilst we might expect a system developed to a higher level than another to exhibit “more secure behavior” in operation, this cannot be guaranteed; more particularly, we cannot infer what the actual security behavior will be from knowledge of such a level. In the paper we discuss similarities between reliability and security with the intention of working toward measures of “operational security” similar to those that we have for reliability of systems. Very informally, these measures could involve expressions such as the rate of occurrence of security breaches, or the probability that a specified “mission” can be accomplished without a security breach. This new approach is based on the analogy between system failure and security breach, but it raises several issues which invite empirical investigation. We briefly describe a pilot experiment that we have conducted to judge the feasibility of collecting data to examine these issues     

重现头顶的璀璨星空

作为一个常年混迹于网络的看客,相信近几年国内发生的诸多热点事件大家部不会错过,当潜规则被搬上桌面,成为心照不宣的秘密;当躲猫猫、俯卧撑、楼脆脆这些荒唐的事件接二连三地发生;当一个个"范跑跑"、"郭美美"越来越理直气壮地跳出来时,我们一边围观、谴责,又一边逃避着,这些事也层出不穷,竟成为常态。这个世界到底怎么了?一个接一个令人发指的荒唐事件的上演,短暂的警示后,却反成了人们茶余饭后的谈资,少有人会真正地去思考:我们生活的社会正在遭遇一场什么样的变故?近期有幸读了华中科技大学出版社策划出版的《中国刻不容缓——拯救我们的道德》一书,不说醍醐灌顶,却有如读了《警世钟》的感觉,国民的道德信念日渐式微,以陕西周老虎事件和河北三鹿     

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     

What is systems engineering?

There are probably more definitions of “Systems Engineering” than there are AESS members. In its simplest form systems engineering is the design of the whole as opposed to the design of the parts. The vast number, complexity and diversity of elements can overwhelm and degrade system performance and reliability. Embedded processing and software can be both a boon and a bane. A systems engineer analyzes and optimizes an ensemble of elements that relate to the flow of energy, mass and communications into a design that performs the desired function. “Systems engineering” is used herein to cover a very broad spectrum of processes and controls to engineer a product at the many levels required to satisfy all aspects of the original requirement. Our definition is not intended to either include or exclude systems engineering and integration as used in the computer field. In any case, systems engineering is the application of solid engineering principles to design and develop a large enterprise within cost and schedule to satisfy the needs of the ultimate user. It involves conceptualization, design, development, test, implementation, approval/certification and operation (including human factors) of a system. In essence, systems engineering is a problem-solving discipline for the modern world     

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.     

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