Threat weapon systems used in the attacks against our mounted/dismounted combat personnel and their support systems are a critical-priority Request for Information (RFI) for Warfighters and force modernization senior leaders. Intelligence, test and evaluation, research and development, and medical analysts from multiple organizations within the Department of War (DoW) share similar interests in identifying, tracking, and analyzing attacks on U.S. and allied forces to support a range of critical activities, including, but not limited to, weapon use tracking; protective design technique evolution; threat mitigation tactics, techniques, and procedures; and the design and integration of new protective design measures to mitigate lethal effects to existing and emerging weapons systems. Currently, analysts must gather segregated information, consolidate it, process it, and then produce the documentation and data points needed for RFIs, trend analyses, details studies, and relevant models. This task can be time and resource intensive.
Accordingly, the U.S. Army Engineer Research and Development Center (ERDC), National Ground Intelligence Center (NGIC), Joint Aircraft Survivability Program Office (JASPO), and Joint Trauma Analysis and Prevention of Injury in Combat (JTAPIC) collaborated to investigate conventions between a range of key controlled database systems and develop interoperability options to allow analysts and soldiers to have compartmentalized access to one system for combined data, thereby producing a compiled, faster, and more complete and efficient set of results. This work has the potential to significantly reduce the man-hours needed to produce improved data analytics used in critical RFIs for decision-making processes. In addition, it promises to create a new capability that would support and impact multi-domain operations and full spectrum survivability.
The goal of this effort was to work with the individual owners of select systems to investigate and design an initial convention that could be extended to the current systems and potentially applied to other systems within the DoW. Figure 1 illustrates the basic proposed flow of data, systems, and users.
This effort detailed how to significantly enhance current capabilities by establishing internal communication between said programs, created a communication blueprint for access and sharing/ingestion of data, and demonstrated the design and how it could be applied for outside systems. The proposed tasks were straightforward in nature, but complex in execution. The seven tasks identified were as follows:
Figure 1. Proposed Data Flowchart.
- Identify correlations between database objects (hundreds to thousands of incident cases with critical details, such as munitions/weapons, strike locations, injuries, and affected support systems).
- Establish translation and conversion algorithms, including creating an overarching database with new standard objects.
- Translate and migrate each database’s data to new objects.
- Test to make sure all tools are working, provide accurate results, contain no loss of capabilities, and maintain all security restrictions.
- Transition to production networks for demonstration and evaluation.
- Create a generalized blueprint.
- Construct a blueprint and demonstration documentation on how others can access and/or make personalized modifications. The demonstration would include an overall summary of the blueprint, as well as, more specifically, how to request and receive access through and across said systems and how to adjust the algorithm or create a translator for the objects to be included in outside systems. This includes identifying requests and establishing a shared data connection between the current and new systems. The effort would work with the key agencies throughout the process and gain approval for all demonstrations. In addition to the transition of the internal communication framework, this demonstration would be presented to the program office for a path forward for future development.
These seven tasks were further broken down and modified/expanded into five phases, Phases 0–IV. Phase 0, which was funded and completed, included finalization of the full scope of the project, background research on current data sharing and network technologies, and comparison of system details and data.
Getting Started – Phase 0
The project scope included three separate systems and stakeholders. Each system used its established development team with a designated project lead. Phase 0, detailed in Figure 2, involved identifying what items would need to be completed during the background/research phase of this effort.
Figure 2. Phase 0 Flowchart.
The first step in Phase 0 was to define use cases. Project lead liaised with their respective system owners and discussed use cases that would be relevant to the data-sharing options. To provide system owners with general knowledge of what is possible to be shared, the project leads pulled database schemas, scrubbed for appropriate sharing, and disseminated with all parties. This approach allowed each system owner the opportunity to decide on the use cases to be used in the study. These cases were separated into two categories, priority and future. All use cases were recorded and investigated for any concerns and possible issues with system owners.
The next step in Phase 0 was a Go/No Go decision based on the use cases and schema to determine if a set of standard objects would be possible. Project leads discussed with their sponsors items from the database schemas that they wanted to share with the other projects. These approved schemas were then shared with the other project leads. The system owners were then consulted on what data seemed relevant to them to receive from the other systems. The initial discussions included comparing all three systems’ approved data schemas that might overlap to identify a standard set of objects. The assumption was that this standardized object mapping to individual systems would allow for a common data set of reference between the three systems, forcing cleaner matching and better/quicker analysis by users.
Subsequent discussions identified that mapping of the data between systems would be extremely time consuming and difficult because each system used a different data management style. For example, System 3 holds the name of a weapon as a free text string, which the user enters. This style allows System 3 users to type in anything and any name they wish, which is beneficial in that it doesn’t require maintaining a complete list of weapons in the world. By contrast, System 2 maintains a complete list of weapons with unique IDs that is compiled into a four-level tree that lets users dig down to find specific weapons. Mapping these two data styles to each other would’ve required extensive effort to review each of the System 3 entered data elements with the System 2 tree data matching where possible. Similar data issues were likewise found in numerous other areas of all three systems.
Along with the excessive amount of effort to map the data elements, it was discussed that there would also need to be a maintenance system applied to the standard objects. This maintenance would include storage for the objects (possibly a centralized database), a configuration change board, a process for updating or modifying the objects, and the funding cost associated with these needs. Creating and maintaining this separate system simply did not seem feasible or cost efficient. At this time, the decision on standard objects was thus a No Go.
Therefore, the team redirected and began to focus directly on application programming interfaces (APIs) and what structure and documentation would be best for the blueprint design. The first step was to define how the systems should communicate. To determine any network communication hurdles, a network diagram (shown in Figure 3) was created, identifying where each system is deployed and how the connections should work.
Figure 3. Network Diagram.
For the documentation and structure of the APIs, different examples were researched. One example presented was the documentation that is provided with Google APIs [1]. The APIs and documentation would be customized by each system but would have a similar style for Phase 0. Each team agreed that the initial display of other systems’ data would be most likely just displaying a key value pair of strings. This would reduce the return structure and allow for quick graphical user interface (GUI) development for displaying the acquired data. More complex structures could be used later that would give the systems the opportunity to enhance the display. The documentation for the format was agreed to include an endpoint name, version, description, uniform resource locator (URL), authentication requirements, method type, input parameters, response, attributes, and JavaScript Object Notation (JSON) response example. Mockup examples of the extended GUI screens and example APIs were included in the deliverable for the effort.
The final task of Phase 0 was to complete the generalized blueprint for other projects to use the established standards and produce APIs in the format that the other projects can use. The blueprint included the following identified key items:
- Each system will be independent.
- Each system must be located on the same network but may not be in the same enclave.
- Each system will use Rest APIs as the communication tool.
- For initial implementation, limited search parameters and APIs will be used.
- For initial implementation, a response JSON structure with key/value pair items will be returned.
- All APIs will be defined and documented using the standard structure.
- Each system will develop its own display screens within the theme and layout of its native system.
- For ease, the initial APIs will be in a JSON structure with system-specific row items, but the data will be in a key/value pair of Display Title and Display Data both strings.
Future Work
An implementation plan was constructed to move this initial research into implementation and deployment if future funding is secured. Figure 4 shows the possible phases and options that could be realized.
Figure 4. Future Phases.
Phase I would include implementing limited APIs. Implementation of limited search APIs will allow for an initial/limited amount of data to be shared between systems as a proof-of-concept that the data share would be successful. Search parameters should be limited to items that are proven to be common across all three systems. Items such as dates and locations of a specific format only should be used for the initial implementation. The return responses should be limited to contents based on priority/necessity indicated by system owners. The results should be in a JSON key/value format. (Note that the response items are for display only.) The GUI screens and displays would be system dependent and fit in seamlessly with the native system.
Phase II would include possible implementation of unlimited APIs. Research would be conducted on if hardware/network/buffering could handle sharing all approved data. This phase would include a Go/No Go risk. There could be massive amounts of data that could overload systems/networks or create corrupted/lost data. If a No Go is determined, then documentation of the limitations/restrictions would be encouraged. Technology changes often, and this documentation will provide insight into attempting to expand APIs if future technology allows. If a Go is determined, previous APIs should be extended or new ones implemented to expand the data to the full capacity of approved data to be shared. This again would be system dependent, require updating to the documentation, and may require expanding of the display only data screens per system.
Phase III would include expanding the APIs to include less restricted/unrestricted searches. A multi-relational API system would be constructed as needed per system to allow for more complex searches. Each system would create a set of APIs so that the current lists items can be acquired. The system would use these list items when sending the search API to receive highly queried/filtered data. This is still system dependent so the number of APIs and nesting would vary greatly. If implemented, it would be equivalent to the advanced searches each system currently contains. This phase requires major adjustments to the display/entry screens within the native systems. The list items (some of which are trees) would have to be displayed in a way for users to choose which search parameters they want and then inserted into the new calls. Depending on the system, those screens could be extensive.
Phase IV, the final phase, would show a possibility for including predictions into the systems. The purpose of the sharing and displaying of the connected data would be to enhance what is known about an event while saving time/labor for an analyst. If the system were able to generate and display event-related suggestions, a better whole picture could be established. Suggestions can be made through many methods, basic Structured Query Language (SQL) searches, artificial intelligence/machine learning (AI/ML), and/or other tools to identify events that may be related. Research would be conducted (again system dependent, if necessary, based on framework and language) on the best ways to produce those suggestions.
A Go/No Go risk would be at this stage in the phase. If determined that no good suggestions can be made at this time, limitations/restrictions would be documented for future understanding. If a Go was determined, the suggestion tools would be implemented and tested within the three systems. Within the display, entry screens, a quality assurance/quality control (QA/QC) section would be added. Each system’s analysts would get to approve/disapprove if predicted data between the systems is related, so a user would see if others agreed the items are related or not. Checks and balances for prediction methods and for system analyst autonomy to disagree would also need to be implemented. The agree/disagree would be added to the API data shared with all systems.
Conclusion
This work discussed herein has investigated conventions between a range of key controlled database systems and associated interoperability options to enable analysts and Warfighters to have a compiled, faster, and more complete and efficient set of results to answer critical RFIs. Ongoing efforts promise to provide continued progress in this area, as well as additional opportunities to share this new capability, strengthen networks, and possibly integrate successes into future development. Phase 0 of this work successfully laid out a blueprint for a prototype measure to share limited data between three test systems. Phases I–IV would likewise define the implementation of that blueprint, advanced expansions into sharing large amounts of data, and predictions with QA/QC systems.
About the Authors
Dr. Jennerpher Bryner is a computer scientist in the CAD/BIM Technology Center, Information Technology Laboratory, at the U.S. Army Corps of Engineers, Engineer Research and Development Center (ERDC). She is currently involved in a wide range of software engineering, code modernization, artificial intelligence/machine language data science, and interactive outreach programs. Dr. Bryner holds a bachelor’s degree in mathematics and psychology, a master’s degree in computer science, and a doctorate in computational science from the University of Southern Mississippi.
Mr. Jeffery Stokes is a software engineer at the Information Technology Laboratory, with more than 20 years of experience supporting ERDC. He specializes in developing production-grade, web-based applications in support of stakeholders across the DoW. He currently leads a team of developers working on the Joint Trauma Analysis and Prevention of Injury in Combat (JTAPIC) Information and Collaboration System. Mr. Stokes holds a bachelor’s degree in software engineering and a master’s degree in computer science from Mississippi State University.
Mr. Joseph Toth is an information technology professional and aircraft survivability consultant for the SURVICE Engineering Company and a retired U.S. Navy Reserve captain. He has more than two decades of experience in enterprise technology, defense modernization, aircraft survivability, and aviation operations and has served in numerous key leadership roles, including supporting the Naval Air Systems Command, the Joint Combat Aircraft Team, and JASPO. Mr. Toth holds a B.S. from the U.S. Naval Academy and an M.S. in management of information systems from Bowie State University.
Mr. Oran Wallace is a professional computer scientist and team leader at the SURVICE Engineering Company. He currently leads the maintenance and development of the Advanced Survivability Assessment Program (ASAP). In addition, he develops and maintains the Combat Damage Incident Reporting System (CDIRS) web application. Mr. Wallace hold a bachelor’s and a master’s degree in computer science from the New Mexico Institute of Mining and Technology and the Georgia Institute of Technology, respectively.
