Abstract
The National Geospatial-Intelligence Agency ( NGA ) collaborates with commercial and academic partners to develop and improve technologies for the intelligence community ( IC ) . Within NGA, there is a Research and Development entity that integrates, develops, and transitions relevant technologies for analysts. To understand where work falls within this model, the inherent technical maturity of the research must be identified. Technology Readiness Levels ( TRLs ) , originally developed by NASA and used by the DOD, are used by NGA to quickly assess technical maturity and inherent risks (technical, schedule, cost, or transition). This paper discusses GEOINT-focused performance ratings relevant to TRLs and provides an introduction to a multi-sensor data fusion model.
Introduction
For a systems engineer, the discovery of a new sensor technology rai
...ses new questions.
This paper aims to explore the potential of a new phenomenon that could offer a fresh perspective on an important intelligence task. It raises questions about how to transform this technology into a useful tool and properly evaluate it during its development process, as well as what should be done with the resulting information once the tool is implemented.
The focus of this paper will address these inquiries and use the question of what to do with the information as a framework for one approach to technical evaluation. The initial point of discussion is determining how to manage the influx of new information, even if it proves invaluable and provides previously unattainable answers. There is still a risk of it getting lost amidst extensive repositories of data and tools.
The National Geospatial Intelligence Agency (NGA) recognizes this challenge and already conducts
investigations into various types of geospatial intelligence (GEOINT) detectors such as EO, IR, MSI, HSI, LIDAR, RADAR, Video, etc., along with those based on signals intelligence (SIGINT) among others. As more detectors are introduced, there arises a need for an efficient method to integrate these technologies into existing infrastructures while supporting development efficiency.
To effectively address this demand, the NGA has prioritized research on multi-sensor and multi-intelligence (multi-INT) data fusion.
The chosen application for our new hypothetical engineering is data merger. The primary concern is the rating of this technology. As new technologies emerge, it is important to evaluate them and their potential applications properly. We need to determine if the detector is accurately modeled and if a new mark acknowledgment algorithm will be effective in the required environment. Once this new technology is integrated into an existing system, its output can be combined with the existing data to help reduce uncertainty. However, it could also limit effectiveness and increase overall project risk.
The general trend is that as the proficiency of a new idea increases, its associated risk decreases. The primary measure of proficiency used today is the engineering preparedness degree (TRL). TRLs are often an important aspect of management and learning for many projects. This is partly because they provide a simple representation. One digit gives insight into the longevity of the engineering, amount of testing performed on it, risk associated with project completion, and potential impact on project cost.
Discussion on Technical Readiness
When academia publishes a new paper, it may represent years of research and lay the foundation for a revolutionary concept. However, it is still far from being a feasible product. Academia, industry, and the
government need to have a comprehensive understanding of this idea's proficiency and effectively communicate this understanding in order to make proper investments and further develop it.
It is evident that there would be relatively low risk to incorporate a technology that has already reached full technical maturity compared to one at TRL 1. Moving a new idea into an organization focused on immediate product development will likely cause schedule delays, cost overruns, and project cancellation. That's why the overall TRL of a system should not exceed the lowest TRL component. For example, if an inexperienced rocket engine is to be added to the current spacecraft, it should be clear that significant delays or risks will arise for the next space flight. Technical readiness levels were initially introduced by NASA in the 1970s to assist in assessing new technology development. Although there have been different definitions developed since then by NASA, the DOD, and other organizations, most still have the same structure and purpose.
The Technology Readiness Levels (TRLs) consist of 9 separate degrees. TRL 1 represents a basic principle, while TRL 9 indicates a completed product successfully tested in its intended environment. Although the definitions for each TRL degree are clear, interpreting results can sometimes be unclear. Merely testing and evaluating a project for each degree is insufficient; it must also meet certain expectations to progress to the next level. As projects become more complex or expensive, there is a tendency to accept work of limited quality. Thus, having an independent group perform evaluations against standardized requirements is often beneficial. This formal testing model aids in identifying unmanageable risks before investing excessive time and money into development.
Additionally, identifying unwieldy risks early on allows for cheaper adjustments to mitigate them.
If the engineering fails the evidence of concept trial at TRL 3, it is unnecessary to proceed to the next level. This could mean that more attention is required at this stage or that the technology is better suited for a different application. Each new technology should be tested at every level, starting from the lowest and progressing to the highest, without skipping any levels in order to continue with the program. Some may argue that reaching TRL 6 is the ultimate goal in the development cycle, as this is when a fully integrated prototype undergoes successful testing.
In the development process, the next stage involves refining and testing the system in a real-life setting that may be beyond the control of the original developer. For example, if the project is an unmanned aerial system (UAS) capable of gathering data and assessing battlefield situations realistically, then it should be tested on an airborne platform. The development process is considered complete when the system reaches TRL 8. TRL 9 signifies that the system has successfully accomplished missions carried out by intended users in their intended environment.
If the system was designed for a combat vehicle, it would need to go on actual missions in a combat theater to reach the final stage of technical maturity.
Fusion Application Development
To demonstrate the use and definitions of TRL levels, let's consider a fictional program that involves new sensor technology. Usually, it would be customary to develop a new sensor or fusion algorithm independently from the overall system development. However, in this scenario, they will be merged for simplicity's sake. As
previously mentioned, there is already abundant data accessible for utilization by a restricted group of analysts.
Even if critical national security information is present and has been gathered, what are the chances of it reaching the relevant analyst in a timely manner? One method is to create data fusion technologies that serve two main purposes. Firstly, merging information dynamically and autonomously in as close to real-time as required. This can involve raw sensor data or processed data. Secondly, analyzing this merged information so that its relevance can be determined before analysts have access to it. This approach of alert services enhances the probability of analysts focusing on the most crucial information.
Following the Path of Technical Maturity
Basic Research
It is likely a fair assumption that most undertakings begin with an idea. At this point, a researcher can start investigating the fundamental science behind the idea to determine the amount of effort required. In this case, research has found that a new detector phenomenology could potentially be achieved. We are aware that we need to combine the resulting data with existing detector data in a way that allows for automated analysis. Since we are discussing a new merging process or the merging of new types of data without a well-defined approach, this specific merging process would be considered TRL 1.
The possible outcomes of a TRL 1 thought are: concluding it is not suitable for further development, publishing a paper on its fundamental properties, or advancing it to TRL 2. Advancing to TRL 2 necessitates conducting a formal investigation into the thought's usage. Although practical applications and potential operational designs are considered at this stage, there is currently no evidence
to support the effectiveness of the thought. Once data is collected and combined, we can evaluate the resulting product. This evaluation involves determining if there are synthetic features like roads or pavements present, as well as identifying targets such as tanks and aircraft. After these identities are established and merged together, decisions can be made based on this information. It is also possible to enhance the analysis or situational assessment by incorporating additional information from signals intelligence (SIGINT) or human aggregation (HUMINT). The concept currently consists of four stages: data fusion, feature/target analysis, feature/target identification, and conclusions/situational assessment.The text describes the stages of the JDL revised data fusion model, which align with the functional data fusion. These stages include entity appraisal, situation appraisal, impact assessment, and procedure appraisal. Once the functional appraisal is taken into account, it allows for identification of the required components to meet specific requirements.
Insight can also be gained into the requirements for performance, size, shape, and power needs. A basic model can be created for standards and test programs. Once the application is deemed satisfactory and a design begins to take shape, the technology can be considered TRL 2. After active R;D on the fundamental technology is initiated and some form of appropriate testing is conducted, the concept is proven and can be considered TRL 3. This represents the first level of actual testing and may involve the execution of an algorithm or laboratory results as long as it confirms a key aspect of the technology.
Various trials can be conducted on different, stray, non-representative constituents of the system to verify the feasibility of individual technologies and ensure that the false alarm
rate is not excessive. Once it is demonstrated that individual parts are capable of fulfilling their required tasks, testing is considered complete. Additional potential outcomes include technology coding, schematics, and high-level requirements. Now that the concept behind the technology has been tested, risk has been sufficiently reduced to explore more serious ideas for commercial or government applications. At this stage, you have the following options:
- Determine if the technology is mature enough
- Confirm there is a demand for its application
- Refine the concept further
- Explore alternative uses for the technology
- Create a plan for integrating components
- Improve system functionality and performance requirements
- Create a roadmap towards delivering a TRL 7 system.
Technology development (TRL 4-5)
To reach TRL level 4, it is necessary to incorporate the merger algorithm into software and integrate other low-fidelity software and hardware components.
This is the initial stage where the application's individual components are combined and tested. This stage confirms that the components can effectively work together and represents the first step towards validating the overall map functionality. Although this package may be basic and inefficient, its purpose is not to offer a marketable solution, but rather to make progress in that direction. In fact, various paradigms might be necessary to verify different test scenarios. The next stage of technical maturity entails testing the components in a suitable real-world setting.
The system may still be in the original development research lab environment, but it now uses existing information or interacts with existing libraries or communication systems. Simulated connections to other systems are used to help verify system integration. The relevant environment may also involve realistic problems. Once
at TRL 5, the technology is ready to be integrated into existing systems.
System Development (TRL 6-7)
TRL 6 fully demonstrates the feasibility of the technology. Instead of evaluating individual components, the system prototype is fully developed with all components working together.
This also includes being connected to Bing systems and running on fully realistic tasks in a simulated operational environment. This showcases form, suitability, function, and verifies all system requirements. User and training manuals may be completed at this stage. The remaining three levels of technical maturity only involve the refinement of the final system from the now finalized model and its usage in the operational environment.
After successfully working together and evaluated, the paradigm undergoes further development and is brought into the coveted environment for proving and rating. This system is close to becoming the planned operational system. Depending on the final construct for the application, the system would either be moved into operations or flown on a bed aircraft. The operational value of the application is confirmed. Before continuing with concluding system development, all stakeholders should be involved and agree that everything is running as expected.
System Test and Operation (TRL 8-9)
The system is further developed in built into its final form, which is then tested and demonstrated.
Once the deliverable quality system is created and tested, it is classified as TRL 8 when development is finished. The final TRL is attained when the operational version of the system is functioning in the operational environment and successfully completes entire missions.
- Genetic Engineering essays
- Bus essays
- Internal Combustion Engine essays
- Hybrid essays
- Electric Car essays
- Invention essays
- Mechanics essays
- Innovation essays
- Telephone essays
- Software Engineering essays
- Automobile essays
- Cycling essays
- Civil engineering essays
- Mechanical Engineering essays
- Bentley essays
- Animals essays
- Charles Darwin essays
- Agriculture essays
- Archaeology essays
- Moon essays
- Space Exploration essays
- Sun essays
- Universe essays
- Birds essays
- Horse essays
- Bear essays
- Butterfly essays
- Cat essays
- Dolphin essays
- Monkey essays
- Tiger essays
- Whale essays
- Lion essays
- Elephant essays
- Mythology essays
- Time Travel essays
- Discovery essays
- Thomas Edison essays
- Linguistics essays
- Journal essays
- Chemistry essays
- Biology essays
- Physics essays
- Seismology essays
- Reaction Rate essays
- Roman Numerals essays
- Scientific Method essays
- Mineralogy essays
- Plate Tectonics essays
- Logic essays