US Army Operating Environment OE Presented to The

US Army Operating Environment (OE) Presented to The Open Group Meeting, Austin, Texas 30 April 2003 Presented by: Dr. George Vinansky, Jr. WSTAWG Vice Chairman ARDEC Armaments Software Engineering Center (ASEC) U. S. Army TACOM-ARDEC ATTN: AMSTA-AR-FSF-S, Building 352 Picatinny Arsenal, NJ 07806 -5000 UNITED STATES (973) 724 -4658 [DSN 880] FAX: 724 -7850 email: Vinansky@pica. army. mil Tank-automotive & Armaments COMmand COM

Purpose • Familiarize The Open Group Real-time and Embedded Systems Forum representatives with the Army’s OE and its concept of a Weapon Systems Common Operating Environment (WSCOE) • Show Army is migrating an Army “proprietary” standard into a bona fide commercial standard • Find a pathway for “Best Business Practice” brand certification!

Background What is an OE? The Operating Environment (OE) Application Programmer’s Interface (API) provides a standardized interface to a set of distributable objects, which can be utilized to provide a foundation and infrastructure supporting the creation of rehostable distributed real time embedded weapon systems applications.

Background WSTAWG OE Work • Work started in 1996 • Follows the model of PASC and many other standardization efforts, to use existing practices and develop a single standard API for Army OE implementations. • Teamed with representatives from the various weapons – sub-domains – weapons programs – contractors who have experience in OE development • Leveraged the experience of current hard real-time embedded OE developers (both commerical and military) • A single API to standardize multiple implementations – supporting various hardware/OS combinations – have unique strengths and attributes • Provides the weapons systems community a pathway ahead for incorporating new technologies into common practice.

Real-World Successes • Predator – Target tracking software from the LOSAT (Line of Sight Anti-Tank program) was moved from that environment to the Predator. This tracker software was built upon COE and utilized COE to provide services. This included use of the COE WSTAWG core and COE extended services for managing the 1553 bus and for handling digital video. Standards that comprise WSCOE (e. g. OE API, Weapon Systems Map Services, etc) are mandated in the JTA -A. Significant Cost-Avoidance 75% of software development cost is analysis and test Interoperability enhanced by re-use of conformant product between weapon systems

WSCOE Concept System Service Software & Hardware System A System B System C to gr a Us er s Application API X Vendors OE API System Service Software & Hardware te Application APIs Application APIs Application APIs API* In Architecture Reference Models rs WSCOE - a framework of Interface Standards supported by engineering artifacts * Application Programming Interface Software Acquisition Process Innovations • Software API maintained by Users Group • Software maintained by vendors • Second tier software supplier base • Users acquire software via vendor license • Competition through the life cycle

OE Pedigree Army Science Board Briefed as to WSTAWG API approach 4 April 1997 COE concept for weapon systems Army Real Time Decision to develop a RT Army approved COE to meet but within DISA DII Army COE framework requirements 5 Nov 2001 4 Nov 1999 POSIX 1003. 13 (PSE 53) draft in ballot Open Brand future

WS COE Concept Applied Mission Application Software WSCOE Common Spt App APIs Target Tracking Tgt Tracking API Radar Control Rdr Ctrl API Image Processin g Img Proc API Navigation Nav API Mapping ? ? API Vendors Middleware/Operating Environment Implementation WSCOE OE API Operating Environment (OE API) Processors and Devices Hardware Desktop station as Host System Integration Lab Target Hardware #1 Target Hardware #2 Source: Raytheon

Weapon Systems Concerns HSE statistics on causes of accidents

Potential For WSTAWG to Leverage The Open Group Services • Conformance Test Suites – Leverage Existing Test Suites – Develop WSTAWG Standards Specific Suites • Certification – Third-Party Certification Authority • Standards / Open Brand – Potential Forum for WSCOE Standardization Efforts

Potential WSCOE Conformance Testing via The Open Group • The Open Group’s Definition: Ensuring Products Meet WSCOE Standards • Test Suite Lifecycle Fits WSCOE Needs – – – Test Plan Development Automated Test Environment Test Suite Development Test Suite Maintenance Interoperability Events • Tools for WSCOE Vendors / End-Users to Ensure Conformance

Potential WSCOE Certification via The Open Group • The Open Group’s Definition: Formal Recognition of Product’s Conformance • Potential Services Required: – Assist WSTAWG with Development of: • Certification Policies • Certification Procedures • Certification Program – Third-Party Operation of Certification Program – Independent Certification Authority • Verification of Conformance • Maintains a Register of Certified Products

Potential WSCOE Standardization via The Open Group • The Open Group’s Definition: Consortia Consensus on Specification Defining the Standard • Potential Services Required: – Leverage Standards Already Defined by The Open Group – Standardization of WSTAWG Defined Components • Assist in Identification of Consortia Members • Define the Process • Manage the Process

Open Brand Who, What, When, How and for how much from a legal perspective!! • Is the Open Brand appropriate for WSCOE? • What does this mean from a legal perspective? –For the Vendors? –For the Integrators? –For the US Army?

Summary • WSCOE and its APIs development are critical to meeting interoperability and affordability goals of future weapon systems • Software must come out of the Cybernetic stone age and standardize OS services • OS services must be formalized into an overarching Architecture. • Ensure that nothing being with these standardization processes preclude obtaining certification for DO 178 B or IEC 61508 • Need to nail down liability, who is legally responsible for what, when, where, how and by whom • Want to be able to go to a Wal. Mart, Best Buy, or whatever and buy software shrink-wrapped off the shelf that is guaranteed to work!

Any Questions?

Back-up Slides

WSCOE Architectural Role Technical View Prescribes standards and conventions WSCOE Class Definition JTA-A Tech Architect CIO/G-6 Operational View + Functional Description HLA Federate = UML Modes WSTAWG System View Identifies Warfighter Relationship and Information Needs Operational Architect TRADOC Relates Capabilities and Characteristics to Operational Requirements Systems Architect SAALT Support and Assistance is Crucial for Success

Embedded Disasters Tragedies in Therac 25 [Therac 25], a computer-controlled radiation-therapy machine in the year 1986, caused by the software not being able to detect a race condition, alerts us that it is dangerous to abandon our old but well-understood mechanical safety control and surrender our lives completely to software controlled safety mechanism. Software can make decisions, but can just as unreliable as human beings. The British destroyer Sheffield was sunk because the radar system identified an incoming missile as "friendly". [Sheffield] The defense system has matured to the point that it will not mistaken the rising moon for incoming missiles, but gas-field fire, descending space junk, etc, were also examples that can be misidentified as incoming missiles by the defense system. [Neumann 95] Software can also have small unnoticeable errors or drifts that can culminate into a disaster. On February 25, 1991, during the Golf War, the chopping error that missed 0. 000000095 second in precision in every 10 th of a second, accumulating for 100 hours, made the Patriot missile fail to intercept a scud missile. 28 lives were lost. [Patriot] Fixing problems may not necessarily make the software more reliable. On the contrary, new serious problems may arise. In 1991, after changing three lines of code in a signaling program which contains millions lines of code, the local telephone systems in California and along the Eastern seaboard came to a stop. [Telephone outage] Once perfectly working software may also break if the running environment changes. After the success of Ariane 4 rocket, the maiden flight of Ariane 5 ended up in flames while design defects in the control software were unveiled by faster horizontal drifting speed of the new rocket. [Ariane 5] (See note page for references)

Engineering Solutions Without Real-World Requirements e-Toilet paper

Gold Plating

D. C. Functionality

NEED Interface Definition between IT World & Non-IT World I IT WORLD • Purview of CIO • Primary Mission to O U T NON-IT WORLD A N O I T U • Purview of Title 10 R create - disseminate IT E S • Part of Army Infrastructure R P • Exchanges data with Non- A T IT systems I N Enables decision-making! F Authority/AMC • Primary Mission is to put “steel on target”, to close with and destroy/defeat the foe. • Part of Deployable Force. C A E C I E N • Not an IT system, but uses IT for primary mission execution Puts “steel on target”!

Relative Cost to Fix a Defect Ref. Barry W. Boehm, 1981, COCOMO Relative cost to fix error 100 10 1 Req. Design Code Test Accept. Operation

Software Costing and Sizing Accuracy vs. Phase

Rules Of Thumb 1. Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases. 2. You can compress software development schedules 25% of nominal, but no more. 3. For every $1 you spend on development, you will spend $2 on maintenance. 4. Software development and maintenance costs are primarily a function of the number of source lines of code. 5. Variations among people account for the biggest differences in software productivity. 6. The overall ratio of software to hardware costs is still growing. In 1955 it was 15: 85; in 1985, 85: 15. 7. Only about 15% of software development effort is devoted to programming. 8. Software systems and products typically cost three times as much per instruction as individual software programs. Software-system products (i. e. , system of systems) cost nine times as much. 9. Walkthroughs catch 60% of the errors. 10. 80% of the contribution comes from 20% of the contributors.

Issues Facing the Army: Long Term Affordability of Software Life Cycle Cost Breakdown Documentation - 6% Of Typical Army Weapon System Software Source: GSA Cost Model, REVIC 9. 2, Actual Data Design & Code - 19% Analysis - 47% Test - 28% 75% of the effort is analysis and test Bottom Line: Modularity and Reuse of Software Critical to Affordability of Life Cycle Weapon Software