SEARCH · Search NASA

Results for “agile,”

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.

SourceResearch connectionFrom yearThrough year

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

At least 469 records · Page 26

All sources NASA NTRS DOE OSTI

NASA NTRS2019

Principles from Two Small SRM-Based Launcher Design/Developments

Two solid rocket motor based launch vehicles are in design and development at MSFC, a 4-stage Earth-to-Orbit vehicle cube-satellite launcher, and the 2-stage Mars Ascent Vehicle for the Mars sample return mission. Trade studies that refined these designs have benefited from developments in understanding sensitivities and approximate modeling. The development and practice of that has demonstrated 3 principles: PRINCIPLE I: Identify mission-specific key design drivers — particularly interactions (and focus knowledge-development on those). PRINCIPLE II: Agility — don’t lock down your derived requirements early — keep trading, and characterizing sensitivities. PRINCIPLE III: Use multi-fidelity tools to improve “understanding value generated per modeling effort cost.” The designer should expect different design solution techniques to derive from different mission needs. This paper shows how two launch vehicle designs developed and adapted to those needs.

Kibbey, Timothy P.↗

NASA NTRS2020

An Overview of NASA’s Learn-to-Fly Technology Development

“Learn-to-Fly” (L2F) is an advanced technology development effort within the Modeling and Control for Agile Aircraft Development (MCAAD) group, a part of the NASA Transformative Aeronautics Concepts Program’s (TACP) Transformational Tools and Technologies (TTT) project. The goal of L2F is to develop technologies for enabling self-learning flight vehicles, using both ground- and flight-test approaches. Specifically, research has been conducted to demonstrate the potential to merge two enabling technologies, real-time aerodynamic modeling and adaptive flight controls, to substantially reduce the typical ground- and flight-testing time requirements for air vehicle design. This effort involved development of real-time, on-board algorithms to demonstrate key L2F technologies including aerodynamic modeling and control for an aircraft with minimal a priori knowledge. This research included both ground-based wind tunnel experiments utilizing modern design of experiments (DOE) techniques, as well as a flight test campaign, and was intended to rapidly advance these technologies and demonstrate key capabilities of the L2F approach. This paper presents the overview of the methods used to develop L2F technologies in NASA Langley Research Center’s 12-Foot Low Speed Tunnel, as well as in flight experiments. These methods include efficient wind tunnel data collection, real-time global nonlinear aerodynamic modeling in both the time and frequency domains, and the integration of the modeling techniques with adaptive flight controls, all of which were demonstrated using experimental validation.

Stephen E Riddick↗

NASA NTRSDate not supplied

Major Design Choices and Challenges that Enabled the Success of the Ejectable Data Recorder System

The Ejectable Data Recorder (EDR) subsystem was added to the Crew Module (CM) of the Ascent Abort 2 (AA-2) test flight due to a risk that the communications architecture would be insufficient to downlink all the data to the ground during the test flight. Since the EDR subsystem was a secondary system for data collection, AA-2 management enabled the team to take a different approach to hardware development that was more agile-like. This paper discusses key design decisions, technical challenges, and lessons learned that enabled the success of the EDR system during its flight on July 2, 2019.

Jeff Hagen↗

NASA NTRS2020

The High-Energy Emission from HD 93129A Near Periastron

We conducted an observational campaign towards one of the most massive and luminous colliding wind binaries in the Galaxy, HD 93129A, close to its periastron passage in 2018. During this time the source was predicted to be in its maximum of high-energy emission. Here we present our data analysis from the X-ray satellites Chandra and NuSTAR and the γ-ray satellite AGILE. High-energy emission coincident with HD 93129A was detected in the X-ray band up to 18 keV, whereas in the γ-ray band only upper limits were obtained. We interpret the derived fluxes using a non-thermal radiative model for the wind-collision region. We establish a conservative upper limit for the fraction of the wind kinetic power that is converted into relativistic electron acceleration, f(NT,e) < 0.02. In addition, we set a lower limit for the magnetic field in the wind-collision region as BWCR > 0.3 G. We also argue a putative interpretation of the emission from which we estimate f(NT,e) ≈ 0.006 and B(WCR) ≈ 0.5 G. We conclude that multi-wavelength, dedicated observing campaigns during carefully selected epochs are a powerful tool for characterising the relativistic particle content and magnetic field intensity in colliding wind binaries.

S del Palacio↗

NASA NTRSDate not supplied

Abrstract - OnePlace Redesign Spring 2020 Internship

The project I worked on was the OnePlace Redesign. In that, I converted the OnePlace home page to the Service Portal to match NASA OnePlace’s current application design standards, I was able to allow users to easily find applications in OnePlace and I was able to allow users to easily find and request OnePlace services (new app development, new knowledge base, etc.). It was a major accomplishment to be able to remodel a website that soon the entire Langley center that uses OnePlace will use. The website was made through ServiceNow’s Service Portal, and I organized the applications like never before, allowed a clear styling to applications a user does not have access to and/or are new applications, browsing of applications with clear button divisions, and allowing for different options depending if app is accessible or not, with proper error checking in place and very-well documented code. It was amazing to incorporate all this logic into one widget so that whoever wants to utilize this feature has no trouble at all to do so. The 3 most important things I learned were being able to do this work within ServiceNow, as it is such an important enterprise platform for CRM and boosting the connected workforce of NASA, incorporate built-in APIs from ServiceNow Glide Records to connect Server Scripts to Client Scripts and HTML, and be able to use agile to get another experience of managing work capacity with stories, and having proper communication with the team if every feature is done correctly and steps for continuing forward. The part that I enjoyed the most was the training I did for ServiceNow and I freedom I had to experiment to see how to structure the Service Portal. I was not tied down, and I believe this allowed for a better outcome of the product. As part of the internship, I created a very in-depth design document with the help of my team to document the project goals before it was started and technical documentation (including the design document) summarizing the final result of the product in terms of the new features added and the explanation of the logic thoroughly so that anyone can understand the project easily. The technical documentation will be published as a Knowledge Article within OnePlace Knowledge Base documentation.

Ariel Wald↗

NASA NTRSDate not supplied

A Concept of Operations (ConOps) of an In-time Aviation Safety Management System (IASMS) for Advanced Air Mobility (AAM)

The growth of new emerging operations involving Advanced Air Mobility (AAM) necessitates developing a perspective for an In-time Aviation Safety Management System (IASMS). This perspective advances from the National Academies report on IASMS and its recommendation for developing a Concept of Operations (ConOps) for IASMS. A ConOps has been developed for In-time System-Wide Safety Assurance (ISSA) from which the IASMS ConOps pivots to provide a robust scope commensurate with the broad vision defined by the National Academies. The IASMS ConOps focuses on emerging operations and spans innovations in Unmanned Aircraft System (UAS) and an increasingly complex ecosystem comprised of a widening mix of vehicles and technologies, Urban Air Mobility (UAM) with industry-federated services, traditional operations, as well as new supersonic aircraft and space launch systems.The challenge for the IASMS ConOps is to be broad to encompass innovations in the coming years and decades while agile to ensure levels of safety compatible with operational and certification requirements of the National Airspace System (NAS). The IASMS ConOps interweaves increasing complexity of operational safety capabilities and unlocking UAS Maturity Levels (UMLs). The relationships between increased complexity of automation and automated systems, fewer operators who are not as traditionally higher skilled, more complex operational environments, and aviation operations management with mixed aircraft and equipage pose a multi-dimensional space for IASMS capabilities essential for safety assurance and risk management. Instantiating IASMS capabilities and how they would be integral to AAM operations and increasing maturity of UAM could be accomplished through a series of Safety Demonstrators. These Safety Demonstrators could provide increased understanding and insight into use of controls for risk mitigation, means of compliance for certification, and operational experience with safety services such as in relation to contingency management. The IASMS capabilities can be viewed as initially residing with the vehicle, airspace, and Supplemental Data Service Provider (SDSP). For example, vehicle capabilities include communications including the command and control link, Remote Identification (ID), conflict advisory/alerting, and UAS system monitoring. These capabilities monitor and assess data such as battery health, aircraft state, and human performance. Complexity of ISAMS capabilities depends on a number of factors. These factors are intendedonly as a notional categorization with the purpose being to reflect the complexity of the AAM ecosystem that would drive up the complexity of ISSA capabilities including systems, sensors, models, standards, and controls. Factors could include the Vehicle Flight Management, Environment, Airspace, and Contingency Management. Each of these factors can be comprised of multiple sub-factors that contribute to increasing complexity. For example, Airspace at a lower level of complexity could be dedicated to UTM operations that are unmonitored, and at a higher level of complexity could involve mixed UTM and ATM operations. The IASMS concept includes safety services that provide data and information to different participants in AAM. The roles and responsibilities of participants can be defined using the Responsible-Accountable-Consulted-Informed (RACI) analysis. For example, for the safety service involving the Remote ID, the Operator would be accountable for providing the data, the Vehicle would be responsible for transmitting it, and the USS, SDSP, Vertiports, FIMS (FAA), and Public Entities such as safety services would be informed by receiving the data. The IASMS ConOps identifies the capabilities needed for risk mitigation and safety assurance in the increasingly complex national airspace. The ConOps serves as a pathway for engaging with industry to gain operational experience including through the Safety Demonstrator series, the RACI analysis, and operational complexity factors. The ConOps serves to integrate these different perspectives to build a cohesive and cogent approach to an AAM safety management system.

In-Time Aviation Safety Management System↗

NASA NTRSDate not supplied

NASA’s Advance Information Systems Technology (AIST) Program

NASA’s Earth Science Technology Office (ESTO) develops early-stage technologies to enhance scientific understanding. ESTO’s technologies can be reliably and confidently applied to a broad range of science measurements and missions, as well as facilitate practical applications to benefit society at large. As the lead technology office within the Earth Science Division of the NASA Science Mission Directorate, ESTO is focused on the technological challenges inherent to space-based investigations of our planet's dynamic, interrelated systems. Through flexible, science-driven technology strategies and a competitive selection process, ESTO-funded technologies have supported numerous Earth science missions as well as commercial applications. From next generation sensors and instruments to communication and information systems, ESTO technologies enable many NASA missions and data services. The Advanced Information Systems Technology (AIST) Program is one focal area of ESTO. AIST innovates information system technologies that enable the development of new observing systems as well as agile science investigations through data analytics and artificial intelligence tools and algorithms. AIST utilizes an end-to-end development approach with the goal of infusing mature technologies into future missions, measurements, and analysis. One thrust of AIST is data exploitation and analysis using an analytic center framework to make observational data and model output more accessible and usable to scientists conducting specific investigations as well as to extract higher-level science content and information from the data. The framework accelerates scientific discovery by harmonizing the data, tools, and computational resources. NASA’s upcoming Surface, Biology and Geology (SBG) mission is one such mission whose data architecture will leverage many of the technologies developed through the AIST program. This talk will highlight current and future program development goals.

Laura Rogers↗

NASA NTRSDate not supplied

Splashdown Visualization of Spent Stages

The state of the art for many Earth-to-orbit trajectory analysis toolsets used at NASA is somewhat dated in terms of the languages they are written in and their user interfaces. Many of these programs are written in languages like Fortran or C that are no longer considered modern in the technology industry, and are command-line based without any means of interpreting the data outputs. This presentation is meant to demonstrate a specific use case for a newly developed web app that visualizes the output data for one of these tools. Specifically, one key usage is to investigate and validate launches for notional multi-stage vehicle concepts to various non-standard high-inclination orbits. Some NASA requirements dictate that trajectories be designed such that no surviving debris lands closer than 200 nautical miles (nm) from foreign landmasses or 27 nm from the continental United States, therefore validating re-entry locations of spent stages is an integral part of the launch planning process. In addition, at programmatic levels it can prove insightful and clarifying for the decision-making process to enhance the technical results of numerical simulations with visualizations. The intent with this tool is to provide the mission analyst and program level management with an intuitive and clear grasp of key information on possible mission scenarios either departing from or arriving at Earth, and in the future, the moon or Mars as well. The software tool was developed with an agile development approach and utilizes the latest frameworks and technologies. The front end uses the React JavaScript library for making a state of the art frontend and a backend based on the Django Python framework for handling data using Python’s powerful and free scientific libraries. In addition, the CesiumJS open-source library is key for visualizing these end-to-end trajectories on a high-resolution Earth model. The presentation will demonstrate the current capability and tested use cases.

Jack Agolli↗

NASA NTRSDate not supplied

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗

NASA NTRSDate not supplied

Demonstration of a Modular, Scalable, Laser Communication Terminal for Manned Spaceflight Missions

Free-space laser communication systems are increasingly implemented on state of the art satellites for their high-speed connectivity. This work outlines the design, analysis and test of the Modular, Agile, Scalable Optical Terminal (MAScOT) we have developed to support Low-Earth Orbit (LEO) to deep-space communication links. In LEO, the MAScOT will be implemented on the International Space Station to support the Integrated Laser Communications Relay Demonstration (LCRD) LEO User Modem and Amplifier Terminal (ILLUMA-T) program. ILLUMA-T’s overarching objective is to demonstrate high bandwidth data transfer between LEO and a ground station via a geosynchronous (GEO) relay satellite. Outside of GEO, MAScOT will also be implemented on the Artemis-II mission to demonstrate high data rate optical communications to and from the moon as part of the Orion EM-2 Optical Communications (O2O) program. Both missions leverage the same modular architecture despite varying structural, thermal, and optical requirements. To achieve sufficient performance, the optical terminal relies on a coarse/fine nested tracking loop to realize sub-arcsecond pointing across +/- 120 deg elevation and +/- 175 deg azimuth field of regard. An integrated analysis of the MAScOT in support of both missions will be outlined in addition to scalable versions of this terminal for future missions.

Steven R. Gillmer↗

NASA NTRS2006

A compact 600 GHz electronically tunable vector measurement system for submillimeter wave imaging

A compact submillimeter wave transmission/reflection measurement system has been demonstrated at 560-635 GHz, with electronic tuning over the entire band. Maximum dynamic range measured at a single frequency is 100 dB (60 dB typical), and typical phase noise is less than +/- 1°. By using a frequency steerable lens at the source output and mixer input, the frequency agility of the system can be used to scan the source and receive beams, resulting in near realtime imaging capability using only a single pixel

Siegel, Peter H.↗

NASA NTRS2013

Towards a decision support system for space flight operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The differences between the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the four increments of this vision. These increments include (1) the existing capabilities (2) hardware and software system components and interfaces with the NASA ground system, (3) uncertainty management and (4) re-planning and automated execution. Each of these increments provides value independently; but some may also enable building of a subsequent increment.

Ruszkowski, James↗

NASA NTRS2012

Driving ATHLETE: analysis of operational efficiency

The All-Terrain Hex-Limbed Extra-Terrestrial Explorer (ATHLETE) is a modular mobility and manipulation platform being developed to support NASA operations in a variety of missions, including exploration of planetary surfaces. The agile system consists of a symmetrical arrangement of six limbs, each with seven articulated degrees of freedom and a powered wheel. This design enables transport of bulky payloads over a wide range of terrain and is envisioned as a tool to mobilize habitats, power-generation equipment, and other supplies for long-range exploration and outpost construction. In FY2010, ATHLETE traversed more than 80 km in field environments over eight weeks of testing, demonstrating that the concept is well suited to long-range travel. Although ATHLETE is designed to travel at speeds of up to 5 kilometers per hour, the observed average traverse rate during field-testing rarely exceeded 1.5 kilometers per hour. This paper investigates sources of inefficiency in ATHLETE traverse operations and identifies targets for improvement of overall traverse rate.

Mittman, David↗

NASA NTRS2017

SmallSat Navigation via the Deep Space Network: Lunar Transport

Spacecraft component miniaturization, the standardized CubeSat form factor, and a corresponding increase in launch ride-share availability have led to a renewed interest in smaller, more agile spacecraft missions. Naturally, interest in SmallSat capabilities extends outside of low Earth orbit for a variety of science and technology demonstration applications. As with larger missions, near-term deep-space SmallSats will more than likely rely on telecommunications and tracking via NASA's Deep Space Network or similar facilities. Given the predicted growth in the number of deep space missions, e ective use of telecommunication resources will be more critical than ever, even with Multiple Spacecraft Per Aperture capability. In particular, SmallSat missions will likely face stricter limitations on two-way contact with the tracking stations, thus making other options like one-way data types more attractive. While all missions must eventually develop their own detailed navigation plans, a common set of references is needed to support SmallSat missions, especially in the early development phases. Our investigation provides this initial survey of expected navigation performance for standard radiometric data types, from traditional two-way Doppler and ranging capabilities to one-way equivalents, including delta-di erential one-way range. In this investigation, we examine transport within the Earth-Moon region, the rst step outward from Earth into deep space exploration.

Wood, Lincoln↗

NASA NTRS2018

A Low SWaP-C prototype Ka-band Frequency Synthesizer for Atomic Clocks

We present a low size, weight, power and cost (SWaP-C) prototype circuit of a Ka-band frequency synthesizer. It takes advantage of a phase-locked loop single integrated circuit (IC) and harmonic generation with high speed CMOS gates. We use a direct digital synthesizer (DDS) IC to tune the final output with microHertz resolution. An ultra-low-power micro controller that could serve as the clock controller is used to control the PLL and the DDS. All components are commercial off the shelf (COTS) with acceptable industrial support. The total power consumption is about 1.6 Watt with -45 dBm useful output at 40.507347996 GHz. The short-term instability introduced by the prototype is 7.3E-14 at 1s. The prototyped subsystem uses COTS demonstration boards for the sake of agile prototyping. There is still significant margin for improvement of the size and weight.

Tjoelker, Robert L.↗

NASA NTRSDate not supplied

SAGE III/ISS Rapid Data Analysis Through Dashboarding with Jupyter Notebooks

Spaceborne remote sensing observations of Earth’s atmosphere produce significant quantities of data over the life of each mission. In the case of the Stratospheric Aerosol and Gas Experiment III on the International Space Station (SAGE III/ISS) nearly four years of vertical profiles of atmospheric ozone, water vapor, and nitrogen dioxide concentrations as well as aerosol extinction coefficients have been released. The dichotomy of the desire for both long-term trends in the atmospheric state alongside the assessment of short-term impacts of major disruptive events such as volcanic eruptions and pyrocumulus injections requires agile tools to handle these cases in near real-time as new data are produced. The analysis landscape is further complicated by the desire to compare results between the numerous contemporary observations available for a given dataset. The SAGE III/ISS team has developed a suite of tools leveraging modern web-based frameworks allowing members to interact with a dashboard-style interface to load the data record, assess new profiles as they are generated and in ensemble, compare between species, and additionally add in measurements observed by other platforms as necessary. Leveraging a commonly packaged data format of NetCDF alongside the Python Jupyter Notebook framework, the data can be served to interested parties from an analysis server while still runnable on personal systems if required. This presentation illustrates the ecosystem developed by the SAGE III/ISS team, the applicability to measurements made by any limb-observing platform, and the benefit to transforming routine analyses into readily accessible dynamic plots. Frameworks currently exist at larger scales with projects such as GIOVANNI, and this illustration seeks to show that similar frameworks are accessible and possible within the local research environment while simultaneously unloading human processing cycles for more specialized analysis tasks.

Dashboarding↗

NASA NTRSDate not supplied

An Expanded Role for Python in Expediting System Simulation Development

The Python programming language has traditionally been used as a “scripting” language and is not generally recognized as a language for building system simulations, where C++, Java, and other compiled languages are typically used. While very powerful and gaining favor for a large set of programming tasks, Python is generally regarded as not having the speed to directly do the extensive numeric computations required in large-scale simulation. This paper aims to present an approach, supported by case studies, to re-think this assertion. Directly using Python in this new role has the potential to expedite an agile, spiral cycle of development of design-test-modify for systems simulation.

programming language↗

NASA NTRSDate not supplied

A Model-Based Systems Engineering Journey to Developing a Concept of Operations

Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.

Jeffrey Robert Cohen↗