From DAF To Sim: Simulation Support To Capability Engineering

Transcription

1 From DAF To Sim: Simulation Support To Capability Engineering Evan Harris 1 ; Andrew Graham 1 ; Graham King 2 ; Kurt Bieri 1 1 CAE Professional Services Australia evan.harris@cae.com.au; andrew.graham@cae.com.au; kurt.bieri@cae.com.au 2 Network Centric Warfare Project Office, Capability Development Group graham.king@defence.gov.au Abstract. This paper presents an application of the Capability Engineering Design Approach (CEDA) methodology developed by CAE Professional Services that includes a step in which Defence Architecture Framework (DAF) architectures can be translated into Simulation for execution to support dynamic testing, verification and validation. For the application presented, the simulation tool used is DARNOS (Dynamic Agents Representation of Networks of Systems). DARNOS is a simulation tool that enables the modelling of organisational structures, social and domain knowledge of organisations, responsibilities and relationships, and organisational and individual expertise and decision making in addition to the sensor and engagement grids more commonly simulated. We discuss how a DAF Architecture product is translated into an executable simulation for specific scenario vignettes. The DAF OVs (Operational Views) are translated into team structures, operational components, operational scenarios, networking relationships and structures, C2 structures, social and domain knowledge and expertise for programming a Decision Maker Model (DMM) defining the Order of Battle and behaviour of a scenario. The DAF SVs (System Views) are translated into computational components (specific executable models) within a scenario. The resulting system allows for the execution of human-in-the-loop scenarios for experimentation and Monte Carlo batch scenarios for analytical studies. 1. INTRODUCTION The Battlespace Architecture project (BA2015+) is a pilot project that has the goal of developing a high level operational architecture for a generic Battlespace (in the first instance). Sponsored by the Network Centric Warfare Project Office (NCWPO) of the Capability Development Group (CDG), it initially seeks to create a broad high level architecture that may be further developed and extended over time. The principle uses of the architecture are intended to be for Military Strategy, Capability Development, Capability Planning, Joint Operations, Desk Officers, and NCW Compliance. The architecture is being developed using the Capability Engineering Design Approach (CEDA) methodology developed by CAE Professional Services. A key aspect of CEDA is the use of modelling and simulation to execute the architecture for the purposes of verification and analysis. Modelling and simulation can also support another key aspect of CEDA: measurement of the effectiveness of the capability for which the architecture has been developed. In this paper, we discuss the process of translating the architecture products into simulation. The simulation tool used is DARNOS, a decision support tool developed for DSTO to facilitate NCW Analysis and Experimentation within a single framework. In the next section we provide a brief introduction to Capability Engineering, Defence Architecture Frameworks and CEDA. In Section 3 we introduce DARNOS, and in Section 0 we discuss the BA2015+ project and the application of simulation. In Section 5 we describe how we produce a simulation from the DAF products, and in Section 6 we discuss our conclusions and possible future extensions to the work. 2. CAPABILITY ENGINEERING 2.1 Engineering Systems-of-Systems Capability Engineering is a natural extension of Systems Engineering. In Capability Engineering, the primary focus is the engineering of systems-of-systems. Maier [6] describes five characteristics that differentiate systems-of-systems from systems that are simply very large and complex: 1. Operational independence of elements; 2. Managerial independence of elements; 3. Evolutionary development; 4. Emergent behaviour; 5. Geographic distribution. When engineering systems-of-systems, communication and the interfaces between systems are key attributes. Systems-of-systems are at the heart of modern and future war fighting capabilities. The need for Network Centric Warfare (NCW) and Network Enabled Capabilities (NEC) being introduced into the ADF has resulted in a requirement for a whole of capability view which is now being formulated with supported from Capability Engineering. 2.2 Defence Architecture Frameworks An architecture framework specifies a method of organising an enterprise or systems architecture into a collection of views that are consistent and

2 complementary. The views can be textual, tabular, diagrammatic, or pictorial. Within the Defence context, the two most widely known and used architecture frameworks are the US Department of Defence Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF). DoDAF v1.0 [2] defined four classes of views: All Views (AVs), Operational Views (OVs), System Views (SVs) and Technical Standards Views (TVs). All Views describe the architecture as a whole by specifying its scope and context. Operational Views describe operational nodes, the tasks and activities and the information exchanged between the operational nodes. Systems Views describe the systems used to provide and support the operational activities and nodes. Technical Standards Views describe the rules and standards that the systems and system-of-systems that apply to the architecture. DoDAF v1.5 [4] has added additional System Views and renamed them Systems and Services Views. MODAF v1.1 [7] builds on DoDAF v1.0 by defining a number of additional views: Strategic Views (StVs) and Acquisition Views (AcVs). Strategic Views describe higher, enterprise, level requirements for change over time to support the capability management process. Acquisition Views describe program dependencies, milestones and statuses to support the acquisition and introduction-to-service process. The Australian Defence Architecture Framework (AUSDAF) is also based on DoDAF. It includes a set of Common Views (CVs) instead of All Views (AVs) and it is likely that the next revision [2] will contain additional views such as Strategic Views, Acquisition Views and Human Views. 2.3 CEDA CEDA [9], the Capability Engineering Design Approach developed by CAE Professional Services, is a methodology for developing Capability Architectures. It ties together: 1. The activities of Capability Engineering, from requirements analysis through system-of-system design to options assessment 2. The development of an architecture using a DAF, including the use of Strategic Views, Acquisition Views and Human Views 3. The use of Modelling and Simulation for the execution of the architecture 4. The definition and gathering of Capability Metrics [8] from Measures of Performance (MOP) and Measures of Effectiveness (MOE) to Measures of Force Effectiveness (MOFE) and Measures of Policy Effectiveness (MOPE) Human Views Human Views (HVs) [10] are a prototype extension to DoDAF and MODAF developed by CAE Professional Services to enable the distinction between people and technology to be explicitly highlighted within an architecture. They describe the management of human resources in the context of recruitment, training and retention over time Modelling And Simulation The use of Executable Architectures and Modelling and Simulation is a core component of CEDA. Executable architectures facilitate the analysis of the behaviour of systems-of-systems under dynamic conditions. Introducing modelling and simulation at the point where an architecture is under development allows for incremental development and significant risk reduction. The aim is to use a simulation environment that is as rich as possible, potentially including constructive simulation, rather than simply abstract interpretation of a static architecture, to gain the maximum benefits. MOP and MOE data may easily be generated from such a system. CEDA is product neutral: it encourages the use of the most appropriate Modelling and Simulation tool for the domain and problem at hand Process The CEDA process consists of four broad phases: Analysis, Design, Experimentation and Evaluation. An iterative approach is taken, allowing stages to be repeated as a project progresses, allow the resulting products to become progressively more detailed. During the Analysis phase: domain information is collected, the Problem Definition (CV-1) described, the Strategic Views (StV-1, StV-2, StV-3) defined, and a High Level Operational Concept Graphic (OV-1) is produced. During the Design phase the remainder of the architecture products are developed, commencing with the operational architecture (OVs) and StV-6, followed by the SVs,, HVs, AcVs. The Operational Activity to Capability Mapping (StV-6) is particularly important as it describes the mapping between the capabilities required and the operational activities that those capabilities support. Typically the Operational Activity Model (OV-5), Operational Node Connectivity description (OV-2), Organisational Relationship Chart (OV-4), Logical Data Model (OV-7) and at least one of the OV-6s (Operational Rules Model, Operational State Transition Description, Operational Event-trace Description) need to be developed to enable modelling and simulation design and development to commence. Within the Experimentation phase, models developed during the Design phase are executed within a synthetic

3 environment using scenarios defined during the Analysis phase. During the Evaluation phase, data gathered during the Experimentation phase is analysed against the measures previously developed. Metrics for subsequent iterations can also be developed. 3. DARNOS 3.1 Overview DARNOS (Dynamic Agents Representation of Networks of Systems) [12] is a simulation-based decision support tool for Joint Operations, C3 and NCW Capability Management. DARNOS was developed by DSTO s Defence Systems Analysis Division (DSAD), KESEM International (now CAE Professional Services Australia), the Australian Defence Simulation Office (ADSO) and the RAAF Air Power Development Centre (APDC) to facilitate NCW Analysis and Experimentation within a single framework. As such, it is an ideal vehicle to underpin the simulation implementation for the BA2015+ project. The DARNOS Conceptual Graphic (OV-1) is shown in Figure 1. It is based on the concept of grids introduced by Network Centric Warfare (NCW). The four grids are: the sensor grid, the engagement grid, the command and control (C2) grid, and the information grid. The sensor grid consists of both physical and logical sensors. The engagement grid consists of elements, such as weapons, that may exert force on other elements in the environment. The C2 grid consists of the human C2 elements and decision making processes. It includes the C2 hierarchies and relationships. The information grid consists of the communication and information relationships between elements on a network. 3.2 Architectural Components The components that constitute the DARNOS, as shown in Figure 2, consist of a simulation infrastructure, models of physical systems, models of decision making capabilities, and a collection of analyst and user utilities. The current implementation of DARNOS uses BattleModel as the simulation infrastructure, and BattleModel also provides the physical models that constitute the majority of the sensor and weapons grids, and part of the information grid. The analyst utilities are a combination of components that were newly developed for DARNOS and extensions to BattleModel utilities. The decision making capability models were developed specifically for DARNOS [5] and constitute the C2 grid as well as contributing to the other grids. The architecture of the decision maker capability is shown in Figure 3. This architecture is implemented as a Decision Maker Model (DMM). Each instance of the model contains a number of Expertise Blocks (EBs) that work together forming a skill set and utilise common knowledge and state data that is maintained by the model. There are three types of such data: domain knowledge, social knowledge and decision making state. The domain knowledge contains information received from the environment and domain, including mission data, tracks from sensors, physical position data and experience levels. The social knowledge contains information about the organisational structures, command and control responsibilities and information sharing responsibilities. The decision making state contains information internal to the EBs, such as the current and future intentions of the decision maker. 3.3 Executable Components In execution, DARNOS consists of four major components. The first is the simulation engine: DARNOS BattleModel. Figure 1: DARNOS Conceptual Graphic While many simulation systems support elements within one or a few of these grids, especially the sensor and engagement grids, the key feature of DARNOS is that it brings support for all four of the grids into a single framework. In addition, DARNOS has been engineered to support both analysis in constructive simulation mode (for example, through the use of Monte Carlo techniques) and experimentation, including human-in-the-loop exercises [11]. The second component, DARNOS BattleGen, is a scenario editor that allows a scenario to be constructed by specifying an ORBAT that represents the initial state of the simulation and define the behaviours of elements in the simulation. The third component, KASEd (Knowledge And Structure Editor), is an editor for the C2 and Information Nodes, allowing organisational structures to be developed and populated, and to allow the DMM to be configured by associating EBs with models of decision makers.

4 Figure 2: DARNOS Architectural Components The final component is the run-time GUI, DARNOS BattleVision. KASEd may also be connected to the simulation at run-time to observe and update the organisational structure during execution. Figure 3: Decision Maker Architecture 4. BA2015+ As we have discussed, the Battlespace Architecture project (BA2015+) will develop an architecture for a future generic battlespace. Initially this will be broad and high level and will not contain sufficient

5 detail to perform modelling and simulation in depth. To demonstrate the utility of the modelling and simulation aspects of CEDA, the project will also deepen the architecture centred on an illustrative example. This example is the Joint Fires scenario from the Australian Illustrative Planning Scenarios (AIPS), with specific capability metrics centred on the capability to be provided by the LAND 17 (Artillery Replacement) project Joint Fires and LAND 17 The Joint Fires scenario describes the actions for coordinated offensive support using beyond line of sight weapons against hostile terrestrial targets which are in close proximity to friendly ground forces. It includes capabilities provided by Army, Navy and Air Force coordinated in an NCW context. The metrics produced as an outcome of simulation allow for a comparison of capability options, be they candidate systems responding to the Request For Tender (RFT) or a comparison of the as-is and to-be capabilities. Some of the questions that may be answered by simulation include: range v cost, manning requirement (number and skill level), time and range to detect / react / destroy / battle damage assessment (BDA) / fire-foreffect, and coalition interoperability (different organisational structures). In our initial example, metrics will be collected to answer questions such as these for the whole scenario vignette, but particularly for artillery as may be required by a LAND 17 Desk Officer Process Following CEDA methodology, the broad steps that were followed prior to commencing the simulation work were as follows: 1. Collect stakeholder information and analyse domain information producing a Problem Definition (CV-1) and Operational Concept Narrative. Information used included the Australian Joint Task List (ASJTL) and descriptions of the organisational relationships. 2. A High Level Operational Concept Graphic (OV-1) and Strategic Views (StVs) were produced. An OV-1 was also produced for the illustrative scenario. 3. Determine tasks using ASJTL and operational concept; generate Organisational Relationship Chart (OV-4). 4. Create an operational architecture: Operational Activity Model (OV-5), Operational Node Connectivity (OV-2), Logical Data Model (OV-7), Operational Rules Model (OV-6a). At this point, there are sufficient architecture products to enable modelling and simulation to commence. These steps are similar to those followed in [1] using DoDAF. 5. FROM DAF TO DARNOS To facilitate the execution of the architecture, the DARNOS components are configured via a translation from the DAF architecture product. DARNOS uses XML as the data file format to both configure the simulation as a whole and define the behaviour of individual models such as the DMM. Therefore, by selecting an architectural design tool capable of exporting the DAF products (OVs, SVs, etc.) as XML, much of the translation from DAF to DARNOS can be automated. The BA2015+ architecture is being developed using the System Architect tool with the MODAF plug-in (as it supports Strategic Views). System Architect does allow the DAF products to be exported as XML. Conversion to DARNOS is achieved by the following steps: 1. Templates for the Expertise Blocks used by DARNOS are generated from the OV-6a. The implementation of the EBs is then completed manually. 2. The DARNOS social knowledge structures and the grouping of EBs into skill sets are created through an automatic conversion of the OV-5 exported from System Architect. 3. DARNOS teams and their associated skill sets are converted from OV-2 Physical Nodes and their associated Operational Activities. Currently need lines are not converted; instead they are inferred from the information exchange between operational activities. The last two steps above create data files that may be viewed and edited in KASEd and are loaded by the DMM at initialisation time. 4. Entity configurations within DARNOS are generated by mapping information in the SV-1 to available simulation components stored in a component library. By changing the components in the component library, or using different component libraries, the level of fidelity of the simulation can be set independently of the level of detail captured in the SV The final scenario configuration is performed using the DARNOS scenario editor. Once a DARNOS scenario has been created it can be executed within the synthetic environment. In future, we expect to be able to generate team structures from an OV-4. It In addition, it may prove useful to generate the C2 and networking links from an

6 OV-4 and to generate the structure of the Domain Knowledge from the OV-7. The steps described above are largely independent. As a result, once a fully configured scenario has been created subsequent updates to a single step can often be performed in isolation. For example, updating the OV- 5 does not always require updating other aspects of the scenario. 6. CONCLUSION As a unified architecture for the ADF Battlespace is produced, starting with the Battlespace Architecture project, the success in translating DAF architectural products into simulation will facilitate a more widespread use of modelling and simulation throughout capability lifecycles ensuring better quality outcomes for the ADF. To achieve this, extensions to this work that will be implemented over time include extending the depth of the architecture to cover other projects, and eventually the whole ADF capability, extending the fidelity of the simulation, and the use of other tools or simulation systems such as JSAF in relevant contexts throughout the capability lifecycle for both analysis and experimentation. The DMM has been reused in a number of other capability modelling environments, such as the Wedgetail Capability Modelling Environment (WCME), as the basis for behavioural modelling. Such reuse provides systems like WCME with the same capability as DARNOS. This will allow them to take advantage of the translation from DAF to simulation being developed under BA DoD Architecture Framework Version 1.5 Volume I: Definitions and Guidelines (2007). 5. Ling, M. & Selvestrel, M. (2005) An Organisation- Oriented Agents Approach to Modelling Network Centric Warfare, SimTecT 2005 Conference Proceedings, Sydney, Australia. 6. Maier, M. W. (1998) Architecting Principles for Systems-of-Systems, 7. The MODAF Architecture Framework Version 1.1 (2007), 8. Pogue, C. (2005) CapDEM Metrics Framework Applying Evolving Capability Metrics to CapDEM Walking the Talk. 9. Pogue, C. (2005) Unified Interoperability Solution Set to Support Interoperability Framework Development Municipal-Provincial-Federal Collaboration to CBRN Response. 10. Pogue, C.; Baker, K.; Pagotto, J. (2005) Capability Engineering Development of Human Views (HVs) Concept Paper, Human Views Workshop, Ottawa, Canada. 11. Tidhar, G.; Ling, M.; Shibi-Marr, O.; Selvestrel, M. (2006) Human-in-Loop Simulation to Support Experimentation and Concept Development, SimTecT 2006 Conference Proceedings, Melbourne, Australia. 12. Tidhar, G.; Selvestrel, M.; Ling, M. (2004) Employing Organisation-Oriented Agents to Model Network Centric Warfare, SimTecT 2004 Conference Proceedings, Sydney, Australia. ACKNOWLEDGEMENTS The authors would like to thank Abdel El-Sakka of the CDG NCWPO. The authors would like to acknowledge the other members of the combined CAE Professional Services and Raytheon team who have contributed to the success of the BA2015+ project in delivering the solution: David Glanville, Doug Hales, Phillip Loch, Michael McGarity, Chris Pogue, Mario Selvestrel, Gil Tidhar, Brian Vernon, Chris Walters. REFERENCES 1. AbuSharekh, A.; Kansal, S.; Zaidi, A., K.; Levis, A., H. (2007) Modeling Time in DoDAF Compliant Executable Architectures, Fifth Annual Conference On Systems Engineering Research Conference Proceedings, Hoboken, NJ, USA. 2. CIOG (2008) Australian Defence Architecture Framework Review Discussion Paper, version 0.4, 14 January DoD Architecture Framework Version 1.0 Deskbook (2003).