Search NASA⌕ Search

SEARCH · Search NASA

Results for “scope”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 235 records · Page 13

Using Distributed Operations to Enable Science Research on the International Space Station

In the early days of the International Space Station (ISS) program, and as the organization structure was being internationally agreed upon and documented, one of the principal tenets of the science program was to allow customer-friendly operations. One important aspect of this was to allow payload developers and principle investigators the flexibility to operate their experiments from either their home sites or distributed telescience centers. This telescience concept was developed such that investigators had several options for ISS utilization support. They could operate from their home site, the closest telescience center, or use the payload operations facilities at the Marshall Space Flight Center in Huntsville, Alabama. The Payload Operations Integration Center (POIC) processes and structures were put into place to allow these different options to its customers, while at the same time maintain its centralized authority over NASA payload operations and integration. For a long duration space program with many scientists, researchers, and universities expected to participate, it was imperative that the program structure be in place to successfully facilitate this concept of telescience support. From a payload control center perspective, payload science operations require two major elements in order to make telescience successful within the scope of the ISS program. The first element is decentralized control which allows the remote participants the freedom and flexibility to operate their payloads within their scope of authority. The second element is a strong ground infrastructure, which includes voice communications, video, telemetry, and commanding between the POIC and the payload remote site. Both of these elements are important to telescience success, and both must be balanced by the ISS program s documented requirements for POIC to maintain its authority as an integration and control center. This paper describes both elements of distributed payload operations and discusses the benefits and drawbacks.

Bathew, Ann S.↗

RAT Requisition Approval Team - A L6S Initiative

L6S Project Description - Problem: The current cycle time for generating and approving Requisitions does not meet "Best-In-Class." . Scope: Only looking at the Florida Requisition Approval process for Orbiter (ORBF & ORBG) and Ground (GFAC) stocked items. This includes the time from when a requirement is generated by Logistics Planning and Supportability in Florida until it is approved and received by Procurement. Requisitions generated at other sites or for non stocked items will be out of scope of this Project

Hall, Valerie↗

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014. The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such a comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass, ground operations can still reduce mission costs through smaller staffing of operators and limiting their working hours. The challenge, then, for the SMAP GDS engineering team, is to formulate an automated operations strategy--and corresponding system architecture -- to minimize operator intervention during routine operations, while balancing the development costs associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS -- NASA's AMMOS Mission Data Processing and Control System (AMPCS) -- provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

soil moisture↗

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014.[double dagger] The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass ground operations can still reduce mission cost through smaller staffing of operators and limited work hours. The challenge, then, for the SMAP GDS engineering team is to formulate an automated operations strategy--and corresponding system architecture--to minimize operator intervention during operations, while balancing the development cost associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS--NASA's AMMOS Mission Data Processing and Control System (AMPCS)--provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

remote-sensing↗

A Wind-powered Rover for a Low-Cost Venus Mission

Venus, with a surface temperature of 450 C and an atmospheric pressure 90 times higher than that of the Earth, is a difficult target for exploration. However, high-temperature electronics and power systems now being developed make it possible that future missions may be able to operate in the Venus environment. Powering such a rover within the scope of a Discovery class mission will be difficult, but harnessing Venus' surface winds provides a possible way to keep a powered rover small and light. This project scopes out the feasibility of a wind-powered rover for Venus surface missions. Two rover concepts, a land-sailing rover and a wind-turbine-powered rover, were considered. The turbine-powered rover design is selected as being a low-risk and low-cost strategy. Turbine detailed analysis and design shows that the turbine can meet mission requirements across the desired range of wind speeds by utilizing three constant voltage generators at fixed gear ratios.

Benigno, Gina↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

U.S. Spacesuit Knowledge Capture Series Catalog

The National Aeronautics and Space Administration (NASA) and other organizations have been performing U.S. Spacesuit Knowledge Capture (USSKC) since the beginning of space exploration through published reports, conference presentations, specialized seminars, and classes instructed by veterans in the field. The close physical interaction between spacesuit systems and human beings makes them among the most personally evocative pieces of space hardware. Consequently, spacesuit systems have required nearly constant engineering refinements to do their jobs without impinging on human activity. Since 2008, spacesuit knowledge capture has occurred through video recording, engaging both current and former specialists presenting technical scope specifically to educate individuals and preserve knowledge. These archives of spacesuit legacy reflect its rich history and will provide knowledge that will enhance the chances for the success of future and more ambitious spacesuit system programs. The scope and topics of USSKC have included lessons learned in spacesuit technology; experience from the Gemini, Apollo, Skylab, and Shuttle Programs; the process of hardware certification, design, development, and other program components; spacesuit evolution and experience; failure analysis and resolution; and aspects of program management. USSKC activities have progressed to a level where NASA, the National Air and Space Museum (NASM), Hamilton Sundstrand (HS) and the spacesuit community are now working together to provide a comprehensive way to organize and archive intra-agency information related to the development of spacesuit systems. These video recordings are currently being reviewed for public release using NASA export control processes. After a decision is made for either public or non-public release (internal NASA only), the videos and presentations will be available through the NASA Johnson Space Center Engineering Directorate (EA) Engineering Academy, the NASA Technical Reports Server (NTRS), the NASA Aeronautics & Space Database (NA&SD), or NASA YouTube. Event availability is duly noted in this catalog.

Bitterly, Rose↗

Consolidated Development Objectives Document (CDOD) For MB-60

This document defines the objectives related to liquid rocket engine system development to be undertaken by JAXA in support of the Space Launch System (SLS) Program managed out of the NASA Marshall Space Flight Center (MSFC). These objectives include furnishing the necessary management, labor, facilities, tools, equipment, and materials required to execute the specified activities. 1.1 Project Scope: The scope of this effort is to develop a rocket engine and associated products per the objectives and technical requirements established in this document. This engine, minus the engine controller, designated here as MB ]60, is to be developed through to a prequalification point of maturity. It is assumed that should JCNE ]1 development proceed beyond this maturity point towards actual flight qualification, the engine controller will be supplied and integrated by NASA. 1.2 Document Structure: The structure of this Consolidated Development Objectives Document (CDOD) includes a traditional description of objectives in a SOO, plus the associated Data Products Document (DPD) in an attached appendix, and then Engine Requirements Document (ERD) as another attached appendix. It is the intent that this document, in conjunction with the cited applicable documents, should constitute a complete programmatic and technical description of the development effort to be pursued.

Greene, William D.↗

Athena in 2013 and Beyond

TRISA, the U.S. Army TRADOC G2 Intelligence Support Activity, received Athena 1 in 2009. They first used Athena 3 to support studies in 2011. This paper describes Athena 4, which they started using in October 2012. A final section discusses issues that are being considered for incorporation into Athena 5 and later. Athena's objective is to help skilled intelligence analysts anticipate the likely consequences of complex courses of action that use our country's entire power base, not just our military capabilities, for operations in troubled regions of the world. Measures of effectiveness emphasize who is in control and the effects of our actions on the attitudes and well-being of civilians. The planning horizon encompasses not weeks or months, but years. Athena is a scalable, laptop-based simulation with weekly resolution. Up to three months of simulated time can pass between game turns that require user interaction. Athena's geographic scope is nominally a country, but can be a region within a county. Geographic resolution is "neighborhoods", which are defined by the user and may be actual neighborhoods, provinces, or anything in between. Models encompass phenomena whose effects are expected to be relevant over a medium-term planning horizon-three months to three years. The scope and intrinsic complexity of the problem dictate a spiral development process. That is, the model is used during development and lessons learned are used to improve the model. Even more important is that while every version must consider the "big picture" at some level of detail, development priority is given to those issues that are most relevant to currently anticipated studies. For example, models of the delivery and effectiveness of information operations messaging were among the additions in Athena 4.

Chamberlain, Robert G.↗

Advanced Strategic and Tactical Relay Request Management for the Mars Relay Operations Service

This software provides a new set of capabilities for the Mars Relay Operations Service (MaROS) in support of Strategic and Tactical relay, including a highly interactive relay request Web user interface, mission control over relay planning time periods, and mission management of allowed strategic vs. tactical request parameters. Together, these new capabilities expand the scope of the system to include all elements critical for Tactical relay operations. Planning of replay activities spans a time period that is split into two distinct phases. The first phase is called Strategic, which begins at the time that relay opportunities are identified, and concludes at the point that the orbiter generates the flight sequences for on board execution. Any relay request changes from this point on are called Tactical. Tactical requests, otherwise called Orbit - er Relay State Changes (ORSC), are highly restricted in terms of what types of changes can be made, and the types of parameters that can be changed may differ from one orbiter to the next. For example, one orbiter may be able to delay the start of a relay request, while another may not. The legacy approach to ORSC management involves exchanges of e-mail with "requests for change" and "acknowledgement of approval," with no other tracking of changes outside of e-mail folders. MaROS Phases 1 and 2 provided the infrastructure for strategic relay for all supported missions. This new version, 3.0, introduces several capabilities that fully expand the scope of the system to include tactical relay. One new feature allows orbiter users to manage and "lock" Planning Periods, which allows the orbiter team to formalize the changeover from Strategic to Tactical operations. Another major feature allows users to interactively submit tactical request changes via a Web user interface. A third new feature allows orbiter missions to specify allowed tactical updates, which are automatically incorporated into the tactical change process. This software update is significant in that it provides the only centralized service for tactical request management available for relay missions.

Allard, Daniel A.↗

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗

Rewriting Modulo SMT

Combining symbolic techniques such as: (i) SMT solving, (ii) rewriting modulo theories, and (iii) model checking can enable the analysis of infinite-state systems outside the scope of each such technique. This paper proposes rewriting modulo SMT as a new technique combining the powers of (i)-(iii) and ideally suited to model and analyze infinite-state open systems; that is, systems that interact with a non-deterministic environment. Such systems exhibit both internal non-determinism due to the system, and external non-determinism due to the environment. They are not amenable to finite-state model checking analysis because they typically are infinite-state. By being reducible to standard rewriting using reflective techniques, rewriting modulo SMT can both naturally model and analyze open systems without requiring any changes to rewriting-based reachability analysis techniques for closed systems. This is illustrated by the analysis of a real-time system beyond the scope of timed automata methods.

Rocha, Camilo↗

Configuration Management Process Assessment Strategy

Purpose: To propose a strategy for assessing the development and effectiveness of configuration management systems within Programs, Projects, and Design Activities performed by technical organizations and their supporting development contractors. Scope: Various entities CM Systems will be assessed dependent on Project Scope (DDT&E), Support Services and Acquisition Agreements. Approach: Model based structured against assessing organizations CM requirements including best practices maturity criteria. The model is tailored to the entity being assessed dependent on their CM system. The assessment approach provides objective feedback to Engineering and Project Management of the observed CM system maturity state versus the ideal state of the configuration management processes and outcomes(system). center dot Identifies strengths and risks versus audit gotcha's (findings/observations). center dot Used "recursively and iteratively" throughout program lifecycle at select points of need. (Typical assessments timing is Post PDR/Post CDR) center dot Ideal state criteria and maturity targets are reviewed with the assessed entity prior to an assessment (Tailoring) and is dependent on the assessed phase of the CM system. center dot Supports exit success criteria for Preliminary and Critical Design Reviews. center dot Gives a comprehensive CM system assessment which ultimately supports configuration verification activities.*

Henry, Thad↗

Initial Assessment of a Variable-Camber Continuous Trailing-Edge Flap System on a Rigid Wing for Drag Reduction in Subsonic Cruise

In this paper, we describe an initial optimization study of a Variable-Camber Continuous Trailing-Edge Flap (VCCTEF) system. The VCCTEF provides a light-weight control system for aircraft with long flexible wings, providing efficient high-lift capability for takeoff and landing, and greater efficiency with reduced drag at cruising flight by considering the effects of aeroelastic wing deformations in the control law. The VCCTEF system is comprised of a large number of distributed and individually-actuatable control surfaces that are constrained in movement relative to neighboring surfaces, and are non-trivially coupled through structural aeroelastic dynamics. Minimzation of drag results in a constrained, coupled, non-linear optimization over a high-dimension search space. In this paper, we describe the modeling, analysis, and optimization of the VCCTEF system control inputs for minimum drag in cruise. The purpose of this initial study is to quantify the expected benefits of the system concept. The scope of this analysis is limited to consideration of a rigid wing without structural flexibility in a steady-state cruise condition at various fuel weights. For analysis, we developed an optimization engine that couples geometric synthesis with vortex-lattice analysis to automate the optimization procedure. In this paper, we present and describe the VCCTEF system concept, optimization approach and tools, run-time performance, and results of the optimization at 20%, 50%, and 80% fuel load. This initial limited-scope study finds the VCCTEF system can potentially gain nearly 10% reduction in cruise drag, provides greater drag savings at lower operating weight, and efficiency is negatively impacted by the severity of relative constraints between control surfaces.

trailing edge flaps↗

Coupled Solid Rocket Motor Ballistics and Trajectory Modeling for Higher Fidelity Launch Vehicle Design

Multi-stage launch vehicles with solid rocket motors (SRMs) face design optimization challenges, especially when the mission scope changes frequently. Significant performance benefits can be realized if the solid rocket motors are optimized to the changing requirements. While SRMs represent a fixed performance at launch, rapid design iterations enable flexibility at design time, yielding significant performance gains. The streamlining and integration of SRM design and analysis can be achieved with improved analysis tools. While powerful and versatile, the Solid Performance Program (SPP) is not conducive to rapid design iteration. Performing a design iteration with SPP and a trajectory solver is a labor intensive process. To enable a better workflow, SPP, the Program to Optimize Simulated Trajectories (POST), and the interfaces between them have been improved and automated, and a graphical user interface (GUI) has been developed. The GUI enables real-time visual feedback of grain and nozzle design inputs, enforces parameter dependencies, removes redundancies, and simplifies manipulation of SPP and POST's numerous options. Automating the analysis also simplifies batch analyses and trade studies. Finally, the GUI provides post-processing, visualization, and comparison of results. Wrapping legacy high-fidelity analysis codes with modern software provides the improved interface necessary to enable rapid coupled SRM ballistics and vehicle trajectory analysis. Low cost trade studies demonstrate the sensitivities of flight performance metrics to propulsion characteristics. Incorporating high fidelity analysis from SPP into vehicle design reduces performance margins and improves reliability. By flying an SRM designed with the same assumptions as the rest of the vehicle, accurate comparisons can be made between competing architectures. In summary, this flexible workflow is a critical component to designing a versatile launch vehicle model that can accommodate a volatile mission scope.

Ables, Brett↗

Reflections on Centaur Upper Stage Integration by the NASA Lewis (Glenn) Research Center

The NASA Glenn (then Lewis) Research Center (GRC) led several expendable launch vehicle (ELV) projects from 1963 to 1998, most notably the Centaur upper stage. These major, comprehensive projects included system management, system development, integration (both payload and stage), and launch operations. The integration role that GRC pioneered was truly unique and highly successful. Its philosophy, scope, and content were not just invaluable to the missions and vehicles it supported, but also had significant Agencywide benefits. An overview of the NASA Lewis Research Center (now the NASA Glenn Research Center) philosophy on ELV integration is provided, focusing on Atlas/Centaur, Titan/Centaur, and Shuttle/Centaur vehicles and programs. The necessity of having a stable, highly technically competent in-house staff is discussed. Significant depth of technical penetration of contractor work is another critical component. Functioning as a cohesive team was more than a concept: GRC senior management, NASA Headquarters, contractors, payload users, and all staff worked together. The scope, content, and history of launch vehicle integration at GRC are broadly discussed. Payload integration is compared to stage development integration in terms of engineering and organization. Finally, the transition from buying launch vehicles to buying launch services is discussed, and thoughts on future possibilities of employing the successful GRC experience in integrating ELV systems like Centaur are explored.

Launch Vehicle↗

Ontological Modeling for Integrated Spacecraft Analysis

Current spacecraft work as a cooperative group of a number of subsystems. Each of these requiresmodeling software for development, testing, and prediction. It is the goal of my team to create anoverarching software architecture called the Integrated Spacecraft Analysis (ISCA) to aid in deploying the discrete subsystems' models. Such a plan has been attempted in the past, and has failed due to the excessive scope of the project. Our goal in this version of ISCA is to use new resources to reduce the scope of the project, including using ontological models to help link the internal interfaces of subsystems' models with the ISCA architecture.I have created an ontology of functions specific to the modeling system of the navigation system of a spacecraft. The resulting ontology not only links, at an architectural level, language specificinstantiations of the modeling system's code, but also is web-viewable and can act as a documentation standard. This ontology is proof of the concept that ontological modeling can aid in the integration necessary for ISCA to work, and can act as the prototype for future ISCA ontologies.

ontological modeling↗

Athena in 2013 and Beyond

TRISA, the U.S. Army TRADOC G2 Intelligence Support Activity, received Athena 1 in 2009. They first used Athena 3 to support studies in 2011. This paper describes Athena 4, which they started using in October 2012. A final section discusses issues that are being considered for incorporation into Athena 5 and later. Athena's objective is to help skilled intelligence analysts anticipate the likely consequences of complex courses of action that use our country's entire power base, not just our military capabilities, for operations in troubled regions of the world. Measures of effectiveness emphasize who is in control and the effects of our actions on the attitudes and well being of civilians. The planning horizon encompasses not weeks or months, but years.Athena is a scalable, laptop-based simulation with weekly resolution. Up to three months of simulated time can pass between game turns that require user interaction. Athena's geographic scope is nominally a country, but can be a region within a county. Geographic resolution is "neighborhoods", which are defined by the user and may be actual neighborhoods, provinces, or anything in between. Models encompass phenomena whose effects are expected to be relevant over a medium-term planning horizon--three months to three years.The scope and intrinsic complexity of the problem dictate a spiral development process. That is, the model is used during development and lessons learned are used to improve the model. Even more important is that while every version must consider the "big picture" at some level of detail, development priority is given to those issues that are most relevant to currently anticipated studies. For example, models of the delivery and effectiveness of information operations messaging were among the additions in Athena 4.

Diplomatic, Informational, Military, Economic (DIM↗