US Army OE Vinansky

US Army Operating Environment (OE): 

US Army Operating Environment (OE) Presented to The Open Group Meeting, Austin, Texas 30 April 2003

Purpose: 

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 how 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?: 

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: 

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: 

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

Slide6: 

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 WSCOE - a framework of Interface Standards supported by engineering artifacts Application API X Users Vendors System A System B System C WSCOE Concept * Application Programming Interface Integrators

OE Pedigree: 

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

WS COE Concept Applied: 

WS COE Concept Applied

Weapon Systems Concerns: 

Weapon Systems Concerns HSE statistics on causes of accidents

Potential For WSTAWG to Leverage The Open Group Services: 

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: 

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: 

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: 

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: 

Open Brand 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? Who, What, When, How and for how much from a legal perspective!!

Summary : 

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 DO178B 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 WalMart, Best Buy, or whatever and buy software shrink-wrapped off the shelf that is guaranteed to work!

Slide16: 

Any Questions?

Back-up Slides: 

Back-up Slides

WSCOE Architectural Role: 

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

Embedded Disasters: 

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. [Neumann95] 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 10th 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: 

Engineering Solutions Without Real-World Requirements

Gold Plating: 

Gold Plating

D.C. Functionality: 

D.C. Functionality

IT WORLD: 

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

Relative Cost to Fix a Defect: 

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

Software Costing and Sizing Accuracy vs. Phase: 

Software Costing and Sizing Accuracy vs. Phase

Rules Of Thumb: 

Rules Of Thumb Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases. You can compress software development schedules 25% of nominal, but no more. For every $1 you spend on development, you will spend $2 on maintenance. Software development and maintenance costs are primarily a function of the number of source lines of code. Variations among people account for the biggest differences in software productivity. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15. Only about 15% of software development effort is devoted to programming. 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. Walkthroughs catch 60% of the errors. 80% of the contribution comes from 20% of the contributors.

Issues Facing the Army: Long Term Affordability of Software: 

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