an overview of the capdem integrated engineering environment · an overview of the capdem...

An Overview of the CapDEM Integrated Engineering Environment

Sylvia Lam, Shiva Poursina and Tim Spafford

Defence R&D Canada √ Ottawa TECHNICAL MEMORANDUM

DRDC Ottawa TM 2005-118 July 2005

An Overview of the CapDEM Integrated Engineering Environment

Sylvia Lam DRDC Ottawa

Shiva Poursina MLTS Inc. Ottawa ON Tim Spafford Trident Systems Inc. Fairfax VA

Defence R&D Canada – OttawaTechnical Memorandum

DRDC Ottawa TM 2005-118

July 2005

DRDC Ottawa TM 2005-118 i

Abstract In order to gain a better understanding of the approach and the technology requirements to support collaborative engineering activities, the Collaborative Capability Definition, Engineering and Management (CapDEM) Technology Demonstration Project (TDP) initiated an effort to implement a Collaborative Engineering Environment (CEE). The US Naval CEE served as an early reference for the CapDEM team. The Integrated Engineering Environment (IEE) described in this report is one component of the Naval CEE. This IEE provides essential engineering data management functions as well as functionalities that enhance collaborative teamwork.

This implementation effort has provided first-hand experience to the CapDEM team in the understanding of the process involved in, and the requirements for, building an effective IEE. The details of this IEE implementation process, and the basic requirements for developing an effective IEE are described in this report.

Résumé Afin d’avoir une meilleure compréhension des exigences en matière de méthode et de technologie pour appuyer les activités d’ingénierie collaboratives, le personnel du Programme de démonstration de technologies (PDT) – Définition, ingénierie et gestion collaboratives de capacités (DIGCap) a amorcé une initiative pour mettre en œuvre un environnement d’ingénierie collaboratif (EIC). Tôt dans ce processus, le US Naval Collaborative Engineering Environment a servi de référence à l’équipe du DIGCap. L’environnement d’ingénierie intégré (EII) décrit dans le présent rapport est un élément du EIC de la marine américaine. Cet EII offre des fonctions de gestion de données techniques cruciales et des fonctionnalités qui améliorent la collaboration lors de travaux d’équipe.

Grâce à cette initiative, l’équipe du DIGCap a acquis une expérience directe du processus pour élaborer un EII efficace et des exigences pour y parvenir. Ce rapport comporte les détails de ce processus de mise en application d’un EII et les exigences de base pour élaborer un EII efficace.

ii DRDC Ottawa TM 2005-118

This page intentionally left blank.

DRDC Ottawa TM 2005-118 iii

Executive summary The function of a Collaborative Engineering Environment (CEE) is to provide project stakeholders with an effective interface by which to access information, utilize specialized applications and communicate with each other. Ultimately, the CEE should promote holistic system thinking, i.e., enable stakeholders to understand how they relate to each other in the project, hence improving their relationship to the process and its application through more effective collaboration. In order to gain a better understanding of the approach and the technology requirements to support collaborative engineering activities, the Collaborative Capability Definition, Engineering and Management (CapDEM) Technology Demonstration Project (TDP) initiated an effort to implement a CEE. The US Naval Collaborative Engineering Environment (NCEE) served as an early reference to the CapDEM team. The Integrated Engineering Environment (IEE) described in this report is one component of the NCEE. This IEE provides essential engineering data management functions as well as a flexible collaborative environment to support a geographically distributed project team. This implementation effort has provided first-hand experience to the CapDEM team to understand the process involved in, and the requirements for, building an effective IEE. The results are captured in Section 3 and 4, respectively. In short, the implementation process, as derived from the lessons learned, involves the following steps:

• Identify the application this environment will support

• Describe the engineering activities and engineering products to be generated

• Determine team composition and the computing environment (tools and network connectivity)

• Define workflow and dataflow within the IEE

• Develop/ modify / fine-tune the plug-ins that link tools to a central repository

The two basic requirements that contribute to an effective IEE are: • Integrated engineering data management and efficient data exchange that

enable team members to focus on their domain-specific tasks rather than worrying about data maintenance such as back ups, configuration management, and data integration.

• Effective way for team members to acquire project situation awareness that enables them to work independently yet maintaining enough awareness of the progress in the project to maintain self-synchronization.

Two future activities have been planned to utilize the existing IEE. First, the IEE will be used to provide engineering data management for the CapDEM Concept Development and Experimentation (CD&E) exercise. This CD&E exercise will employ the same set of tools to demonstrate the application of capability engineering concepts to support CD&E.

iv DRDC Ottawa TM 2005-118

Second, the IEE will be used to develop a Synthetic Environment Development Environment (SEDE). The purpose of the SEDE is to provide a facility that will assist the different types of Synthetic Environment (SE) users i.e. stakeholders who identify the problem to be addressed, engineers and specialists who provide engineering solutions, and SE implementers, so that SE can be delivered faster, better and cheaper. These two activities will be carried out in budget year 2005/06 under the CapDEM TDP.

Lam S, Poursina S, Spafford T. 2005. An Overview of the CapDEM Integrated Engineering Environment. Defence R&D Canada – Ottawa TM 2005-118

DRDC Ottawa TM 2005-118 v

Sommaire L’environnement d’ingénierie collaboratif (EIC) a pour but d’offrir aux intervenants d’un projet une interface performante pour accéder à de l’information, utiliser des applications spécialisées et communiquer entre eux. En bout de ligne, l’EIC devrait promouvoir une approche systémique, c’est-à-dire permettre à ces intervenants de comprendre leurs interrelations au sein du projet, améliorant ainsi leurs liens avec le processus et son application grâce à une collaboration plus efficace. Afin d’avoir une meilleure compréhension des exigences en matière de méthode et de technologie pour appuyer les activités d’ingénierie collaboratives, le personnel du Programme de démonstration de technologies (PDT) – Définition, ingénierie et gestion collaboratives de capacités (DIGCap) a amorcé une initiative pour mettre en œuvre un EIC. Tôt dans ce processus, le US Naval Collaborative Engineering Environment ([NCEE] environnement d’ingénierie collaboratif de la marine américaine) a servi de référence à l’équipe du DIGCap. L’environnement d’ingénierie intégré (EII) décrit dans le présent rapport est un élément du NCEE. Cet EII offre des fonctions de gestion de données techniques cruciales et un environnement de collaboration flexible pour appuyer une équipe géographiquement dispersée. Grâce à cette initiative, l’équipe du DIGCap a acquis une expérience directe du processus pour élaborer un EII efficace et des exigences pour y parvenir. Les résultats se trouvent dans les sections 3 et 4 respectivement. En gros, le processus de mise en œuvre qui a été déduit des leçons apprises comprend les étapes suivantes :

• identifier l’application appuyée par l’environnement;

• décrire les activités et produits d’ingénierie qui seront élaborés;

• déterminer la composition de l’équipe et l’environnement informatique (outils et connectivité de réseau);

• définir le déroulement des opérations et le flux de données au sein de l’EII;

• développer/modifier/mettre au point les utilitaires qui lient les outils au dépôt central.

Les deux exigences de base contribuant à l’efficacité de l’EII sont les suivantes : • Une gestion intégrée des données techniques et un échange efficace des

données pour permettre aux membres de l’équipe de se concentrer sur les tâches propres à leur domaine au lieu de se soucier de la maintenance des données, comme les copies de sécurité, la gestion de la configuration et l’intégration des données.

• Un moyen efficace de sensibiliser les membres de l’équipe à la situation du projet, ce qui leur permet de travailler indépendamment, tout en étant conscients des progrès du projet afin de conserver une autosynchronisation.

vi DRDC Ottawa TM 2005-118

Deux activités ont été prévues pour utiliser l’EII actuel. Premièrement, il servira à la gestion des données techniques au cours d’un exercice d’élaboration et d’expérimentation de concepts (EEC) du DIGCap. On utilisera lors de cet exercice d’EEC les mêmes outils pour démontrer l’application des concepts d’ingénierie des capacités en appui à l’EEC.

Deuxièmement, on utilisera l’EII pour élaborer un environnement de développement d’environnement synthétique. Cet environnement a pour but d’aider les différents utilisateurs d’environnement synthétique (ES), c.-à-d. les intervenants qui identifient les problèmes à rectifier, les ingénieurs et les spécialistes qui trouvent des solutions ainsi que les réalisateurs d’ES, en leur offrant une meilleure prestation d’ES - plus rapide et économique. Ces deux activités se dérouleront au cours de l’année financière 2005-2006 sous la tutelle du PDT DIGCap.

Lam S, Poursina S, Spafford T. 2005. An Overview of the CapDEM Integrated Engineering Environment. R & D pour la défense Canada – Ottawa DRDC Ottawa TM 2005-118

DRDC Ottawa TM 2005-118 vii

Table of contents

1. Introduction ................................................................................................................... 1

2. Background.................................................................................................................... 2 2.1 The NCEE .............................................................................................. 2

2.2 Tools in the IEE...................................................................................... 4 2.2.1 DOORS............................................................................................... 4 2.2.2 CORE.................................................................................................. 5 2.2.3 Rational Rose / Rose RT ................................................................... 5 2.2.4 Interchange SE ................................................................................... 5 2.2.5 OPNET ................................................................................................ 6 2.2.6 IPME ................................................................................................... 6 2.2.7 Linkage to M&S / T&E Environment ................................................. 6

2.3 Considerations Affecting IEE Implementation ...................................... 7

3. Implementing the CapDEM IEE ................................................................................... 8 3.1 The Application...................................................................................... 8

3.2 Engineering Activities Supported by IEE .............................................. 9

3.3 Team Members and their Roles ............................................................. 9

3.4 Workflow and Dataflow in the IEE...................................................... 11

3.5 Live Demonstration of the IEE ............................................................ 13

4. Two Basic Requirements for an Effective IEE............................................................ 16 4.1 Engineering Data Management ............................................................ 16

4.2 Situation Awareness............................................................................. 16

4.3 IEE Functions Supporting Collaboration ............................................. 17

5. Concluding Remarks ................................................................................................... 19

6. References ................................................................................................................... 20

viii DRDC Ottawa TM 2005-118

List of figures

Figure 1 US Naval Collaborative Engineering Environment ..................................................... 2

Figure 2 US Naval IEE and the associated engineering process ................................................ 3

Figure 3 Configuration of the CapDEM IEE.............................................................................. 4

Figure 4 Systems Engineering Process....................................................................................... 8

Figure 5 The Integrated view of the activities and team members supported by the IEE ........ 12

Figure 6 Engineering Workflow used in the Live Demonstration............................................ 15

Figure 7 Parameters describing the Nature of Collaboration ................................................... 17

DRDC Ottawa TM 2005-118 ix

Acknowledgements

Staff at Trident Systems Inc. has provided excellent technical support to make this implementation a successful endeavour.

x DRDC Ottawa TM 2005-118

This page intentionally left blank.

DRDC Ottawa TM 2005-118 1

1. Introduction A Collaborative Engineering Environment (CEE) is an environment that makes use of a mixture of communication and information technologies to facilitate distributed teamwork at multiple geographically-distributed locations. The function of such an environment is to provide project stakeholders with an effective interface by which to access information, utilize specialized applications and communicate with each other. Ultimately, the CEE is intended to promote holistic system thinking, i.e., enable stakeholders to understand how they relate to each other in the project, hence improving their relationship to the process and its application through more effective collaboration. In order to gain a better understanding of the approach and the technology requirements to support collaborative engineering activities, the Collaborative Capability Definition, Engineering and Management (CapDEM) Technology Demonstration Project (TDP) initiated an effort to implement a CEE. The US Naval Collaborative Engineering Environment (NCEE), as described in Section 2, served as an early reference to the CapDEM team. The Integrated Engineering Environment (IEE) described in this report is one component of the NCEE. This IEE provides essential engineering data management functions as well as a flexible collaborative environment to support a geographically distributed project team. The main challenges and lessons learned are documented in [1]. This report provides futher technical details on the implementation. Implementing an IEE is more than just linking a set of tools together. In order to optimize the functionality and performance, it requires careful planning and detail discussions with team members to understand the project objectives, members’ roles in the project and their existing workflow and toolset to accomplish their tasks. An IEE implementation process is documented in Section 3, together with a high level description on various aspects of this implementation. Based on the experience gained from this implementation, the implementation team identified two basic requirements for and IEE to support effective distributed teamwork: 1) strong project engineering data management, and 2) ability to promote project situation awareness to all team members. These two requirements are described in Section 4. The IEE functionalities that contribute to these two requirements are also listed in this section. Section 5 concludes this report by reiterating the benefits gained by this implementation and describes future activities based on this IEE.

2 DRDC Ottawa TM 2005-118

2. Background Being closely linked to The Technical Cooperative Panel (TTCP) Joint Systems Analysis (JSA) Technical Panel 4 (TP4) activities, CapDEM benefits from the TTCP members’ experience in building collaborative environments. Among the member nations, the US Navy Chief Engineering Office (CHEng) offered their existing CEE, referred to as the NCEE, as a case study for other nations. Consequently, CapDEM decided to follow the NCEE approach to implement the CapDEM IEE.

2.1 The NCEE The NCEE, as shown in Figure 1, consists of three elements: the Decision Support Environment (DSE), the Integrated Engineering Environment (IEE) and the Interoperability Data Management and Analysis (IDMA) Environment. A detailed description of the NCEE can be found in [2]. The purpose of the NCEE is to provide an integrated digital environment that enhances the cooperation and exchange of data, information, knowledge among Naval stakeholders engaged in force systems integration and interoperability activities, and enables the integration and interoperability of systems across the spectrum of the Naval acquisition process.

Figure 1 US Naval Collaborative Engineering Environment


The Naval IEE features an integrated set of tools that supports distributed engineering teams engaged in requirements analysis, functional analysis, system synthesis and assessment of forces system architectures. A centralized repository maintains a systems database structure that is common to all platforms and systems within the Naval force. Figure 2 shows the US Naval IEE concept, the related toolset, and the flow of engineering process within the IEE.

Figure 2 US Naval IEE and the associated engineering process

Based on the input from NCEE, CapDEM started to implement its IEE in late 2003. Figure 3 shows the current configuration of this environment. The two-way arrows between the tools and the project repository (Interchange Server) indicate that data flows between the project repository and tools through the use of plug-ins. This IEE resembles that of the NCEE with a similar set of Commercial-Off-The-Shelf (COTS) products, they are: DOORS, CORE, Rose and Interchange. Two software tools have been added to this basic toolset. OpNET is a specialized network analysis tool, and Integrated Performance Modeling Environment (IPME) is a human performance analysis tool. The IEE is currently implemented on the Defence Research Establishment Network (DRENet) Joint Simulation Network (JsimNet) subnet, and users of the DRENet can access this environment regardless of their physical location. Currently users at Defence Research Development Canada (DRDC) Ottawa at Shirley’s Bay, DRDC Valcartier (Quebec) and at Joint Staff Operational Research Team (JSORT), have successfully accessed the project repository during several technical trials.


Figure 3 Configuration of the CapDEM IEE

2.2 Tools in the IEE The toolset in the IEE contains the products:

• DOORS • CORE • Rational Rose / Rose RT • Interchange SE • OpNET • IPME

2.2.1 DOORS DOORS is a popular requirements management and analysis tool developed by Telelogic Inc. [3]. It provides the utilities needed to capture, track and manage user requirements. Requirements can be entered directly into DOORS using its familiar word processor style interface. Once the requirements are captured in DOORS, they can be tracked and managed throughout the project life cycle using a variety of features, such as views, links and traceability analyses.


2.2.2 CORE CORE is a functional analysis tool developed by Vitech Inc. [4]. The CORE product family provides a flexible combination of modeling and simulation tools supporting product and process engineering. CORE's object-oriented environment delivers the same functionality from a single user workstation to large, distributed, client-server teams.

COREsim allows execution of the integrated architecture by dynamically inferring the behavior model that resides in the system design repository. Discrete-event simulation logic identifies timing, resource utilization, and model inconsistency including:

• Timeline Analysis - COREsim timeline analysis identifies the sequential and concurrent events that occur during the simulation based upon data triggers, resource availability, random probabilities, and outcomes.

• Resource Analysis - COREsim resource analysis monitors resource availability to identify bottlenecks, resource contention, and queuing effects on system performance.

• Consistency Analysis - COREsim may be used interactively to identify logical inconsistencies as the behavioural model is developed. This provides the engineer with a dynamic modeling construction kit for establishing a complete and logically consistent model of system behaviorl.

2.2.3 Rational Rose / Rose RT Rational Rose family of products is a set of popular modeling and development tools developed by IBM Inc. [5]. Data Modeller is a visual modeling tool that makes it possible for database designers, analysts, architects, developers and anyone else on your development team to work together, capturing and sharing business requirements, and tracking them as they change throughout the process. It provides the realization of the ER methodology using Unified Modeling Language (UML) notation to bring database designers together with the software development team. With UML, the database designer can capture information like constraints, triggers and indexes directly on the diagram rather than representing them with hidden properties behind the scenes. Rational Rose Data Modeller gives you the freedom to transfer between object and data models and take advantage of basic transformation types such as many-to-many relationships. This tool provides an intuitive way to visualize the architecture of the database and how it ties into the application.

2.2.4 Interchange SE InterchangeSE is a data integration environment developed by Trident Systems Inc. [6]. Interchange SE allows the user to:

• Graphically view or edit any information in the repository

• Configuration manage the data across all domains of information

• Share common data between similar applications

• Interrelate data between applications in different domains


Interchange provides a common entity-relationship graphic interface so that anyone with the Interchange client on his or her desktop can graphically view and edit any of the information in the repository. This allows them to participate in distributed design reviews, quickly access and analyze information to make decisions or make simple changes or additions to the data without having to know how to use the different tools used on the project just to view the information. Having a common interface to this integrated information saves on training and licensing of the other tools. Interchange is not meant to replace the engineering, cost and project management tools. Only selected people working in a domain would have to license the specialized tools and get detailed training. The user can also graphically verify data completeness by performing complex queries or drill-downs that place interrelated information from multiple domains in a single view. Finally, Interchange can provide automated alerts to the user to changes to objects of interest.

2.2.5 OPNET OPNET Technologies Inc. is a leading provider of management software for networks and applications [7]. OPNET’s solutions address: application performance troubleshooting; network configuration and security auditing; network capacity and resiliency planning; application deployment planning; systems capacity planning; and network technology R&D. OPNET solutions have been operationally proven in thousands of customer environments worldwide, including corporate enterprises, government and defense agencies, network service providers, and network R&D organizations.

2.2.6 IPME

The Integrated Performance Modeling Environment (IPME) is a Unix-based integrated environment of simulation and modeling tools for answering questions about systems that rely on human performance to succeed. IPME provides [8]:

• A realistic representation of humans in complex environments

• Interoperability with other models and external simulations

• Enhanced usability through a user friendly graphical user interface IPME provides a full-featured discrete event simulation environment built on the Micro Saint modeling software. Additionally, it provides added functionality to enhance the modeling of the human component of the system. Finally, it has a number of features that make it easier to integrate IPME models with other simulations on a real-time basis including TCP/IP sockets and tools for developing simulations that adhere to the Higher Level Architecture (HLA) simulation protocols that are becoming standard throughout the world.

2.2.7 Linkage to M&S / T&E Environment The linkage to a Modeling and Simulation (M&S) / Testing and Evaluation (T&E) environment is desirable because of the potential benefits of using M&S to support trade


studies and concept validation. However, due to the complexity of linkage to a synthetic environment (SE), the CapDEM team decided to address this linkage at a later time.

2.3 Considerations Affecting IEE Implementation Although the tools in the CapDEM IEE were selected based on NCEE recommendations, there were other considerations that contribute to the complexity of the implementation. The influencing factors include:

• the application this environment supports

• the engineering activities and products to be generated

• the engineering team members and their roles

• the workflow and dataflow

Section 3 describes these aspects of the IEE implementation in detail


3. Implementing the CapDEM IEE The CapDEM team has gained valuable hands-on experience from this implementation, and through the lessons learned, the team derived the following implementation process:

Step 1. Identify the applications this environment will support Step 2. Describe engineering activities and products Step 3. Determine team members’ roles and their computing environment (tools and network connectivity) Step 4. Define workflow and dataflow within the IEE Step 5. Develop/ modify / fine-tune the plug-ins that link tools to a central repository The rest of this section describes the current IEE implementation following this process.

3.1 The Application Although the IEE has been developed to support a generic systems engineering process, the CapDEM team believed a concrete example was needed to guide the implementation. The Joint Information and Intelligence Fusion Capability (JIIFC) Project [9], one of the CapDEM use cases, was selected. This application of the environment provided the team with a good understanding of its requirements and the engineering team composition needed for successful implementation of the process within it.. In addition, project datasets are available for dataflow development and testing purposes. Figure 4 shows the systems engineering process as applied to the JIIFC Project.

Figure 4 Systems Engineering Process


3.2 Engineering Activities Supported by IEE Engineering activities define the workflow within the IEE. The activities described below are derived from the experience gained from the JIIFC use case, as well as from common systems engineering practices. Develop Operational Needs / Deficiencies: The statement of operational needs / deficiencies

is usually developed by management stakeholders at the strategic level. The deficiencies are then translated into high level operational requirements with preliminary key performance parameters. Although this activity may not directly involve the engineering team at the project level, this will be the trigger to initiate a project, and the operational requirements document will be crucial in defining the project’s objectives.

Develop Originating Requirements: This activity identifies the mission and the scope of the

project. It relates to the originating requirements to the operational needs within a set of predefined scenarios. In order to determine the customer acceptance of the system, an objective hierarchy of the system is created. An external systems diagram is also produced at this stage to identify the inputs and outputs of the system.

Perform Enterprise Change Proposal (ECP) Functions: This activity is responsible for the

approval of all requirements submitted for approval at each layer of modeling. Define Operational Model: This activity captures the operational architecture according to

the selected architecture framework. Since the operational architecture is likely to be a team effort, the various parts of the models must be integrated to provide a complete and consistent picture of the operational architecture.

Define System Model: This activity captures the systems architecture according to the

selected architecture framework. Since the systems architecture is likely to be a team effort, the various parts of the models must be integrated to provide a complete and consistent picture of the systems architecture. In addition, several options on systems design may be proposed and evaluated to derive the optimal solution. This will require strong traceability between proposed designs and trade studies (analysis results).

Define Human Factor Performances: This activity models the human-systems interface at a

more detailed level in order to evaluate the performance and identify requirements related to human factors.

Manage Models: This activity encompasses many house-keeping functions required to maintain

the central repository. Define Network Performance: This activity models the network connectivity at a more

detailed level in order to evaluate the performance and identify requirements related to communications network.

3.3 Team Members and their Roles Like the engineering activities, the roles of the team members influence the design of the workflow within the IEE. The following team members and their respective roles have been


developed based on the experience captured in the JIIFC use case and other roles that are needed to support the activities defined above. Stakeholders: The stakeholders develop the Concept of Operations (CONOPS) document.

This document will be used to determine project requirements, the external systems diagram and the objectives hierarchy. Frequent interface between the project team and the stakeholders may be required at the beginning of the project to ensure project team interprets stakeholder’s needs correctly.

Change Control Board (CCB): The role of the change control board is to assess the change

requests created during systems analysis. These include problem reports, derived requirements, new requirements, functional architecture variants. The changes agreed upon by the change control board will be submitted to the requirements analyst for appropriate action.

Requirements Analyst: The role of the requirements analyst is to manage the requirements

identified throughout the project definition phase into the requirements database. Other responsibilities include the management of the requirements baseline after change request submitted by the change control board. This ensures that all derived/changed requirements are forwarded from the DOORS database to the central repository dataset within Interchange

Operational Architecture Modeler: The Operational Architecture Modeler is responsible for

capturing operational data and processes and developing the operational architecture model according to a specified architecture framework. The key activities are developing an activity model and partitioning the activities into the various roles performed. In system engineering terms this is basically developing the functional baseline.

System Architecture Modeler: The role of the System Architecture Modeler is to develop

the system architecture model according to a specified framework. The key activities are to define the physical model, defining the functions performed by each of the physical components, and mapping of the activities to the functions. In systems engineering terms this is the development of the allocated baseline.

Functional Analyst: The Functional Analyst is responsible for developing the functional

model (what the system must do, that is the system functions and the data flows between them). In the final analysis the functional analyst produces the operational activities and the information exchanges among them. After the operational activities are defined the functional analyst defines how they are implemented by system functions. The functional analyst may also develop executable models of both the operational activity model and system functional model. The role of the functional analyst is inherited by the Operational Architecture Modeler and System architecture Modeler.

Human Factor Analyst: The role of the Human Factor Analyst is to decompose the

operational activities into discrete tasks that are handled by human operators and / or computer systems. The human factor analyst shall provide performance prediction of the human-in-the-loop, which can affect the rewriting of requirement.


Model Manager (Interchange) / Analyst: The role of the Model Manager / Analyst is to manage the integrated architecture models and provide configuration support and synchronization between the models in the central repository currently support by Interchange. This Analyst ensures that the models are consistent as they are being developed and integrated. He/She also enforces the workflow process and provides notification to appropriate team members regarding changes in the databases that may impact their work.

Communication Network Modeler: The role of the Communication Network Modeler is to

detail the network engineering requirements (bandwidth, latency, performance). The Network Modeler takes the physical model from Interchange (originally developed in CORE) and creates the network topology within OPNET. After simulation is completed the derived requirements, problem reports and network topology elements must be sent to Interchange where they are incorporated into the requirements via the change control process.

3.4 Workflow and Dataflow in the IEE Workflow identifies the steps and interactions between team members to execute the engineering activities, and dataflow describes the sequence and content of data exchange between tools. Figure 5 illustrates the interaction among the engineering team members and their activities. The complete description of the workflow is an elaborated document and can be better viewed in a web-based UML model [9]. An instance of the workflow is provided in Section 3.5.


CapDEM IEE Process Use Case Model

Functional Analyst

(from CapDEM Actors)

Perform ECP functions

(f ro m Cap DEM System Use Ca ses)

Change Control Board


Define Network Performance

(f rom CapDEM Syste m Use Case s)

Network Modeler

(f rom Cap DEM Acto rs)

Manage Requirements Baseline

(f rom CapDEM System Use Cases)

Develop Originating Requirements

(from CapDEM System Use Cases)

Requirements Analyst


Manage Models


<<include>>

<<include>>

Model Manageme...


Define Human Factor Performance


<<include>>

Human factor Analyst

(f rom Cap DEM Acto rs)

Define Operational Model


<<Include>>

CORE Operation...


Define System Model


<<include>>

CORE System Architectu...


Develop Operational Needs

(from CapDEM System Use Cases)Stakeholder

(f rom Ca pDEM Actors)

<<include>>

<<include>>

Figure 5 The Integrated view of the activities and team members supported by the IEE


3.5 Live Demonstration of the IEE A “live” demonstration of the CapDEM IEE was performed in December 2004 at the Future Forces Synthetic Environments (FFSE)/DRDC Advanced Collaborative Capability Engineering and System (ACCES) Facility in Ottawa. Understanding that normal systems engineering activities usually takes days, and more likely weeks, to complete, it is difficult to demonstrate the actual workflow in an one hour demonstration. However, the authors believed that the audience would gain a better appreciation of the IEE if they could visualize the engineering workflow. As a result, the CapDEM team decided to take a “cooking show” approach to demonstrate the IEE. The “cooking show” approach required the team to prepare several sets of datasets in advance, and demonstrate only the relevant steps of the workflow (e.g. executing the plug-ins) in real time. The demonstration showed the activities in the IEE following the workflow/dataflow below. Figure 6 depicts graphically the same sequence of event. The numbers noted on Figure 6 correspond to the numbers listed under each activity below. Create Requirements database in DOORS

1. Create the originating requirements database in DOORS by creating two modules (A&B) for the Statement of Operations (SOR) and Concept of Operations (ConOps) respectively.

Upload requirements database to the central repository

2. Export requirements to Interchange (the central repository) by running DOORS script to export these modules in CSV (common separated value) format.

3. Import these CSV files into Interchange (create 3 models A, B and X, which is the union of A and B).

Export requirements to CORE-readable format (i.e. rdt file)

4. Create new model C in Interchange. Make Model C the default container and add to it the selected requirements to be to export to CORE.

5. Set up a change notification agent in Interchange to monitor the changes to these requirements.

6. Export model C by running the appropriate export command in Interchange. This will generate a rdt file

Importing the requirements into CORE and perform functional analysis

7. Import the rdt file generated in the previous step into Core.

8. The architecture team develops the architecture models and performs functional analysis to determine if requirements are achievable within project constraints.


9. If a problem is discovered with an originating requirement, an issue is created and linked to the affected requirement(s).

Export Issues identified in functional analysis back into Interchange

10. Import the rdt file with the architecture model and related issues generated in the previous step into Model C in Interchange. The changes defined in the rdt file are merged into the existing Model C in Interchange.

11. Change notification agents will be triggered if there are issues attached to requirements being monitored (e.g. CCB members will receive email notification).

12. CCB accesses Interchange to view the open Problem Reports that contain issues identified by functional analysts.

Resolve issues

13. Conduct CCB to resolve open issues.

14. Update DOORS database with any changes required as a result of the CCB decision.

Update central repository after CCB

15. Run DOORS export script to generate CSV files for each module.

16. Update Model X in Interchange with the new CSV files generated from DOORS.

17. Change the CORE Export attribute of Model C to “incremental”.

18. Return to step 6 if needed.

Export CORE physical connectivity model to OPNET

19. Create high level communication model in CORE

20. Merge the changes to the Core model into Model C in Interchange.

21. Create new Model D in Interchange. Make Model D the default container and add to it the objects to be to exported to OPNET.

22. Export the Model D as an XML file to OPNET

23. Perform Network Analysis in OPNET

Import OPNET model into central repository

24. Report Network related issues and create XML export file

25. Update Model D in Interchange with the OPNET XML file.


Figure 6 Engineering Workflow used in the Live Demonstration


4. Two Basic Requirements for an Effective IEE Based on the experience gained from this implementation, two basic requirements for an effective IEE became evident. First, the need for a strong engineering data management scheme for the project team, and second, the ability to enable project level situation awareness.

4.1 Engineering Data Management To allow a distributed project team to be productive, it is essential to provide, at minimum, the following data management functions in an integrated manner:

• Ability to control data access to ensure data integrity

• Ability to configuration manage data

• Ability to integrate engineering data and models to facilitate content validation

A common approach to project data management is using a shared folder as a central data repository where most team members can deposit and retrieve project related information. Some of the problems related to using only a shared folder for data management include:

• Difficulties in identifying the appropriate version or approved baseline of engineering / architecture products

• Difficulties in finding files because they could be easily misplaced or overwritten

• No integrated data management, have to rely on individuals to maintain their data.

• Lack of common approach to maintain history of product development.

• Data cannot be reused readily

• Not possible to integrate and validate data / engineering models

Although some of these problems can be resolved by enforcing a manual process to maintain the central repository, it is an unnecessary burden on the team members, and often becomes a source of frustration when data is mishandled.

4.2 Situation Awareness Besides being able to focus on their own engineering tasks, team members must develop a sense of awareness of the on-going situation of the project, and understand how their work contribute to its progress. This is particularly important for a geographically distributed project team where frequent face-to-face interaction may not be possible. One way to improve situation awareness is to provide an environment that enhances interaction. The parameters describing the nature of collaboration can be found in reference [11]. The nature of collaboration can be described by the degree of reach, richness and quality of information. Figure 7 provides a graphical summary of these parameters.


Figure 7 Parameters describing the Nature of Collaboration

A combination of a data repository, telephone conversations, emails, video conferencing and face-to-face meetings are commonly used to keep team members informed on project status, issues and solutions. Many people are familiar with the limitations of using these approaches for communication. Telephone tags, flooded email boxes, mountains of duplicated documents, lost data due to technical or human errors, information captured in various forms that cannot be searched easily are just some examples of issues project teams have to deal with.

4.3 IEE Functions Supporting Collaboration The IEE is not a panacea, but it does offer functions that facilitate distributed teamwork. It provides strong support on integrated engineering data management, allowing Individual members to focus on performing their engineering tasks rather than worrying about data maintenance and synchronization. Many of the IEE functions also enhance the nature of collaboration described in Figure 7. The Interchange SE repository provides the data management functions of the IEE. Together with a set of plug-ins that enable effective data flow between domain engineering tools to the central repository, and a well-defined workflow process, much of the project level data management routines will be carried out on the central repository by a database administrator. IEE data management functions include:


• A common repository and data schema to store all architecture data, trade study analyses and project related documents

• Integrate data / model within the repository

• Provide integrated views of engineering data / models generated by various team members.

• Automatic version control and selective baselining of data and models to enforce data consistency and enable synchronization of activities

• Access control by user profile

• Efficient data flow between domain-specific tools to facilitate data exchange and reuse.

• Automatic change notification to subscribers on selected data elements

• Automatic generation of reports on subscribed contents

To enhance project situation awareness, the IEE offers the following functions to improve collaboration.

Reach:

• Asynchronous (space and time): IEE is accessible through various computer networks so project information is reachable by authorized team members on demand.

• Selective: user profiles determine data access. In addition, agent services (e.g. change notification agent) are provided based on subscription. These two features provide selectivity on both the users and the data.

• Simultaneous: multi-user concurrent access to the database is supported through web-interface or Interchange clients.

Richness:

• Multi-media support: User can attached and view any media file in any format to the central repository as long as the application software (or a viewer software) is accessible from the Interchange Server.

• Tools: The use of plug-ins allows data flow between the central repository and specialized engineering tools.

Quality of Interaction: The current IEE is not designed to support multi-user interaction.

Although the IEE is not intended to support real-time multiple user interaction, the combination of tools and technologies in the overall CEE will supplement this deficiency in the IEE.


5. Concluding Remarks This IEE implementation has been a worthwhile exercise because it has generated valuable first-hand experience for the CapDEM team to understand the process involved in, and the requirements for, building an effective IEE. The results are captured in Section 3 and 4, respectively. To reiterate, the implementation process, as derived from the lessons learned, involves the following steps:

• Identify the application this environment will support

• Describe the engineering activities and engineering products to be generated

• Determine team composition and the computing environment (tools and network connectivity)

• Define workflow and dataflow within the IEE

• Develop/ modify / fine-tune the plug-ins that link tools to a central repository

The two basic requirements that contribute to an effective IEE are:

• Integrated engineering data management and efficient data exchange that enable team members to focus on their domain-specific tasks rather than worrying about data maintenance such as back ups, configuration management, and data integration.

• Effective way for team members to acquire project situation awareness that allows team members to work independently yet maintain enough awareness of the progress in the project to maintain self-synchronization.

The major challenges encountered and lessons learned from this exercise have been captured in [1]; therefore, they will not be repeated in this report Two future activities have been planned to utilize the existing IEE. First, the IEE will be used to provide engineering data management for the CapDEM Concept Development and Experimentation (CD&E) exercise. This CD&E exercise will employ the same set of tools to demonstrate the application of capability engineering concepts to support CD&E. Second, the IEE will be used to develop a Synthetic Environment Development Environment (SEDE). The purpose of the SEDE is to provide a facility that will assist the different types of Synthetic Environment (SE) users i.e. stakeholders who identify the problem to be addressed, engineers and specialists who provide engineering solutions, and SE implementers, so that SE can be delivered faster, better and cheaper.. These two activities will be carried out in FY 05/06 under the CapDEM TDP.


6. References

1. Robbins W, Lam S and Lalancette C, (In press). “Towards a Collaborative Engineering Environment to Support Capability Engineering”. INCOSE July 2005 Rochester NY.

2. Crisp, HE, Chen P, (2002). Coalition collaborative Engineering Environment. INCOSE Insight Vol 5 Issue 3. October 2002. pp. 13-15. A publication of the International Council on Systems Engineering

3. DOORS Online documentation, http://www.telelogic.com

4. CORE Online documentation, http://www.vitechcorp.com

5. Rational Online Documentation, http://www.rational.com

6. Interchange User Guide, http://www.interchangese.com

7. OPNET product information website http://opnet.com/investor_relations/opnet_2004ar.pdf

8. IPME product information website http://www.maad.com/index.pl/ipme

9. Ramotar, R. 2004. Internal Document UML rational rose model on IEE workflow and dataflow.

10. Lam, S, Fliesser, RJ, Pagotto, J, (2005). Applying Capability Engineering Concepts to Support JIIFC Project Definition. DRDC Ottawa TM 2005-113. Defence R&D Canada – Ottawa

11. Aleberts DS, Hayes RE, (2003). Power to the Edge: Command and Control in the Information Age. CCRP Publication Series. http://www.dodccrp.org/html/pubs_pdf.html.


List of symbols/abbreviations/acronyms/initialisms

CapDEM Collaborative Capability Definition, Engineering and Management

CEE Collaborative Engineering Envrionment

CONOPS Concept of Operation

COTS Commercial Off TheShelf

DRDC Defence Research and Development Canada

DSE Decision Support Environment

ECP Enterprise Change Proposal

HLA High Level Architecture

IDMA Interoperability Data Management and Analysis Environment

IEE Integrated Engineering Environment

IPME Integrated Performance Modeling Environment

JSA Joint Systems Analysis

JSORT Joint Staff Operational Research Team

M&S Modeling and Simulation

NCEE Naval Collaborative Engineering Environment

SE Synthetic Environments

T&E Test and Evaluation

TDP Technology Demonstration Projects

TTCP The Technical Cooperative Panel

UML Unified Modeling Language

UNCLASSIFIED SECURITY CLASSIFICATION OF FORM

(highest classification of Title, Abstract, Keywords)

DOCUMENT CONTROL DATA (Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified)

1. ORIGINATOR (the name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g. Establishment sponsoring a contractor’s report, or tasking agency, are entered in section 8.)

Defence R&D Canada – Ottawa 3701 Carling Avenue Ottawa ON K0A 1Z4

2. SECURITY CLASSIFICATION (overall security classification of the document,

including special warning terms if applicable) UNCLASSIFIED

3. TITLE (the complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S,C or U) in parentheses after the title.)

An Overview of the CapDEM Intergrated Engineering Environment (U)

4. AUTHORS (Last name, first name, middle initial)

Lam, Sylvia; Poursina, Shiva; Spafford, Tim

5. DATE OF PUBLICATION (month and year of publication of document)

July 2005

6a. NO. OF PAGES (total containing information. Include Annexes, Appendices, etc.)

22

6b. NO. OF REFS (total cited in document)

11

7. DESCRIPTIVE NOTES (the category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.)

Technical memorandum

8. SPONSORING ACTIVITY (the name of the department project office or laboratory sponsoring the research and development. Include the address.)

DRDC Ottawa 3701 Carling Avenue Ottawa ON K0A 1Z4

9a. PROJECT OR GRANT NO. (if appropriate, the applicable research and development project or grant number under which the document was written. Please specify whether project or grant)

15AS01

9b. CONTRACT NO. (if appropriate, the applicable number under which the document was written)

10a. ORIGINATOR’S DOCUMENT NUMBER (the official document number by which the document is identified by the originating activity. This number must be unique to this document.)

DRDC Ottawa TM 2005-118

10b. OTHER DOCUMENT NOS. (Any other numbers which may be assigned this document either by the originator or by the sponsor)

11. DOCUMENT AVAILABILITY (any limitations on further dissemination of the document, other than those imposed by security classification) ( x ) Unlimited distribution ( ) Distribution limited to defence departments and defence contractors; further distribution only as approved ( ) Distribution limited to defence departments and Canadian defence contractors; further distribution only as approved ( ) Distribution limited to government departments and agencies; further distribution only as approved ( ) Distribution limited to defence departments; further distribution only as approved ( ) Other (please specify): canadian contractors

12. DOCUMENT ANNOUNCEMENT (any limitation to the bibliographic announcement of this document. This will normally correspond to

the Document Availability (11). However, where further distribution (beyond the audience specified in 11) is possible, a wider announcement audience may be selected.)

UNLIMITED.

UNCLASSIFIED

SECURITY CLASSIFICATION OF FORM DDCCDD0033 22//0066//8877

UNCLASSIFIED SECURITY CLASSIFICATION OF FORM

13. ABSTRACT ( a brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual).

In order to gain a better understanding of the approach and the technology requirements to support collaborative engineering activities, the Collaborative Capability Definition, Engineering and Management (CapDEM) Technology Demonstration Project (TDP) initiated an effort to implement a CEE. The US Naval Collaborative Engineering Environment (NCEE) served as an early reference for the CapDEM team. The Integrated Engineering Environment (IEE) described in this report is one component of the NCEE. This IEE provides essential engineering data management functions as well as functionalities that enhance collaborative teamwork. This implementation effort has provided first-hand experience to the CapDEM team in the understanding of the process involved in, and the requirements for, building an effective IEE. The details of this IEE implementation process, and the basic requirements for developing an effective IEE are described in this report.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (technically meaningful terms or short phrases that characterize a document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus-identified. If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.)

Integrated Engineering Envrionment Collaborative Engineering Environment Engineering Data Management Capability Management and Engineering

UNCLASSIFIED

SECURITY CLASSIFICATION OF FORM

an overview of the capdem integrated engineering environment · an overview of the capdem...

Documents