model and data management tool for the air force structure analysis model - final...

Model and Data Management Tool for the Air Force Structure Analysis Model - Final Report

D.G. Hunter DRDC CORA

Prepared By: CAE Integrated Enterprise Solutions - Canada 1135 Innovation Drive Ottawa, ON, K2K 3G7 Canada Telephone: 613-247-0342 Fax: 613-271-0963 Technical Lead, Simulation Systems Contractor's Document Number: 5394-002 version 02 Contract Project Manager: W. Scott Guenther, 613-247-0342 PWGSC Contract Number: W7714-083663 CSA: D.G. Hunter, Defence Scientist, 613-996-3895

The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada.

Defence Research and Development Canada – CORA Contract Report DRDC CORA CR 2013-197 November 2013

IMPORTANT INFORMATIVE STATEMENTS

The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada.

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2013

© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2013

DRDC CORA CR 2013-197 i

Abstract ……..

This report provides the background to the development and a detailed description of the Model and Data Management Tool (MDMT). MDMT was created to provide a user-friendly wrapper for various versions of the Air Force Structure Analysis (ASTRA) model. Its primary function is to keep track of the model versions along with all input data, output data and associated meta-data for the models and for each execution of the model.

Résumé ….....

Le présent rapport décrit le contexte de développement de l’outil MDMT (Model and Data Management Tool) et donne une description détaillée de l’outil. Nous avons créé l’outil MDMT (Model and Data Management Tool) afin d’offrir une enveloppe conviviale pour diverses versions du modèle ASTRA (Air Force Structure Analysis). La fonction principale de l’outil est de faire le suivi des versions du modèle ainsi que des données d’entrée et de sortie et des métadonnées connexes associées aux modèles et à chaque exécution du modèle.

ii DRDC CORA CR 2013-197

This page intentionally left blank..

CAE Integrated Enterprise Solutions – Canada (CAE IES)

1135 Innovation Drive Ottawa, Ont., K2K 3G7 Canada

Telephone: 613-247-0342 Fax: 613-271-0963

MODEL AND DATA MANAGEMENT TOOL FOR THE AIR FORCE STRUCTURE ANALYSIS MODEL

FINAL REPORT

CONTRACT #: W7714-083663

FOR

GREGORY HUNTER

101 Colonel By Drive Ottawa, Ontario

K1A 0K2

2 8 M a r c h 2 0 1 3

Document No. 5394-002 Version 02

Model and Data Management Tool for the

Air Force Structure Analysis Model Final Report

28 March 2013 – iii – 5394-002 Version 02

R E V I S I O N H I S T O R Y

Revision Reason for Change Origin Date Version 01 Version 02

Initial document issued Final document – Incorporation of client feedback

19 March 2013 28 March 2013



28 March 2013 – iv – 5394-002 Version 02

T A B L E O F C O N T E N T S

1 INTRODUCTION ..................................................................................................... 1 1.1 Background .......................................................................................................... 1 1.2 Objective .............................................................................................................. 2 1.3 Outline .................................................................................................................. 2

2 MDMT SYSTEM DESCRIPTION ............................................................................ 3 2.1 System Architecture ............................................................................................. 3 2.2 MDMT ................................................................................................................... 4 2.2.1 Perform Analysis Tab ......................................................................................... 4 2.2.2 Scenario Tab ..................................................................................................... 5 2.2.3 Develop Model Tab ............................................................................................ 6 2.2.4 Input Tab ............................................................................................................ 7 2.2.5 Output Tab ......................................................................................................... 8 2.2.6 Input/Output Metadata Tab ................................................................................ 9 2.2.7 Compatibility Tab ............................................................................................. 10 2.2.8 Raw Tables Tab ............................................................................................... 11 2.3 MATLAB ............................................................................................................. 12 2.4 Database ............................................................................................................ 12

2.4.1 Model ............................................................................................................... 13 2.4.2 IO Metadata ..................................................................................................... 14 2.4.3 Scenario ........................................................................................................... 14 2.4.4 Compatible Pairs.............................................................................................. 15 2.4.5 Output .............................................................................................................. 15 2.4.6 Input ................................................................................................................. 15 2.5 External Files ...................................................................................................... 15 2.6 Technology Stack ............................................................................................... 15 2.7 Implementation Notes and Issues ...................................................................... 16

2.7.1 User Warning ................................................................................................... 16 2.7.2 Versioning ........................................................................................................ 17 2.7.3 MATLAB Interface............................................................................................ 17

3 CONCLUSIONS AND RECOMMENDATIONS ..................................................... 18 3.1 Summary of Work Completed............................................................................. 18 3.2 Recommendations for Future Work and Improvements ..................................... 18

ANNEX A ACRONYMS AND ABBREVIATIONS ............................................. A-1



28 March 2013 – v – 5394-002 Version 02

L I S T O F F I G U R E S

Figure 2-1: System Architecture ...................................................................................... 4 Figure 2-2: Perform Analysis Tab .................................................................................... 5 Figure 2-3: Scenario Tab ................................................................................................. 6 Figure 2-4: Develop Model Tab ....................................................................................... 7 Figure 2-5: Input Tab ....................................................................................................... 8

Figure 2-6: Output Tab .................................................................................................... 9 Figure 2-7: IO Metadata Tab ......................................................................................... 10 Figure 2-8: Compatibility Tab ........................................................................................ 11 Figure 2-9: Raw Tables Tab .......................................................................................... 12 Figure 2-10: Database Entity Relationship Model ......................................................... 13 Figure 2-11: MDMT Model Structure ............................................................................. 14 Figure 2-12: MDMT Scenario Structure ......................................................................... 15



28 March 2013 – vi – 5394-002 Version 02

L I S T O F T A B L E S

Table 2-1: MDMT Implemenation Technologies ............................................................ 16 Table 2-2: Technology Versions .................................................................................... 16 Table 2-3 MDMT File Extensions .................................................................................. 17 Table A-1: Acronyms and Abbreviations ......................................................................A-1



28 March 2013 – vii – 5394-002 Version 02

E X E C U T I V E S U M M A R Y This document represents the final report for a project entitled “Model and Data Management Tool (MDMT) for the Air Force Structure Analysis (ASTRA) Model”. The purpose of this project was to design and implement the desired database and modelling object management tools for the Air Force Structure Analysis software. This report was completed by CAE Inc. under Task #137 for contract #W7714-083663/001/SV to Defence Research and Development Canada (DRDC) Centre for Operational Research and Analysis (CORA).

The purpose of Task #137 was to design and implement a database and modelling object management tool suite for the ASTRA software. The integration of the modelling object tool suite and the database are known as the MDMT. The MDMT manages the input and output data, provides version control for the models, and manages execution.

With guidance from the Technical Authority (TA), the CAE team analysed the problem space and produced a MDMT architecture and design; this was documented in a separate document entitled “Design and Implementation of the Model and Data Management Tool for the Air Force Structure Analysis Model”1.

Upon design approval, the team implemented the MDMT. During implementation, the team liaised closely with the TA to ensure that the intricate functionality required by the design and the implementation decisions made were according to the TA’s expectations.

The MDMT provides a graphical user interface (GUI) which enables the ASTRA models to be managed, stored, and executed. The GUI interfaces with MATLAB for the creation and execution of models, to provide a database for data storage and management, and facilitate the collection of external files (managed via the database) for storage of models, input data, and output data.

The design and implementation of the MDMT supports extensibility to provide additional features and functionality. During MDMT development, CAE identified additional items for future development. The following improvements were recommended:

A command line interface;

An improved compatibility pairs feature set;

An improved mechanism for generating scenario files; and

A database search feature set. 1 Bahramifarid, N. (2012). Design and Implementation of the Model and Data Management Tool for the Air Force Structure Analysis Model. Technical report to DRDC CORA. (Task 137).



28 March 2013 1 5394-002 Version 02

1 INTRODUCTION

This document represents the final report for a project entitled “Model and Data Management Tool (MDMT) for the Air Force Structure Analysis (ASTRA) Model”. The purpose of this project was to design and implement the desired database and modelling object management tools for the Air Force Structure Analysis software. This report was completed by CAE Inc. under Task #137 for contract #W7714-083663/001/SV to Defence Research and Development Canada (DRDC) Centre for Operational Research and Analysis (CORA).

1.1 Background

The Directorate of Air Staff Operational Research (DASOR) created a number of force structure models over the past decade, in the form of various instances of the ASTRA model. Most of these instances were fleet-specific models designed in the Microsoft Access database software with a Visual Basic for Applications front-end. These versions capture much useful information and data concerning the organization and state of the applicable fleet at the time that they were created. The disadvantages of this format are manifold, the primary issues relating to data management, software development methods and its limited scope and lack for future growth.

In an attempt to rectify this situation, DASOR developed a new generic prototype version of ASTRA in 2005-2006, dubbed ASTRA Mark II. It was developed in MATLAB/Simulink for the following reasons:

MATLAB has well-developed data structuring and graphic presentation capabilities;

A simple graphical user interface (GUI) could be created to facilitate data entry;

Simulink provides a visual development environment, allowing most operations performed on the data to be represented as nested graphic objects. This enables the developer to understand the model holistically and to view the model details.; and

Ranges and steps can be entered for all input variables and all possible combinations of the variables can be generated for brute-force processing in a single step.

This approach alleviated some problems experienced with the first version of ASTRA, but made little headway in dealing with the problems of poor maintainability, limited personnel scope and the need for separate models for each platform.

Ideally, ASTRA Mark III will mitigate these deficiencies by becoming a comprehensive Air Force Structure model development tool. An analyst will be able to specify the input



28 March 2013 2 5394-002 Version 02

data and rules; the ASTRA MDMT will enable this by providing the ability to manage the data and model versions.

1.2 Objective

The objective of Task 137 was to a) design and implement the desired database and modelling object management tools for the ASTRA software; b) include a database for the management of input and output data to the ASTRA models; and c) implement a type of version control and execution control for the ASTRA model objects.

1.3 Outline

This document describes the work completed to create the MDMT for the ASTRA model. It provides the MDMT’s technical specifications, database specifications, and suggestions for further improvement. The document consists of the following sections:

Section 1 – Introduction describes the project background objectives.

Section 2 – MDMT System Description provides an overview of the MDMT architecture, design concepts, and implementation.

Section 3 – Conclusion and Recommendations summarizes the work completed and provides recommendations for future work and improvements.

Annex A – Acronyms and Abbreviations lists the acronyms and abbreviations used in this document.

The MDMT User Guide is documented separately2; the user guide describes the operation of MDMT software and contains a list of references for all the software required to run the MDMT software.

2 Guo, J. and Guenther, S. (2013). Design and Implementation of the Model and Data Management Tool for the Air Force Structure Analysis Model – User Guide. Technical report to DRDC CORA. (Task 137).



28 March 2013 3 5394-002 Version 02

2 MDMT SYSTEM DESCRIPTION

This section presents the MDMT architecture, describes its components, and identifies the factors that influenced its design. The implementation of the MDMT is also described, highlighting the technologies employed during implementation. This section also describes issues encountered during the implementation phase of the task.

2.1 System Architecture

The purpose of the MDMT is to manage and track MATLAB files and their interactions. The MATLAB files are grouped into two categories: models and inputs. A MDMT user can combine models and inputs, and place them within a single MATLAB context (or workspace) to be executed by the MDMT tool. The results of that execution are saved as output files. A record of the model and inputs selected together with their resultant output is stored as a scenario.

The content of a model and the input is generally outside the scope of the MDMT and controlled by the user; these files are not directly created or edited within the MDMT. The MDMT expects that a model will contain a MATLAB .mdl file, and an input will contain MATLAB .mat and .m files, with one file named “prepASTRA.m”. However, this is not directly enforced by the MDMT. The only relevant rules are that only one .mdl file exists per run, and that the only .m file run is “prepASTRA.m”. Another option is that the “prepASTRA.m” file can load other files (such as .mat or .m files), but it should not execute the .mdl file as this is done by the MDMT.

A model can have input/output (IO) metadata linked to it. IO metadata describes input and output, and can be used to ensure values are acceptable; for example, if a given input variable is within a set range. IO metadata is stored as eXtensible Markup Language (XML).

Sections 2.4 and 2.5 provide additional detail regarding the content and structure of the database and external files.

Figure 2-1 illustrates the system architecture of the MDMT system. The central component of the system is the MDMT itself, which interfaces with all other components. Each component is described in the following sections. Note that the Database GUI component in Figure 2-1 has been integrated into the MDMT component.



28 March 2013 5 5394-002 Version 02

Figure 2-2: Perform Analysis Tab

2.2.2 Scenario Tab

The Scenario tab enables a user to examine previous executions of models, input and output data, known as scenarios. Within this tab, a user can rename scenarios, add notes, or export scenario data. When a scenario is selected in the Resources pane and the Select button is clicked, the relevant models, inputs, and outputs are loaded in the Perform Analysis tab, Input tab, Develop Model tab, and Output tab.

Figure 2-3 depicts the Scenario tab.



28 March 2013 6 5394-002 Version 02

Figure 2-3: Scenario Tab

2.2.3 Develop Model Tab

The Develop Model tab permits a user to create a new model entry in the database with the Add button (bottom left). The new model will be linked to an empty zip file, to which a model can be appended using the Append button. An alternative method for assigning files to a model is importing a zip file using the Import Button. If removing a file from the selected model is desired, it can be done with the Splice button. The model can be exported as a zip using the Export button. The Name, Version, Notes, and History fields can be altered which will change the model’s information in the database. Finally, a model can be linked to a single existing IO metadata entry using the IO metadata list. Figure 2-4 depicts the Develop Model tab.



28 March 2013 7 5394-002 Version 02

Figure 2-4: Develop Model Tab

2.2.4 Input Tab

The Input tab allows a user to create and modify input data. It essentially provides the same functionality as the Develop Model tab, but rather than working on model data, it functions on input data. Figure 2-5 depicts the Input tab.



28 March 2013 8 5394-002 Version 02

Figure 2-5: Input Tab

2.2.5 Output Tab

The Output tab permits a user to add notes and versioning information to the output data. Figure 2-6 depicts the Output tab.



28 March 2013 9 5394-002 Version 02

Figure 2-6: Output Tab

2.2.6 Input/Output Metadata Tab

The IO Metadata Tab provides a user with a mechanism to describe and validate variables that are passed to a model. Even though IO Metadata is attached to a model, in practice, a user is more concerned with validating the input files to ensure that the input is compatible with a model. IO metadata, variables and corresponding information are stored within an XML file. Figure 2-7 depicts the IO Metadata tab.



28 March 2013 10 5394-002 Version 02

Figure 2-7: IO Metadata Tab

2.2.7 Compatibility Tab

The Compatibility tab provides a user with a mechanism to annotate which inputs are compatible with a model, or which models are compatible with an input. This is accomplished by selecting an item from one column, and then selecting or deselecting one or more items from the subsequent column.

Validation of the input’s compatibility with the model occurs at run time.

Figure 2-8 depicts the Compatibility tab.



28 March 2013 11 5394-002 Version 02

Figure 2-8: Compatibility Tab

2.2.8 Raw Tables Tab

The Raw Tables tab provides a mechanism for a user to view the contents of the MDMT database, the database tables. Selecting one of the six sub-tabs displays the contents of the selected database table. The tables can be modified directly by clicking in the data fields and overtyping the contents. Figure 2-9 depicts the Raw Tables tab.

WARNING: CHANGES TO THE DATABASE TABLES ARE EFFECTIVE IMMEDIATELY UPON ENTRY. THERE IS NO “UNDO” FUNCTIONALITY. THE MDMT SHOULD EXERCISE CAUTION WHEN MAKING CHANGES USING THE RAW TABLES TAB.



28 March 2013 12 5394-002 Version 02

Figure 2-9: Raw Tables Tab

2.3 MATLAB

MATLAB is the external software which is used for model creation, modification, and execution. Simulink is a block diagram environment for multi-domain simulation and model-based design. It supports system-level design, simulation, automatic code generation, and continuous test and verification of embedded systems. It is integrated with MATLAB, enabling users to incorporate MATLAB algorithms into models and to export simulation results to MATLAB for further analysis.

The MDMT was designed and developed to support MATLAB version R2012b and Simulink 8.0.

2.4 Database

The database component contains all system data or links to the external files necessary for the MDMT to function. The database also maintains all data association, in addition to providing versioning.



28 March 2013 13 5394-002 Version 02

Data is structured into six major elements, each held in a separate database table. Figure 2-10 illustrates the major data elements and their interrelationships.

Figure 2-10: Database Entity Relationship Model

2.4.1 Model

The Model data element contains all the model relevant information and links, such as Model Name, History, Version, and the link to the model file.

A model, in the context of the MDMT, consists of a Simulink file (*.mdl), a primary MATLAB script file (*.m), and a group of MATLAB data files (*.mat). The primary MATLAB script file can also be associated with other MATLAB script files or data files. The model structure is illustrated in Figure 2-11.

The primary MATLAB script file in a model may be a root file of a tree structure comprising a collection of sub-script files and their descendent-script files. Each MATLAB script file (*.m) in a model may also be linked to a group of input data template files (*.mat).

The sub-model (*.mdl) files in a model may also associate with their own MATLAB script files, input templates, and sub-models. All the linked files in a model may be under a single folder or multiple folders under a specified project folder.



28 March 2013 14 5394-002 Version 02

Figure 2-11: MDMT Model Structure

2.4.2 IO Metadata

The IO metadata data element contains information used to describe and validate input and output variables used by models.

2.4.3 Scenario

The Scenario data element contains a record of the model and associated inputs and outputs. A scenario, in the context of the MDMT, refers to an instance of a model specified by:

1. A Simulink model file (*.mdl);

2. A primary MATLAB script file (*.m);

3. A set of real input data; and

4. The output from model execution using the specified input data.

This structure is illustrated in Figure 2-12.



28 March 2013 15 5394-002 Version 02

Figure 2-12: MDMT Scenario Structure

2.4.4 Compatible Pairs

The Compatible Pairs data element contains data that correlates models with valid inputs.

2.4.5 Output

The Output data element contains links to the output data files created by an execution instance of a model and input set.

2.4.6 Input

The Input data element contains links to the input data files required by a model for execution. Input records will contain .mat and .m files.

2.5 External Files

A design decision was made to not store all data locally to the database to ensure the database data model maintains its flexibility for future extensibility. The database is used only to structure the data; most of the raw data is stored in external files using standard formats. This makes the raw data easily accessible to external tools such as Microsoft Excel or other databases for further custom analysis and visualization.

2.6 Technology Stack

Table 2-1 identifies the technologies used in the implementation of the MDMT.



28 March 2013 16 5394-002 Version 02

Table 2-1: MDMT Implemenation Technologies

MDMT Component Technology Notes

MDMT Java Swing Matlabcontrol

Primary programming language Swing is a Java GUI development toolkit Open source MATLAB control library for Java

Database GUI Java Swing

Primary programming language Swing is a Java GUI development toolkit.

Database MySQL Server MySQL Workbench

Database development and implementation Database schema (model and entity relationship model)

External Zip Files Java Creation and manipulation External XML files

Java Architecture for XML Binding (JAXB)

Creation and manipulation

Table 2-2 details the technology versions used in the implementation of the MDMT.

Table 2-2: Technology Versions

Technology Version Notes Java 1.6 Swing JDK 1.6 matlabcontrol 4.0.0 JAXB n/a Included with Java 1.6 MATLAB R2012b Simulink 8.0 MySQL Server 5.5

2.7 Implementation Notes and Issues

2.7.1 User Warning

WARNING: USERS MUST EXERCISE CAUTION WHEN EDITING DATA FIELDS IN THE SYSTEM’S FUNCTION TABS. THE CHANGES ARE COMMITTED TO THE DATABASE INSTANTANEOUSLY. THERE IS NO UNDO BUTTON.



28 March 2013 17 5394-002 Version 02

2.7.2 Versioning

The MDMT suite provides versioning. The aim of versioning is twofold: a) to provide a mechanism to ensure that previous executions of models can be replicated; and b) to provide a mechanism to track new variations of existing entities (inputs, IO metadata, models, and output). Versioning is handled by zipping files and obscuring them from the user (these files will be zip files, but the MDMT will change the extension as identified in Table 2-3). This will allow the MDMT to treat versions atomically. Different versions of files are specified in the database.

Table 2-3 MDMT File Extensions

MDMT Extension File Type

.mmo MDMT model

.min MDMT input

.mou MDMT output

2.7.3 MATLAB Interface

The MDMT suite was developed for use with MATLAB 2012b and Simulink 8.0. The MDMT has not been tested for other versions, and may consequently be incompatible.



28 March 2013 18 5394-002 Version 02

3 CONCLUSIONS AND RECOMMENDATIONS

This section provides a summary of the work completed and provides recommendations for future work and improvements.

3.1 Summary of Work Completed

CAE analysed the problem space and produced a MDMT architecture and design. This is documented separately in a report entitled “Design and Implementation Model and Data Management Tool for the Air Force Structure Analysis Model”.3

Upon design approval, the team implemented the MDMT. During implementation, the team liaised closely with the TA to ensure that the intricate functionality required by the design and the implementation decisions made were according to the TA’s expectations.

The MDMT provides a graphical user interface (GUI) which enables the ASTRA models to be managed, stored, and executed. The GUI interfaces with MATLAB for the creation and execution of models, to provide a database for data storage and management, and facilitate the collection of external files (managed via the database) for storage of models, input data, and output data.

3.2 Recommendations for Future Work and Improvements

The design and implementation of the MDMT supports extensibility to provide additional features and functionality. During MDMT development, CAE identified additional items for future development. The following improvements were recommended:

Command Line Interface. As implemented, the MDMT provides a user with a GUI to control the execution of ASTRA models. The modular design of the MDMT suite lends itself to have a non-graphical, command line interface. It would be beneficial to develop a command line interface for the MDMT to enable some functionality of the present version, but without the GUI. The command line interface would provide a mechanism for batch processing of models that could enable chain processing; for example the output of an ASTRA model run could be used as an input for a different model.

Compatibility Pairs Implementation Improvements. Presently, the implementation of the compatibility pairs functionality deletes and creates a new pair every time the user interacts with the user interface. This may result in a large number of identification keys being created in the database over a large timeframe. While the delivered implementation is fully functional, and should not encounter issues in the

3 Bahramifarid, Nima (2012). Design and Implementation Model and Data Management Tool for the Air Force Structure Analysis Model. Technical Report to DRDC CORA (Task 137).



28 March 2013 19 5394-002 Version 02

near- to mid-term, CAE recommends modifying this piece of functionality to ensure no issues arise with long-term use of the MDMT.

Generation of Scenario Files. Presently, scenario files are generated on request. An improved solution would be to generate scenario files on execution as this would improve the robustness of the MDMT. A potential issue is if a model or input is changed prior to the scenario file generation, the scenario would not accurately represent the model and input data as run.

Database Searching. The present design of the MDMT database did not provide a database search. A search capability could be added to the MDMT suite to assist users to search for specific content within models, input, output, or scenarios.



28 March 2013 A-1 5394-002 Version 02

APPENDIX A ACRONYMS AND ABBREVIATIONS

The following table defines the acronyms and abbreviations used in this report.

Table A-1: Acronyms and Abbreviations

Acronym or

Abbreviation Definition

ASTRA Air Force Structure Analysis

CORA Centre for Operational Research and Analysis DASOR Directorate of Air Staff Operational Research DB Database DRDC Defence Research and Development Canada GUI Graphical User Interface IO Input/Output JAXB Java Architecture for XML Binding JDK Java Development Kit MDMT Model and Data Management Tool SO Standing Offer

TA Technical Authority XML Extensible Markup Language

This page intentionally left blank.

DOCUMENT CONTROL DATA (Security markings for the title, abstract and indexing annotation must be entered when the document is Classified or Designated)

1. ORIGINATOR (The name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g. Centre sponsoring a contractor's report, or tasking agency, are entered in section 8.) CAE Integrated Enterprise Solutions - Canada 1135 Innovation Drive Ottawa, ON, K2K 3G7 Canada Telephone: 613-247-0342 Fax: 613-271-0963

2a. SECURITY MARKING (Overall security marking of the document including special supplemental markings if applicable.)

UNCLASSIFIED

2b. CONTROLLED GOODS

(NON-CONTROLLED GOODS) DMC A REVIEW: GCEC APRIL 2011

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.) Model and Data Management Tool for the Air Force Structure Analysis Model - Final Report

4. AUTHORS (last name, followed by initials – ranks, titles, etc. not to be used) Hunter, D.G.

5. DATE OF PUBLICATION (Month and year of publication of document.) November 2013

6a. NO. OF PAGES (Total containing information, including Annexes, Appendices, etc.)

34

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

0 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.) Contract Report

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development – include address.) Defence Research and Development Canada – CORA 101 Colonel By Drive Ottawa, Ontario K1A 0K2

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.)

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

W7714-083663

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.) 5394-002 version 02

10b. OTHER DOCUMENT NO(s). (Any other numbers which may be assigned this document either by the originator or by the sponsor.) DRDC CORA CR 2013-197

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by security classification.)

Unlimited

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

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), (R), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual.)

This report provides the background to the development and a detailed description of the Model and Data Management Tool (MDMT). MDMT was created to provide a user-friendly wrapper for various versions of the Air Force Structure Analysis (ASTRA) model. Its primary function is to keep track of the model versions along with all input data, output data and associated meta-data for the models and for each execution of the model.

---------------------------------------------------------------------------------------------------------------

Le présent rapport décrit le contexte de développement de l’outil MDMT (Model and Data Management Tool) et donne une description détaillée de l’outil. Nous avons créé l’outil MDMT (Model and Data Management Tool) afin d’offrir une enveloppe conviviale pour diverses versions du modèle ASTRA (Air Force Structure Analysis). La fonction principale de l’outil est de faire le suivi des versions du modèle ainsi que des données d’entrée et de sortie et des métadonnées connexes associées aux modèles et à chaque exécution du modèle.

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.) Air Force Structure Analysis; ASTRA; MDMT; Model and Data Management Tool

model and data management tool for the air force structure analysis model - final...

Documents