Attachment 6 RMTK Mobile Assessment_9-29-17_Final.docx

Marine Corps Training and Education Command Range and Training Area Management Division (RTAM) Assessment of the Range Managers Tool Kit (RMTK) September 2017

Prepared for: Naval Facilities Engineering Command, Southwest

1220 Pacific Hwy San Diego, California 92132-5181

Contract # N62742-14-D-1863 (FZNH)

Assessment of the Range Managers Tool Kit (RMTK) September 2017 iv Table of Contents

Assessment of the Range Managers Tool Kit (RMTK)

TABLE OF CONTENTS

LIST OF TABLES

Table B-1 ESRI Pricing as of 2-16-17…………………………………………………………………………………………………….B-1 Table B-2 Boundless-CarahSoft pricing as of 2-16-17…………………………………………………………………………..B-2

LIST OF FIGURES

GLOSSARY AND ACRONYMS

1-1

Executive Summary References

(a) TECOM Safety of Use Memorandum 6-09

(b) MCO P3570.1C Range Safety

(c) MCO 3550.9 Marine Corps Ground Range Certification and Recertification Program

(d) MCO P3550.10 w/Ch 1 Policies and Procedures for Training Area Management

(e) MCO 3550.12 Operational Range Clearance Program Purpose The Range and Training Area Management Division (RTAM) Assessment of the Range Managers Toolkit (RMTK) provides RTAM with an assessment of current range safety tools, proposed courses of actions to meet future platform capability requirements, and an overview of representative tools that support RTAM’s range management and safety responsibilities.

The endpoint of the study will support RTAM’s long-term mobile RMTK programmatic implementation methodology with information on the relative operational and maintenance fees, in order to educate decision makers on the best strategy for optimizing subsequent sustainment costs and capability. The information will allow improved distribution of resources across the RMTK components by meeting long-term programmatic objectives in the most economical and sustainable manner.

Change frequently happens in the mobile computing environment for hardware and software, communication networks, operating systems, and development methodologies. This report will reference required capabilities, not specific solutions, so that programmatic decisions can be made for purchasing the most capable hardware and software to support mobile RMTK at the time the particular acquisition action is initiated.

Situation The Marine Corps Range Safety Program ensures safety while enhancing combat effectiveness and readiness. The RMTK was developed for implementation of this program by supporting range operations with practical geospatial data assessment and decision support tools. Training and Education Command (TECOM) Safety of Use Memorandum 6-09 (Reference (a)) provides an overview of RMTK implementation objectives. The Range Managers Toolkit is one of the tools that implements this program. It is a framework of interrelated tools that assist the Range Manager and Range Control staff and the operating forces in operating a safer and more efficient range complex and training exercise. The RMTK Working Group has identified nine main functional areas (or tools) of requirements: Surface Danger Zones (SDZ), laser hazard danger zones, on range ammunition storage potential explosion radii, range development and planning, range design, range related noise, Explosive Training Range danger zones (ETR), range clearance, range management data visualization (3D), and Weapon Danger Zones (WDZ). There are several requirements that are universal to these functional areas, while some are related to only one tool.

Essential functions of the RMTK which actively use geospatial information data and analysis tools include Surface Danger Zones (SDZ), Weapons Danger Zones (WDZ), and Explosive Training Range Danger Zones (ETRs). The RMTK was designed and fielded for desktop use and secure network connectivity. The platform utilizes Environmental Systems Research Institute (ESRI) architecture to provide geospatial database and analysis capabilities. Use of ESRI tools either requires a desktop application or access through Navy and Marine Corps Internet CITRIX based services. ESRI’s current desktop architecture is projected to change in the next five years significantly.

RTAM required this technical and programmatic assessment to provide information and recommendations for a mobile architecture supporting RMTK geospatial data capabilities for SDZ, WDZ, ETR tools and provide efficient and sustainable solutions for the future. RTAM is seeking a programmatic approach that builds as many platform “agnostic” components as possible which can then be reused across different platforms. The use of flexible, agnostic programming language toolkits will further support RMTK mobile applications and the ability to adapt to upcoming ESRI licensing and software changes. An additional use for this assessment is to help lead the acquisition process and derive specifications for elements of the mobile RMTK architecture so that coordination with USMC information system enterprise stakeholders can happen early in the acquisition process. A proactive approach to shape approved system and software lists, before vendor quotes are sought, will improve RTAM’s the ability to purchase the most current capability in the mobile computing market as they acquire and refresh the mobile RMTK architecture.

The projected chain of command/decision-making for follow on programmatic efforts for mobile RMTK begins at TECOM/MCCDC and ends at HQMC. NAVFAC (and the contractor) is involved in this effort to provide subject matter expertise based assessment products and recommendations developed herein to support RTAM programmatic requirements. The deliverables to be provided under this task are in support of the assessment and representative planning tools described herein.

Current Workflow The current workflows for managing the range safety planning and execution process is centralized using standalone desktop clients and paper products. The RMTK is utilized by a varied but limited set of range managers, inspectors, and GIS professionals to provide products in support of range planning and use. Any changes to planned training operations or range regulations in the field must be brought back to the central range facility with the desktop client to have pertinent information for the intended change entered into RMTK so the appropriate range management individuals can approve or deny the requests. This process can take several hours to days which limits opportunities for improved training, causes the operators to wait for a decision and diminishes the efficiency of the range assets and agility of the range management organization.

RMTK Outputs The RMTK provides output for the nine main functional areas or range safety requirements. It is a planning tool to be used by Range Safety Officers (RSO) and Officers in Charge (OIC) at each training facility, and by unit commanders and their staffs in planning training exercises.

Range Regulations The USMC risk management process results in range standard operating procedures that are implemented through range regulations. The output from the RMTK tools supports the development and maintenance of the range regulations, which are currently created and distributed via hard copy products that take significant effort to maintain.

RMTK Data Collection and Analysis The assessment analyzed the current capabilities, programming architecture, and future requirements for the RMTK tools for SDZ, WDZ, and ETR. A majority of the data collected regarding tool functionality resulted from subject matter expert interviews for required updates and recommendations for improvements to the RMTK Range Safety Tools. The study assessed four principal components for each of the SDZ, WDZ, and ETR tools within the RMTK:

The User Interface Core Geometry Generation Supporting Functions and Frameworks Input and Output Database This assessment presents the complexity of the identified solutions along with their potential implementation challenges at the macro level for a mobile RMTK architecture Decision Process The process of determining the best COA for developing a mobile RMTK solution was deliberative and based on some initial assumptions that the workflow for RMTK could be improved and less costly.

Decision Criteria The decision criteria for the COA determination were established as:

Open source versus dependency on ESRI product or proprietary data standards, over next five years.

Level to which functional components of desktop SDZ, WDZ, and ETR can be met in mobile environment.

Ability to scale from current user base (including any users of free, open source GIS desktop tools) to anticipated future mobile RMTK.

Map background (raster image) with or w/o local technical support.

NMCI network compliance.

NGEN/MCEN network compliance.

Ability of the mobile capability to transmit information across unclassified wireless distributed networks.

Cost of proposed solutions – initial and long term.

Selected COA The selected COA is based on a ESRI runtime API framework initially supporting an Android OS with future capability on iOS and Windows. The platform is currently supported by ESRI and is the intended direction for the industry in GIS. The ESRI runtime API also allows for easier integration with other ESRI products (portal, desktop, and server). A core rewrite for SDZ and ETR would be the same for all COAs. Front end presentation layer will have to be written with an equivalent level of effort across all COAs. The creation of middle framework is required in all COAs.

Representative RMTK Tools As with any mobile option, various components will be rewritten and refactored including the presentation layer to the runtime API using Xamarin. A middle framework will be created that controls various selection criteria and a general library commands. This will then be compiled into versions compatible with desktop, web, and mobile. A set of interfaces for map interaction, data import, data export, and other miscellaneous functions will be created specific to the mobile platform (i.e. Map data import, data export, etc.)

ESRI free/lite version of runtime supports all the functionality required except for one requirement, which is the use of raster images for map background without processing them to tiled map packages. This will require desktop processing of map data and reprocessing to account for map data changes.

For background data import, the device will need to be able to connect and load the required data from another device. Created and exported data will need to be copy, exported, or downloaded to another device as needed.

The proof-of-concept approach to this initial tool development focused on the tools core functionality to make the application work, and learn what might need to be addressed in future mobile RMTK development. The specific features and functions of the user interface were a lower priority.

0. SDZ

For each item in SDZ a detailed “Post-Development” summary was added under each in the respective section of the report. In general, SDZ could contain more weapons and contain the most important input methods required. The sample on SDZ could contain more as we went due to the simplicity of the architecture and some for thought on design.

WDZ

For each item in WDZ a detailed “Post-Development” summary was added under each in the respective section of the report. In general, WDZ was more problematic than initially anticipated. The code based of the core being C++ is platform agnostic. However, some of the code in the core was Windows specific, along with resource files needing to run being in a Windows specific format. After this was discovered considerable time was spent porting and rewriting these components to be platform agnostic. These components appear to work like the current desktop with a couple exceptions that need to be investigated formally by those responsible for WDZ configuration. These updated components are now available for use in desktop also pending the approval of those responsible for WDZ desktop configuration.

For WDZ we were able to complete workflows for bombs that do not allow an offset, strafe, unguided rockets, and door gunnery. Offset capable weapons, guided rockets, missiles, and legacy WDZs were not included in the workflows.

ETR

For each item in ETR a detailed “Post-Development” summary was added under each in the respective section of the report. In general, ETR contains the Bare Charge workflow and the respective munitions for that workflow along with the underlying supporting functionality of administration and management.

Estimate to Complete the Sample Application to a Final Product and Sustain An analysis of the difference in functionality from what the government desired in the interviews and what was achieved in the sample was analyzed. Based on this information to complete all three to contain all the government indicated is around $105,000 of development time.

Also based on industry version changes, IA compliance, and rate of change of the RMTK tools the annual sustainment of all three tools is around $64,000 a year.

For both numbers about half of each is just supporting the complexities inherent to the requirements in WDZ and keeping up with the dynamics of that individual tool.

3-8

Overview and Description References

(a) Range Managers Toolkit Functional Description Document 5.0, 25 Feb, 2014

(b) Range Safety, Army Regulation 385-63 / MCO 3570.1C, 30 Jan, 2012

(c) Range Safety, Army Pamphlet 385-63, 10 Apr, 2003

(d) Ammunition and Explosives Ashore Safety Regulations for Handling, Storing, Production, Renovation, and Shipping (NAVSEA OP5 Volume 1, Rev 7), (NOTAL) Purpose RMTK exists to automate range policy. GIS based architecture supports the spatial nature of range control operations and aids in modernizing ranges, operating the range complex, and managing training lands to efficiently provide safe and effective training opportunities for all Services using RMTK. The current environment on ranges requires excellence information systems management to accommodate the military’s new operational environment, encroachment realities, and new weapon systems. Understanding the location and size of training related danger zones (i.e. surface danger zones, weapon danger zones, explosive danger zones, laser surface danger zones, and noise areas) in the context of other installation features is crucial to the efficient operation and utilization of DoD range assets. RMTK aims to allow Range Control staff to interact with this information in a standard map format. RMTK is only a software package. It does not relieve range community users from the responsibility of understanding the functions that RMTK automates.

The current architecture and workflow of RMTK and its tools as described in the following sections is the starting point for establishing user requirements and to show the return on investment for migrating the essential functions of RMTK to a mobile environment that will support RTAM’s long term mobile RMTK programmatic implementation.

Introduction Below is a brief description of each tool derived from the RMKT FDD, reference (a) based on requirements in references (b) through (d). It is followed by a basic understanding of the standard workflows and user interaction.

SDZ

Surface danger zones (SDZs) define the ground and airspace designated within the training complex (to include associated safety areas) for vertical and lateral containment of projectiles, fragments, debris, and components resulting from the firing, launching, or detonation of weapon systems to include explosives and demolitions. The SDZ Tool generates surface danger zones by parameters defined in reference (b) and (c). The size and shape of an SDZ is dependent on particular user input such as the location of firing points and targets, weapon system, ammunition, impact media, and terrain. The capability to develop SDZs on the map serves as the basis for other RMTK uses, such as mission planning, range deviations, range modernization/planning, and range certification.

User Interface / Workflow Because of the size and diversity of the tools the following UI and workflow components common to all tools will take priority in COA analysis. Other functions will be considered but secondary to the common components. The general workflows are as follows:

Danger Zone Generation Wizard: The wizard workflow is designed to give the user the quickest and easiest path to generate the danger zone with all required information. The wizard workflow consists of “what are you making”, “how are you making it”, “where are you making it”, and “is it right and what do you want to name it?”. The workflow allows the users a consistent process to minimize training and put in safety checks. The result of the workflow is a saved danger zone.

Danger Zone Management: After danger zones are created, the users need basic functions to view, edit, delete, and rename danger zones. This is accomplished through the manager interface. This interface is usually a basic grid containing the danger zones and information with the ability to select the function the user wishes to perform against the danger zone. The manager interface also includes the export functionality for sharing of danger zones or use on other systems.

Administrative and Setup Functionality: Each tool is dependent on a basic setup that is done through the administration tool. While these functions are required, for this effort much of this can be automated to the specific installation reducing user error or providing the user with intelligent messages when they try to do something outside of a predetermined setup. Once a COA is chosen a plan for these functions will be determined.

Data and Map management: These functions are intrinsic to the desktop ArcMap program that is currently used for RMTK and so are not a function within the desktop tools. However, in the mobile environment, the application will likely need to be self-contained. This will require functionality for loading, displaying, and referencing maps. The ability of the chosen framework to import, store, and display data is a decision factor.

Core Geometry Generation The core of the SDZ tool is the geometry generation that occurs based on user inputs. This core is conceptually and architecturally isolated and treated as a “black box” from the rest of the tool. The design pattern is such that the core can be tested for accuracy, bugs, and efficiency apart from the rest of the tool. Since the geometries are the basis for the decision maker’s visual analysis, a greater emphasis is placed on the geometries themselves. Likewise, only one set of geometry generation routines exist across all platforms and for testing and safety purposes need to stay in this architecture. The SDZ core is currently written in VB.NET using ArcOBjects. Regardless of the COA for the interface and supporting functions the core needs to be a universal and generic language and architecture that can be used or compiled across all RMTK support platforms.

Supporting Functions and Frameworks Each tool requires various functions and common frameworks to work. Some standard functions are display, edit, delete, and export. Currently, many of these functions are embedded in various parts of the tools as part of their development and were not part of a common design strategy. Currently, these and other functions, workflows, and design are being standardized in RMTK. The evaluation of COAs for this assessment and representative will consider the refactoring of these functions to their library and the feasibility and performance. Preference would be towards having these broken out of the user’s interface (presentation layer) and into their middle tier of libraries.

Input and Output Database The current input and output databases for RMTK are based either on MS Access or ESRI File Geodatabase. For all RMTK tools, the input database is static and is only required for lookup tables and should provide for great flexibility between formats (XML, txt, NoSql, etc.). The output database format, and how the output will be will be consumed in the export for other tools, will need to be defined as part of the COA.

WDZ

Weapon danger zones (WDZs) define the ground and airspace for lateral and vertical containment of projectiles, fragments, debris, and components resulting from the firing, launching, and/or detonation of aviation delivered ordnance. The RMTK WDZ Tool creates WDZs for aerial platforms including fixed and rotary wing, and remotely piloted delivering air to ground weapons. The size and shape of a WDZ is dependent on a variety of aircraft delivery parameters to include airspeed, altitude, delivery angle, and run in heading. Range planners from all services must know the locations of WDZs to execute single service and joint training exercises safely.

User Interface / Workflow WDZ interfaces and workflows are the same as SDZ at the component level. Two additional interfaces for WDZ are required and are unique to WDZ.

Target Generation: The WDZ tool requires users to manage targets explicitly and track them since WDZ and air to ground range management is target centric. A basic interface is used to name, defines, and locate targets for use in the generation wizard.

Target Management: Since WDZ requires explicit creation and use of targets it also requires precise management of targets. The target manager will require the primary interface of view, edit, delete, and exporting of targets. This should be done like danger zone management to reduce training time for the users.

Core Geometry Generation For this analysis, the WDZ core is not being considered. It is currently a C++ library that generates WDZs. The size and scope of these libraries would require a major distinct effort to rewrite. Like SDZ this is also where testing and checks for safety are critical. At this time, it is believed that the WDZ core is compatible with all COAs.

Essential Functions and Frameworks The discussion of essential frameworks is the same as in paragraph 2.4.3 for SDZ.

Input and Output Database The discussion of input and output databases is the same as in paragraph 2.4.4 for SDZ.

ETR

RMTK will support breaching operations and explosives training by generating associated explosive danger zones. Definitions and parameters for the explosive danger areas are available in reference (b) and (c). General DoD guidance for this application can be found in reference (d).

User Interface / Workflow ETR does not require any additional interfaces or workflows than SDZ. With the exception of the generation wizard inputs, the SDZ and ETR interfaces should not very much.

Core Geometry Generation ETR core geometry generation is currently written in C# code and uses ArcObjects. Like SDZ it takes user lookup parameters and calculates and draws the appropriate danger zone. Unlike SDZ, the relatively small ETR core only contains four geometry types. However, like SDZ it will need to be compatible across platforms to ensure that each produces the same result and decrease testing time. Rewriting this core to a more platform agnostic library is estimated to be an easy task.

Essential Functions and Frameworks The discussion of essential frameworks is the same as in paragraph 2.4.3 for SDZ.

Input and Output Database The discussion of essential frameworks is the same as in paragraph 2.4.4 for SDZ.

Users and requirements References

(a) Cybersecurity, DoDI 8500.01, 14 Mar, 2014 Workflow Various components would be rewritten and refactored to support this effort. The order of tasking would be the following:

Complete a core rewrite of SDZ and ETR to include no ArcObject in the core generator and make it compile against the desktop, web, and mobile version. WDZ core rewrite is out of scope for these efforts and is not required for this COA.

Refactor and rewrite the presentation layer to the runtime API using Xamarin.

Create a middle framework that controls various selection criteria and a general library commands. This will then be compiled into versions compatible with desktop, web, and mobile.

A set of interfaces for map interaction, data import, data export, and other miscellaneous functions will be created specific to the mobile platform (i.e. Map data import, data export, move/rotate, etc.)

ESRI free/lite version of runtime supports all the functionality required except for one requirement, which is the use of raster images for map background without processing them to tiled map packages. For this reason, it would be cost beneficial to create two versions of the tool. One that supports all functionality found in ESRI lite and a second standard version with all functionality, which will be limited to those that need the single piece of functionality.

This approach will require preprocessing of some background data in ArcGIS. The data will have to be exported to a tiled map package and imported into the mobile application for raster images to be seen in the background of the lite version. These will then need to be updated as map data changes.

Because some range safety and management personnel work across multiple ranges, there will be a requirement to load multiple range databases to support this work.

Look and feel:

The application will attempt to follow standard industry UI while leveraging design of desktop RMTK as reference.

The application will attempt to follow standard industry UI and workflow design where possible. Some examples are Google maps application, ESRI standard map application, and other commonly used mapping applications.

Where wizards and workflows are designed the look and feel of the desktop will be utilized as a reference. Nevertheless, being a different and more modern information system, environment things like sliding windows, expandable panels, and modern mobile design will be used. The goal being that a Marine that has a basic understanding can figure it out with minimal help.

The look and feel should be similar across COAs 1 through 3.

Permissions, signature:

The application will use the current device user information with the assumption that an authorized user of the device is authorized to use the application. It will use OS level authentication and permission.

The signature (“Made By”) will be name of the user that is logged in.

Mobile Workflow Efficiencies Range Inspector Support Mobile RMTK would alleviate many of the manual processes currently associated with initial field range assessments and would substantially reduce time associated with range control clearing a range. The time savings would be multiplied by the number of operators waiting for approval prior to conducting training. Delays for approval of changes, based on current travel times from the training area to range control for coordination can take multiple hours. Future wireless connectivity solutions in the mobile architecture would greatly enhance this workflow efficiency.

Electronic Access and Maintenance of Range Regulations In addition to the mobile implementation of RMTK tools, there are enormous efficiencies that can be gained by providing mobile access to range regulations and other references required by the range safety inspectors that routinely spend their full day in the field. On average the inspectors currently carry 10 to 15 large binders with paper references for their field work. On a weekly basis there are up to fifty changes that need to be incorporated in each of the inspector’s set of regulations by manually changing the pages in them.

The process of maintaining the currency or the numerous range regulations and references could be automated with the use of a mobile platform. By updating single digital versions of the documents and sharing them with the users there would be immense labor and printing cost savings in addition to reducing the update error and latency factors. A useful and validated estimate of these cost savings was outside the scope of this assessment, but would most certainly provide additional return on investment in the mobile architecture supporting RMTK tools.

Range Incident Reporting Access to supported mobile devices in the field would significantly improve the ability to collect and report accurate location, angles, distances, and fire locations with photographic information required for incident reports in near real-time. The increased efficiencies in this process would reduce the time required to validate this information and provide it the chain-of-command for their information and use in any required outreach other stakeholder’s communications with the public. Additionally, an automated workflow would allow integration with other response data centers to minimize response time to range events.

Map Distribution, Environmental Compliance, and Situational Awareness A mobile platform would provide the opportunity to present current and accurate reference imagery, map backgrounds, custom GeoPDFs, military installation maps (MIM) and maps of range environmental operations, digital elevation models (DEM), aviation hazards, and seasonal environmental maps. The output from RMTK tools could be overlaid to improve the situational awareness in the field greatly and to visually show the interface between operations, the installation, and environmentally sensitive range areas.

Hardware The hardware required for the mobile RMTK solution should support accepted standards for commercial IT systems used in a field work setting in addition to being compatible with MCEN / NGEN and NMCI. The selected platform should be ruggedized for impact, water resistance, and ability to operate in temperature extremes.

The location services maybe supported by native GPS receivers and is always preferred for simplicity. An advantage for GPS use is that receivers are available in almost all modern mobile devices. However, the accuracy of GPS can vary and is disturbed by obstructions causing loss of GPS satellite line-of-sight.

Some professional-grade GPS receivers are very accurate (+/- 1cm), whereas the accuracy of basic consumer-grade mobile devices’ GPS is usually reported to be in the range of a few meters. Some external receivers such as the Garmin GLO, Ublox NEO-7P, or Bad Elf GPS for Dock Connector have improved specifications and improved reliability over native device receivers.

Interface Requirements Background data import to the device will need to be able to connect and load the needed data from another device. Created and exported data will need to be copied, exported, or downloaded to another device as needed. Internal to the device the installer will have to give permissions to access things such as; location, application history, file system, etc. The final list will be determined when compiled for install.

Communications Interfaces The communication interfaces for a mobile device that will support mobile RMTK are not greater than any other device in a mobile architecture deployed to the field. If possible, provide for devices that supports SSL/TLS security and that has support for wireless VPN networking.

Inputs Data entry can be supported by a virtual keyboard / touch screen as well as Bluetooth connectivity to a larger physical key board or stylus. Addition functionality would include a microphone for recording notes and observations, and a camera for photographic data.

USB port access would need to account for any MCEN/NEGEN and NMCI information assurance restrictions Output The greatest advantages of a mobile RMTK architecture would be supported by RMTK outputs via established standard wireless communication networks and Web API (web services).

Other options based on approved devices at the time of acquisition would be:

USB port access would need to account for any MCEN/NEGEN and NMCI restrictions Bluetooth (Special Interest Group (SIG) standard currently 5 as of June 2016) Electronic (solid-state) non-volatile computer storage medium such as mini and micro Secure Digital (SD) cards.

Cybersecurity / Operational Requirements Reference (a) directs the use of the term Cybersecurity in place of information assurance. Cybersecurity is defined as, “The prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation.

Access and permissions The implementation of a mobile RMTK architecture will not change the access and permission standards of the current RMTK implementation. Although, it may offer some efficiencies in how the current RMTK access and permissions are implemented. RMTK will continue to inherit the access and permission configurations of the host device, computer, or server and will comply with the IA standards imposed on the device.

Security and Privacy The security and privacy protocols need to be commensurate with an unclassified information architecture and account for physical security through policy that assigns responsibility to the individual using the device. RTAM would manage distribution and sustainment of mobile assets to ranges. Policy and procedures should include:

Password access and data encryption Markings on devices that state, UNCLASSIFIED, For Official Use Only.

Backup and recovery plans (i.e., 24-hour backup). Regularly review and discard data on your device that you will not be actively using for current work.

Ability to include the following caution on outputs (printouts, data exports, displays) “FOR OFFICIAL USE ONLY: MAY NOT BE RELEASABLE UNDER FOIA.”

Audit and Validation Processes Audit and validation processes in a mobile architecture would not change lines of responsibility or chain of custody. The processes would only be improved by access to faster higher quality data.

Conventions/Standards RMTK tools are required to follow the corresponding Security Technical Implementation Guides (STIG) for application development published by the Defense Information System Agency. Additionally, Open Web Application Security Project updates are reviewed for periodically for standards that may have not yet been published in the most recent STIG.

For coding RMTK follows when possible the current published Microsoft MVC pattern and recommendations for the industry.

evaluation methodology

REFERENCES

(a) DoD IT Business Case Analysis Template, 22 October 2014

0. Introduction The evaluation methodology used for this report was established to determine the best COA to support the future programmatic decisions required for implementation of a mobile RMTK solution and guide the following development of representative RMTK range safety tools: SDZs, WDZs, and ETRs. The content and information in the assessment will not provide direct guidance for the implementation for the preferred COA and generally follow the applicable aspects of reference (a).

Assumptions The changes in the ESRI products and licensing schemes may not be the most cost-effective approach for delivery of RMTK capability. The use of a mobile capability will support improved workflow, accessibility, and evolve processes currently used in the field with reduced cost and dependency on ESRI products.

Constraints The use of the mobile application needs to be simple, yet not diminish the accuracy and reliability sufficient to support range safety requirements and policy.

Evaluation Methodology description As part of this assessment and COA development, the user interface was extensively discussed with Government representatives to ensure the COAs will provide a familiar and user focused interface that will work each tool’s implementation requirements. The redesign will minimize the specific tool’s interface to just what the user needs to see, and all functions (supporting or geometry) are clearly separated out.

Assessment Decision Criteria for Mobile Implementation of RMTK The following decision criteria were established at the start of the assessment to eliminate procedural biases and to structure the data collection to inform these criteria properly:

1. Open source versus dependency on ESRI product or proprietary data standards, over next five years.

2. Level to which functional components of desktop SDZ, WDZ, and ETR can be met in mobile environment.

3. Ability to support critical SDZ, WDZ, and ETR functions required by Range Inspectors and range safety policies is an essential factor in any COA that will be considered with ability to scale from current user base (including any users of free, open source GIS desktop tools) to anticipated future mobile RMTK.

4. Map background (raster image) with or w/o local technical support.

5. NGEN/MCEN network compliance.

6. Ability of the mobile capability to transmit information across classified wireless distributed networks.

7. Ability of the mobile capability to transmit information across unclassified wireless distributed networks.

8. Cost of proposed solutions – initial and long term.

Scoring criteria were derived from the decision criteria to allow scoring against more actionable and specific statements.

Reduces dependency on specific software suites or proprietary data standards, over next five years.

Provides critical SDZ functions required by Range Inspectors and range safety policies.

Provides functional components of desktop SDZ in mobile environment.

Provides critical WDZ functions required by Range Inspectors and range safety policies.

Provides functional components of desktop WDZ in mobile environment.

Provides critical ETR functions required by Range Inspectors and range safety policies.

Provides functional components of desktop ETR in mobile environment.

Ability to scale from current user base to anticipated future mobile RMTK.

Provides Map background (raster image) w/o local technical support.

Is compliant with NGEN/MCEN network.

Ability of the mobile capability to transmit information across unclassified wireless distributed networks.

Cost - initial implementation Cost - long term sustainment

4-2 recommended Courses of Action Purpose Define courses of action (COAs) based on the analysis, interviews, and research for the USMC to be able to execute a representative sample of the tools.

Introduction The scoring matrix in Table 5-1 is provided for COA 1, 2, and 3 described below.

Table 51 Scoring Matrix

Scoring:

Cost factor:

Cost estimates are rough order of magnitude estimates, based on expected user base and current known costs for licenses, development, and maintenance, that is effective for comparing COAs.

COA 1 – (Recommended) Description Framework: ESRI runtime API Supported Operating System: Android initially (iOS and Windows can be supported) License Costs: $0/Lite Version, ~$300 per standard version initially (minimum 25 purchase limit) - $100 a year maintenance (minimum 25 a year) The ESRI runtime API will allow development across platforms for easy integration into Android, iOS, and Windows. The platform is currently supported by ESRI and is the intended direction for the industry in GIS. The ESRI runtime API also allows for easier integration with other ESRI products (portal, desktop, and server). All the functionality currently required can be provided at the free license level except the rendering of rasters on the fly from the device and not from a pre-made map package. To do this on the fly will require the standard licensing level at a cost. However, two applications can be created that allow for lite users to use as many as possible and only release the standard version for those who need the on the fly imagery use that do not have access to ArcGIS desktop to preprocess it.

Approach Various components would be rewritten and refactored to support this effort. The order of tasking would be the following:

Complete a core rewrite of SDZ and ETR to include no ArcObjects in the core generator and make it compile against the desktop, web, and mobile version. WDZ core rewrite is out of scope for these efforts and is not required for this COA.

Refactor and rewrite the presentation layer to the runtime API using Xamarin.

Create a middle framework that controls various selection criteria and a general library commands. This will then be compiled into versions compatible with desktop, web, and mobile.

A set of interfaces for map interaction, data import, data export, and other miscellaneous functions will be created specific to the mobile platform (i.e. Map data import, data export, move/rotate, etc.)

ESRI free/lite version of runtime supports all the functionality required except for one requirement, which is the use of raster images for map background without processing them to tiled map packages. For this reason, it would be cost beneficial to create two versions of the tool. One that supports all functionality found in ESRI lite and a second standard version with all functionality, which will be limited to those that need the single piece of functionality.

This approach will require preprocessing of some background data in ArcGIS. The data will have to be exported to a tiled map package and imported into the mobile application for raster images to be seen in the background of the lite version. These will then need to be updated as map data changes.

Look, Feel, and Functions The application will attempt to follow standard industry UI while leveraging design of desktop RMTK as reference.

The application will attempt to follow standard industry UI and workflow design where possible. Some examples are Google maps application, ESRI standard map application, and other commonly used mapping applications.

Where wizards and workflows are designed, the look and feel of the desktop will be used as a reference. Nevertheless, some modern environment improvements such as sliding windows, expandable panels, and modern mobile design will be used. The goal being that a Marine that has a basic understanding can figure it out with minimal help.

The look and feel should be similar across COAs 1 through 3.

Permissions, Validation, and Signature and Other General Requirements The application will use the current device user information with the assumption that an authorized user of the device is authorized to use the application. It will use OS level authentication and permission.

The signature (“Made By”) will be name of the user that is logged in.

Required System Interfaces Requirements:

For background data import the device will need to be able to connect and load the needed data from another device.

Created and exported data will need to be copy, exported, or downloaded to another device as needed.

Internal to the device the installer will have to give permissions to access things such as; location, application history, file system, etc. The final list will be determined when compiled for install.

Implementation Assessment (Resources and Time) Core - Core rewrite (SDZ and ETR) resources and time the same for all implementations.

Front end presentation layer will have to be written from scratch. Relative to the other COAs this should be about the same level of resources and time.

The creation of middle framework will be the same effort as the other COAs.

COA 2

Description Framework: Boundless Suite Supported Operating System: Android initially (iOS and Windows can be supported).

License Costs: $0, Boundless technical support cost depends on selected support tier (See Appendix C). Assume single POC to coordinate Boundless technical issues if needed.

A Boundless Suite implementation will facilitate mobile RMTK without losing existing functionality and capabilities. Applications and data will be interoperable with other existing GIS applications and data in the Range enterprise. Components of the Boundless Suite include:

PostGIS : a spatial database extender for the PostgreSQL object-relational database. It adds support for geographic objects allowing location queries to be run in SQL.

GeoServer: an open source server for publishing and sharing geospatial data as web services.

GeoWebCache: a Java web application used to cache map tiles coming from a variety of sources such as OGC Web Map Service (WMS).

QGIS : a free and open source desktop Geographic Information System.

OpenLayers : A high-performance, feature-packed JavaScript library for building web map applications.

Figure 51 Boundless Suite Architecture Approach Current Tools/Algorithms (WDZ, SDZ, ETR, etc.) published to local install of GeoServer for web processing services (WPS) processes. If enterprise WiFi is enabled/authorized, a single implementation of the RMTK tools can be served as WPS from Geoserver within the enterprise when in a connected environment.

OpenLayers3/Cesium JS implementations of WPS processes for “Web” versions (Web WDZ, Web SDZ, etc.), use published WPS processes (ONE version of tool/algorithm) CesiumJS in conjunction with OpenLayers3 allows for 3-D visualization of WDZs, SDZs, etc.

QGIS utilizes WPS versions of tools when in “connected” state; “Offline” mode initializes internal server to the device that houses same WPS services for one version of tool/algorithm with no loss of functionality.

GeoGig for storage/recall/adjustment of previous Range Plans Exchange used for sharing of…