Simulation-Based Acquisition: Architecture and Implementation - Part 1 Will Hollier Engen Institute
[email protected]
Paul Beckett School of Electrical and Computer Engineering, RMIT University
[email protected] Abstract. Simulation Based Acquisition is a program to facilitate business, engineering and planning to be conducted via simulation and requires an organization-wide systems architecture with unprecedented levels of integration and interoperability between applications. Early initiatives to define this advanced mode of operation are examined. 1.
INTRODUCTION
Simulation Based Acquisition (SBA) is a military program with the goal of applying new levels of interoperability and sophistication to simulation of acquisition functions [1], [2]. It could be said that moving from the current situation characterized by many stand-alone simulations to interoperability is analogous to reiterating the development of computing ‘islands of automation’ towards online networking and the Internet.
2.
WHAT IS SBA?
An early working definition of SBA was as the application of systems of systems architectures to the extended acquisition processes covering the intersection of three major spheres of management consideration – Acquisition, War-Fighting and Resource Allocation (see figure 1).
The vast scope of the proposed undertaking is only apparent to those with a background in military acquisition so that a brief background is provided in this paper. Section 2 defines SBA, the context in which this seed concept was expanded into SBA policy. Section 3 describes the progress of this concept into a ‘definitized’ architecture. Section 4 discusses SBA Architecture and Section 5 some remaining problems. Following this problem analysis in Part 1, an SBA technical architecture will be presented in Part 2. Figure 2: SBA Interacting Communities (from [1]) Acquisition in the Defense context is managed as three classes of program: 1. Consumer and Non-Development (C&NDI) 2. Defence Development Programs 3. Evolutionary Programs
Figure 1: SBA Interacting Communities (from [1])
Items
C&NDI corresponds to the purchasing functions found in private enterprise organizations and includes such activities as tendering, advertising, contracting, preferred supplier arrangements, e-commerce networking and distribution logistics etc. Evolutionary Program management applies in rare circumstances in which an experimental item with
unknown engineering methodology is to be produced. C&NDI and evolutionary programs require comparatively modest organizational support compared to development programs. The Defense Development Programs apply to the development of major platforms (tanks, aircraft, aircraft carriers, etc). They commence with the production of a capability requirement and cover all lifecycle phases - i.e. Needs Identification, Conceptual Design, Engineering Design, Manufacturing Development, Production, Deployment, Operation and Disposal. Simulation of projected operation and support actions across the remaining lifecycle phases is performed at each design phase to evaluate design proposals. The scale of simulations ranges from Theatre/Campaign to Engineering. This Simulation Based Design process has been instrumental in developing and validating future operating modes for logistics, training, deployment, maintenance and mission operations etc. IPPD (Integrated Product and Process Development) and BPR (Business Process Re-engineering) approaches are mandatory in SBA Development programs. This in turn requires detailed ‘AS IS’ organization models to exist in a simulate-able form against which new ‘TO BE’ organizational models are tested, finally producing transition programs. 2.1 SBA in Context SBA revisits aspects of prior initiatives such as CALS and includes functionality of the defunct MIL STD 1388 and MIL STD 502. However SBA extends the mode of delivery of this functionality to simulation and makes mandatory the previously optional advanced modes of CALS. For instance the Data Repository and DPDs (Data Product Definitions) used in SBA are extensions of the CITIS database in CALS and the PDM (Product Data Models) from STEP1.
The transition from the punched card and flat database approach of MIL STD 1388 to the business oriented 502 standard has brought Business Process Re-Engineering an Integrated Product and Process Development methodologies into prominence. The impetus to implement SBA is founded on the observation that while there is the least knowledge about a development program the majority of costs (for the next 40 years) are locked in (70-80% of future costs are determined prior to Development Milestone I). The effectiveness of M&S in acquisition programs, with an average 25% ROI2, was established by Saunders [2],[3]. A policy to exchange results and coordinate architecture exists between the SBA initiative, DARPA’s Simulation Based Design program and NASA’s 15 year plan for its ISE (Integrated Synthesis Environment)[5],[6]. ISE sponsor and utilize extensions to the STEP standards. 2.2 SBA Goals and Scope The Terms of Reference for the Joint Simulation Based Acquisition Task Force and its Road Map Report set goals as – • • •
The MILSPEC Reform initiated in 1994 had, by July 2000, cancelled 6,000 military specifications and standards. The transition to public domain standards has resulted in the ISO developing new standards for lifecycle planning via the STEP standards process.
• •
Reduce time, resources & risk in acquisition Increase quality, military worth & supportability Reduce operating & sustaining cost throughout lifecycle Enable IPPD across acquisition lifecycle Reduce Acquisition cycle time by 50% (from 20 years to 10)
The goal of SBA, to provide simulation interoperability, integration and reuse across all lifecycle phases and scales of simulation, requires organizational modelling and simulation of the entire military organization not just of standard acquisition functions such as e-commerce and logistics. Figure 3: Lifecycle Costs ‘Locked In’ (from [11])
1
ISO 10303 STEP - STandard for Exchange of Product data models
Not only is the simulation of development programs embedded in organizational modelling and simulation but development embeds Virtual Prototyping and this incorporates Simulation Based Design. (see figure 4) 2
ROI – Return On Investment
Three Sub Systems
AI & AGENTS GENERATIVE SIMULATION
ISE SIMULATION BASED DESIGN
SIMULATION BASED ACQUISITION
REQUIREMENTS & DEVELOPMENT M&S
PROCESS MODEL & SIM DATA TRANSFORMS SOFTWARE TRANSFORMS LOGIC & ARTIFICIAL INTELLIGENCE
Figure 4: Three Sub-Systems for SBA Architecture
• • • • •
facilitate the reuse of models, simulations, data and infrastructure make maximum use of existing GOTS/COTS be based on an open, scaleable and flexible architecture operate in distributed heterogeneous computing environments facilitate collaboration between geographically distributed teams
3.3 Consolidated Recommendations The following ranked recommendations were made: 1. “Definitize” requirements for SBA infrastructure Figure 5: Simulation Based Design & Virtual Prototyping (reproduced from [12]) 3.
STATE OF DEVELOPMENT
Like many Defense initiatives before it the policy to develop and implement SBA represents an undertaking to develop technology that has not previously existed. With SBA the technical challenges are considerable and the way forward unclear. Consequently the initiative commenced with foundational studies. 3.1 Foundational Studies The Joint Simulation Based Acquisition Task Force was charged with developing a Concept of Operations covering operational, technical & modular systems architectures. The JSBATF Road Map Report [1] identified major technical challenges, module ownership, costs to implement and near and long term actions. The Road Map also identified industry actions – investment, consortiums, IP sharing, and participation with government in evolving operational and technical architectures to incorporate new technologies. 3.2 Technical Goals The JSBATF identified a number of technical goals. In general, SBA is to – •
facilitate the use of M&S
2. Define & apply data classes/schema to span acquisition lifecycle 3. Define relationship of other policies and initiatives (i.e. DARPA, NASA) to SBA 4. Ensure coordination with Defense (CVPS) Collaborative Virtual Prototyping Study 5. Develop partnership with Industry using STEP Points 6,7,8,9 & 11 specified further CVPS and STEP collaboration. 3.4 Implementation Plan As indicated by the 1st & 2nd ranked recommendations the SBA Task Force were unable to ‘definitize’ the SBA architecture and (with the exception of applying data element formatting and networking based on CALS and STEP) could only recommend a watching brief on similar programs. Consequently the implementation plan was limited to establishing – • Collaborative Environments (CE) - similar to the CALS CITIS database for concurrent engineering. Definition ‘a CE is an enduring collection of subject matter experts (SMEs) supported by interoperable tools and databases, authoritative information resources, and product/ process models focused on a common domain’
• Schemas of DPDs (Data Product Definitions) that evolve through the acquisition lifecycle & DIFs (Data Interchange Formats) – similar to the STEP DPMs (Data Product Models)
SIMULATION INTEROPERABILITY DEVELOPED
Business Modelling
Quotes ‘it is critical the acquisition community leverage existing standardisation efforts (such as the Standard for the Exchange of Product model data (STEP))’
Engineering Modelling
The Task Force also proposed the way forward was currently by further policy initiatives addressing: * Gain real Industry Involvement (big & small industry) * Focus on Acquisition should not become M&S Centric * Reconcile SBA with other initiatives * How do we deal with legacy information? * How to iterate between reference systems architecture and CEs (top-down, bottom-up or both?) 3.6 Pathfinder Program Finally the Joint SBA Task Force instigated a program of experimentation to consist of 3 – 6 experimental SBA implementations to promote further integration in a few selected activities having demonstrated the beginnings of integration. Quotes ‘Just a starting point, need a focused and coordinated experimentation effort.’ ‘DTAP program to identify SBA related science and technology (S&T) and R&D efforts to be undertaken’ 3.7 State of Development Having reviewed both the comprehensive goals of SBA, the financial justification and the limited extent to which an architecture for Simulation Based Acquisition has been defined to date, the need to further develop the SBA architecture is apparent. The following sections discuss the state of development of the major subsystems of the SBA Architecture as outlined so far and shown in Figure 7.
Æ
STEP PDM
ConceptÆ Requirements Æ System Æ Engineering ÆManufacture Æ
‘Achieving SBA goals for interoperability and reuse depend heavily on community migration to such standards.’
3.5 Policy Development
CALS XML
LIFE CYCLE MODELLING
‘actively participate in product data exchange’
Figure 6: SBA Data Architecture (from [12])
UNDEVELOPED
Figure 7: SBA State-of-Development 4.
DEVELOPED SUBSYSTEMS
4.1 Process Modelling & Simulation Business modelling is a form of Process Modelling. Business modelling was pioneered by the US Air Force sponsoring the development of IDEF models for which modelling tools are readily available. State of the art tools produce numerical, graphical and Virtual Reality constructive simulations. Such tools also support process improvement via statistical analysis of operations and Activity Based Costing. Documentation and project management data can be generated together with relational or object-oriented databases with corresponding transaction processing and managerial applications software. 4.2 Simulation Ready Data The comprehensive enterprise wide nature of SBA means that several classes of data and programs will exist and be produced within the system all of which will need to be accessible to simulations and federates of simulations. Thus transactions, documents, programs, CAD models and knowledgebases must all be accessible to the SBA Architecture. In current systems data is not directly simulate-able but can reside in formats with information models which allow the data to be read by other systems. However such semantically united data architectures are as yet not in wide use. Current simulation systems generally are restricted to tightly specified data formats. The CALS3 Initiative established standardized data interchange formats for each class of data and defined sophisticated (state-of-the-art) documentation standards - five classes of IETMs (Interactive Electronic Technical Manuals) based on SGML4. Current initiatives are now upgrading CALS from SGML to XML5 and will thereby provide the foundations of a semantically united data architecture.
4.3 Engineering Modelling & Simulation The engineering design and manufacturing development stages are well supported with state-ofthe-art modelling and data interchange standards. The STEP standards are highly recommended in the SBA documents as are the associated PDM (Product Data Management) standards. DARPA have sponsored the development of model based engineering including simulation based design. Highly sophisticated CAD systems, such as VIVID, with behavioral and relational modelling, supporting real-time analysis and interactive virtual prototypes are now available.
helicopter, plane, tank, simulations interacting in a physical environment. However the types of interoperability required for a development program are deeper. For instance a set of constraints from logistics may constrain choices in Simulation Based Design. Also in Defense Development, programs reuse requires information and decisions in the development process to be transformed into other forms such as logistics. Engineering design specifications and CAD models are transformed into maintenance manuals, training simulations and spares database.
NASA’s Integrated Synthesis Environment (ISE) is a 15 year program which aims to develop a new generation of design environments for the engineering lifecycle.
This is not a need for simulation interoperability so much as the transformation and representation of knowledge into various knowledge media (ie software, multi-media document databases etc) and formats.
5.
Defense Development programs traditionally (ie 1388 & 502) transform knowledge from assorted sources (manuals, microfiche, computer databases, anything etc) into documents which are then developed into product models which in turn are then made into products (hardware, software) and IETM’s (Interactive Electronic Technical Manuals).
UNDEVELOPED SUBSYSTEMS
Figure 7 shows the Conceptual Design, Requirements and Systems Specification stages of the engineering lifecycle as undeveloped. These processes are not supported by software tools or design environments (including simulation) such as those for software and integrated circuit development. These design environments are based on ‘formal methods’ that is they are implemented with mathematically defined languages so that AI reasoning can be applied to design. 5.1 Ill Defined Processes Although the now defunct MIL STD 1388 and its successor MIL PRF 502 describe processes and data formats to use in these early lifecycle processes they are ill-defined with no top level process specification. 5.2 Ill Defined Systems Engineering Systems Engineering as defined in Defense documents is also ill defined – a problem which INCOSE7 are aware of having sought interaction with Software Engineering and the STEP standards communities in order to seek a definition of systems engineering via formal methods. 5.3 Prospects for a Sound Architecture The new standard for the systems engineering lifecycle being developed by the ISO as STEP AP223 only provides documentation standardization and is not a basis for formally defined systems engineering tools. See Sage [9] for a knowledge based approach to systems engineering. 6. SIMULATION & SYSTEMS INTEGRATION The current HLA approach to interoperability will allow composition of a new war fighting simulation –
Thus there is a mismatch between the goals (information media development and transformation) and the methods (simulation interoperability and reuse) of SBA. The goals require methods far more powerful than those being contemplated. Alternatively the situation could be stated as universal simulation, access and management requires/assumes that all this inter-format transformation is already automated when in reality it isn’t. Furthermore, data in one domain may be required to generate simulations in another domain so that an architecture based on a segregation of information into processes and data is too limiting even when any process may use any data. 6.1 Process Generation and Optimization For instance consider converting information structures to become command scripts for process that generate simulations * For processes this is direct as a simulation is a process with spatial, graphic representation * For transactions this requires meta level ie description of transaction processor * For CAD requires instantiation ie particular dynamics * For knowledge this requires multi-level contextual instantiation, where the contextual information maps to simulation control
7.
AI CAPABILITY & INTEGRATION
7.1 Constructive Simulation and the Need for AI In addition to the simulation of organizational modelling and engineering design SBA includes simulation planning that is often presented as constructive simulations which in turn utilize Knowledge Based Simulation [9]. Knowledge Based Simulation systems integrate various AI systems (such as expert systems, language understanding, problem solving, qualitative physics, explanations systems, cognitive modelling, etc) with multi-mode (discrete, continuous, distributed and adaptive agent) simulation and Virtual Reality technologies. 7.2 Optimal Process Generation and AI In the near term, further integration can be achieved via a semantically-united data architecture. However the total integration and interoperability of simulations sought by SBA in the long term requires process generation and optimization capabilities which in turn require AI and constraint processing capabilities.
8.2 Software Investment & Rewrite Costs Defense departments have substantial investments in GOTS8 simulation software, often because COTS9 is not available for the application. With the software technology currently applied to COTS and GOTS the cost of frequent upgrades to software whether by programming, re-purchasing or upgrade purchasing is a barrier to improving functionality. 8.3 Supporting Systems In the first phase of this investigation Hollier was an invited member of the Strategic Industry Research Foundation’s, Marine and Heavy Industry Council Committee for CALS and STEP implementation. Studies at Transfield showed that even if new software such as CALS and STEP is available the associated data was not available from suppliers or legacy systems. It was recommended that the software must be made available via a small supplier network with a dedicated legacy data processing system also on this network. PDES10 are now implementing a US small supplier network for STEP and legacy data processing 9.
CONCLUSION
Simulation Based Acquisition is an initiative to develop substantially enhanced, highly integrated & interoperable simulation systems to support defense systems and technology development.
Figure 8: SBA Integration Stages (from [12]) 8.
PRACTICAL PROBLEMS
8.1 Problems with Middleware The current HLA approach to simulation integration and its precursor DIS are both ‘middleware’ methods. NASA’s ISE initiative has already needed to upgrade HLA to a new network interface standard ‘IsoWAN’ [8] which is also a middleware approach. The problems with middleware are that it only provides limited integration and interoperability and always needs to be replaced to improve the architecture and hence improve capability. Middleware standards only reduce the workload marginally and for applications without a well defined (preferably via formal methods) architecture future capability requirements are difficult to predict so that middleware upgrades are frequent.
Core simulations for Concept Design, Requirements & Systems Specification are undefined and the architecture and methodology (Systems Engineering) are also as yet undefined. There are however state-of-the-art information models and tools to support excellent data and documentation architectures (XML CALS, IETMs, STEP and PDM). A semantically unified architecture is proposed to meet near-term integration goals. Part 2 will describe AI knowledge based program and system generation methods and tools which will satisfy the requirements for process interleaving, generation and optimization to achieve the long-term integration objectives of the SBA Initiative. REFERENCES 1. Bernstein, R., (1998) A Roadmap for Simulation Based Acquisition – Report of the Joint Simulation Based Acquisition Taskforce, Acquisition Council. 2. Johnson, M., McKeon, M. Szanto, T., (1998) Simulation Based Acquisition: A New Approach, Defense Systems Management College Press, Fort Belvoir, Virginia.
3. Sanders, P., (1999) Simulation Based Acquisition: The Revolution is Coming, Feb 16, Office of the Under Secretary of Defense (Acquisition & Technology) 4. Saunders, P., (1996) Study on the Effectiveness of Modelling and Simulation in the Weapons System Acquisition Process, US DoD Office of Test, Systems Engineering and Evaluation – Available 12 Apr 02 at – http://www.acq.osd.mil/te/pubdocs/ acqstudy.htm 5. Braun, R.,(2001) NASA’s Intelligent Environment – Revolutionizing the Engineering and Science Practice, Enterprise Vol 2(1):2-6, Advanced Solutions, available 12 Apr 02 http://www.mscsoftware.com/support/ library/journal/win2001_nasaprgm.pdf
Information and Services Framework, Submitted to ICSS2000. 8. Chow, E.T., (2002) IsoWAN What is it and How does it Work? Available 12 Apr 02 at - http://wwwabc.hsc.usc.edu/ibccw/IsoWAN%20ABBC%20Present ation.ppt 9. Sage, A., (1992) Systems Engineering, John Wiley &Sons Inc.
Synthesis Agency’s Integrated Enterprise at -
10. Fishwick, P. & Modjeski, R. (Eds.), (1991) Knowledge Based Simulation – Methodology and Applications, Springer-Verlag.
6. Van Drei, D., Seidel, N. & Stauffer, R., (2000) ISE Systems Architecture Concept Overview, NASA Glen Research Center, Aug 15.
12. Piplani, l., Mercer, J. & Roop, R., (1994) Systems Acquisition Manager’s Guide for the use of MODELS AND SIMULATIONS, Defense Systems Management College Press, Fort Belvoir VA, Department of Defense
7. Korsmeyer, D., Chow, E.T. & Conroy, M., (2000) IsoWAN A NASA Science and Engineering
11. Defense Systems Management College, (1986) Integrated Logistics Support Guide, 1st Ed. Fort Belvoir VA, Department of Defense
