Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software asset”

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 91 records · Page 5

Large Load Impacts to Distribution System Hosting Capacity

This work examined the impact of large loads on utility distribution system models using the Sandia-developed open-source software DREAMS. It was shown that hosting capacity varies with location and changes after any asset is added to, or removed from, a system. Despite the tested models having similar rated voltages and other characteristics, their thermal and voltage constrained hosting capacity varied over 2 MW. The addition of a 3-phase balanced constant power large load with power factor of 1.0 exhibited non-linear reductions to all voltage constrained hosting capacities. The reductions to thermal constrained hosting capacity from a load with similar characteristics was more linear, related to the size of the added load, and did not impact all model buses. Co-located capacitors were shown to accommodate demand that was beyond the baseline voltage constrained hosting capacity limits, however, the costs and benefits from this approach were found to not be 1:1 and required additional available thermal capacity.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Introduction to mission data system

MDS state-based architecture. A system compromises project assets in the context of some external environments that influences them. The function of mission software is to monitor and control a system to meet operators' intents.

MDS mission data system↗

Multi-Purpose Crew Vehicle Camera Asset Planning: Imagery Previsualization

Using JSC-developed and other industry-standard off-the-shelf 3D modeling, animation, and rendering software packages, the Image Science Analysis Group (ISAG) supports Orion Project imagery planning efforts through dynamic 3D simulation and realistic previsualization of ground-, vehicle-, and air-based camera output.

Beaulieu, K.↗

How to Extend the Capabilities of Space Systems for Long Duration Space Exploration Systems

For sustainable Exploration Missions the need exists to assemble systems-of-systems in space, on the Moon or on other planetary surfaces. To fulfill this need new and innovative system architectures must be developed to be modularized and launched with the present lift capability of existing rocket technology. To enable long duration missions with minimal redundancy and mass, system software and hardware must be reconfigurable. This will enable increased functionality and multiple use of launched assets while providing the capability to quickly overcome components failures. Additional required capability includes the ability to dynamically demate and reassemble individual system elements during a mission in order to recover from failed hardware or to adapt to changes in mission requirements. To meet the Space Exploration goals of Interoperability and Reconfigurability, many challenges must be addressed to transform the traditional static avionics architectures into architectures with dynamic capabilities. The objective of this paper is to introduce concepts associated with reconfigurable computer systems; to review the various needs and challenges associated with reconfigurable avionics space systems; to provide an operational example that illustrates the application to both the Crew Exploration Vehicle and a collection of 'Habot-like' mobile surface elements; to summarize the approaches that address key challenges to the acceptance of a Flexible, Intelligent, Modular, Affordable and Reconfigurable avionics space system.

space assembly↗

Autonomous Coordination of Science Observations Using Multiple Spacecraft

This software provides capabilities for autonomous cross-cueing and coordinated observations between multiple orbital and landed assets. Previous work has been done in re-tasking a single Earth orbiter or a Mars rover in response to that craft detecting a science event. This work enables multiple spacecraft to communicate (over a network designed for deep-space communications) and autonomously coordinate the characterization of such a science event. This work investigates a new paradigm of space science campaigns where opportunistic science observations are autonomously coordinated among multiple spacecraft. In this paradigm, opportunistic science detections can be cued by multiple assets where a second asset is requested to take additional observations characterizing the identified surface feature or event. To support this new paradigm, an autonomous science system for multiple spacecraft assets was integrated with the Interplanetary Network DTN (Delay Tolerant Network) to provide communication between spacecraft assets. This technology enables new mission concepts that are not feasible with current technology. The ability to rapidly coordinate activities across spacecraft without requiring ground in the loop enables rapid reaction to dynamic events across platforms, such as a survey instrument followed by a targeted high resolution instrument, as well as regular simultaneous observations.

Estlin, Tara A.↗

Evaluation of Droplet Splashing Algorithm in LEWICE 3.0

The Icing Branch at NASA Glenn Research has developed a computer program to simulate ice formation on the leading edge of an aircraft wing during flight through cold, moist air. As part of the branch's current research, members have developed software known as LEWICE. This program is capable of predicting the formation of ice under designated weather conditions. The success of LEWICE is an asset to airplane manufacturers, ice protection system manufacturers, and the airline industry. Simulations of ice formation conducted in the tunnel and in flight is costly and time consuming. However, the danger of in-flight icing continues to be a concern for both commercial and military pilots. The LEWICE software is a step towards inexpensive and time efficient prediction of ice collection. In the most recent version of the program, LEWICE contains an algorithm for droplet splashing. Droplet splashing is a natural occurrence that causes accumulation of ice on aircraft surfaces. At impingement water droplets lose a portion of their mass to splashing. With part of each droplet joining the airflow and failing to freeze, early versions of LEWICE without the splashing algorithm over-predicted the collection of ice on the leading edge. The objective of my project was to determine whether the revised version of LEWICE accurately reflected the ice collection data obtained from the Icing Research Tunnel (IRT). The experimental data from the IRT was collected by Mark Potapczuk in January, March and July of 2001 and April and December of 2002. Experimental data points were the result of ice tracings conducted shortly after testing in the tunnel. Run sheets, which included a record of velocity, temperature, liquid water content and droplet diameter, served as the input of the LEWICE computer program. Parameters identical to the tunnel conditions were used to run LEWICE 2.0 and LEWICE 3.0. The results from IRT and versions of LEWICE were compared graphically. After entering the raw experimental data and computer output into a spread sheet, I mapped each ice formation onto a clean airfoil. The LEWICE output provided the data points to graphically depict ice formations developed by the program. weather conditions of runs conducted in January 2001, it was evident that the splashing algorithm of LEWICE 3.0 predicts ice formations more accurately than LEWICE 2.0. Especially at conditions with droplet size between 80 and 160 microns, the splashing algorithm of the new LEWICE version compensated for the loss of droplet mass as a result of splashing. In contrast, LEWICE 2.0 consistently over-predicted the mass of the ice in conditions with droplet size exceeding 80 microns. This evidence confirms that changes made to algorithms of LEWICE 3.0 have increased the accuracy of predicting ice collection.

Homenko, Hilary N.↗

An Integrated Software Architecture for Solar Cruiser Mission Design and Navigation

Solar Cruiser is a solar sailing mission, riding as a secondary payload to the Interstellar Mapping and Acceleration Probe (IMAP) mission, expected to launch in February of 2025. The Solar Cruiser vehicle will generate thrust via a complex, low-thrust solar sail. The extreme low-thrust nature of the solar sail will leave Solar Cruiser highly sensitive to external environmental effects (such as solar radiation pressure and high-order gravitational perturbations) throughout the entirety of flight. Because of this, preliminary & operational optimization routines must be intricately tied to high-order predictive propagation models to ensure the greatest possible confidence in mission success. The Solar Cruiser Mission Design and Navigation (MDNav) team has designed a software tool suite, employing the latest in software containerization technology, to accomplish this task, allowing for seamless development across several users and operating systems. Combining JPL’s Monte toolkit with University of Alabama’s high-performance optimizer, ASSET, the proposed architecture allows for instant verification of optimized trajectories within the same development environment that the optimization takes place, removing the need for mission designers and navigators to switch between tools. The MDNav software suite itself is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile – thus avoiding unnecessary file bloating. This paper discusses the historical differences between previous iterations of the Solar Cruiser MDNav tool suite and the current iteration, planned operational interfaces of the tool with other software and subsystems, and the planned path forward in maintaining containerization services for the software throughout the lifetime of Solar Cruiser.

solar cruiser↗

Jettison Engineering Trajectory Tool

The Jettison Engineering Trajectory Tool (JETT) performs the jettison analysis function for any orbiting asset. It provides a method to compute the relative trajectories between an orbiting asset and any jettisoned item (intentional or unintentional) or sublimating particles generated by fluid dumps to assess whether an object is safe to jettison, or if there is a risk with an item that was inadvertently lost overboard. The main concern is the interaction and possible recontact of the jettisoned object with an asset. This supports the analysis that jettisoned items will safely clear the vehicle, ensuring no collisions. The software will reduce the jettison analysis task from one that could take days to complete to one that can be completed in hours, with an analysis that is more comprehensive than the previous method. It provides the ability to define the jettison operation relative to International Space Station (ISS) structure, and provides 2D and 3D plotting capability to allow an analyst to perform a subjective clearance assessment with ISS structures. The developers followed the SMP to create the code and all supporting documentation. The code makes extensive use of the object-oriented format of Java and, in addition, the Model-View-Controller architecture was used in the organization of the code, allowing each piece to be independent of updates to the other pieces. The model category is for maintaining data entered by the user and generated by the analysis. The view category provides capabilities for data entry and displaying all or a portion of the analysis data in tabular, 2D, and 3D representation. The controller category allows for handling events that affect the model or view(s). The JETT utilizes orbital mechanics with complex algorithms. Since JETT is written in JAVA, it is essentially platform-independent.

Zaczek, Mariusz↗

The Utilization Profiles of the CCSDS Unified Space Link Protocol (USLP)

The purpose of this paper is to identify the utilization profiles for interfacing the Data Protocol Sublayer using the Unified Space Link Protocols (USLP) (reference 1) with the space link coding procedures as specified in the CCSDS Coding & Synchronization Blue Books (references 2 through 5), used in both telecommand and telemetry applications. This paper describes how the USLP Protocol utilizes the coding and synchronization sublayer to support: a. Direct to Earth (DTE) telemetry links for engineering and science data b. Direct to Earth (DTE) telemetry links for very high rate science data c. Direct from Earth (DFE) command, sequencing and flight software loads d. Space to Space Links (Proximity) utilized by orbiters for data exchange to/from surface bound assets. The CCSDS has divided the functions of the Data Link Layer into two sublayers: the Data Link Protocol Sublayer (DLP-SL) and the Coding and Synchronization Sublayer (CS-SL). The Data Link Protocol Sublayer (DLP-SL) interfaces to the users, accepting the data that is to be transported, on the sending side of the link, and delivering that data on the receiving end. The Transfer Frame is the data unit that is transferred across the Data Link Protocol Sublayer and the Coding and Synchronization Sublayer boundary. The Coding and Synchronization Sublayer (CS-SL) provides the encoding, randomization, and frame synchronization functions that prepares the USLP Transfer Frame for transport across the space link. The CS-SL is divided into 2 processes: 1) The Frame Interface Processes (FIP) performs the interface functions required to prepare the data for delivery to the Coding/Decoding Process (CDP). This process includes prepending a Frame Start Marker to the provided frame, when management has designated that the frame is not to be aligned to the codeblock or when there is no block code used. 2) The Coding/Decoding Process (CDP) performs the forward error correction processes that are used to optimize the performance of the link and minimize the error rate. The CDP creates the symbol stream that is delivered to the Physical Layer. The transfer of the USLP transfer frames across different types of space links is the focus of this paper. The Protocol Data Unit (PDU) that is passed in both directions between the Data Link Protocol Sublayer (DLP-SL) and Coding and Synchronization Sublayer (CS-SL) is the transfer frame. The USLP frame structure provides flexibility that can be constrained by the functions utilized within the CS-SL that prepare the transfer frame for transit. For example, the USLP transfer frame contains a length field that enables the frame to be of variable length but CS-SL under certain conditions may constrain the frame to be fixed in length. This paper describes 5 operational modes available for use by the Data Link Layer to provide data exchange across the USLP space link. These modes are different because different operational requirements apply to vastly different types of space links and thus the communications implementation requirements differ. The environmental issues include the power or energy available, the distance between the end points of the link, the complexity of the equipment available at those end points, the atmospheric conditions and radiometric frequency selection. The CS-SL utilizes different forward error correcting codes supported by specific operational modes to configure the data for transit. This paper describes all of the operational modes in a series of data models which decompose the functionality between the Data Link Protocol Sublayer and the Coding and Synchronization sublayer. The operational modes described are: 1. Uncoded Mode: has been used for short links that contain significant available power to provide an acceptable frame error rate. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 2. Convolutional Only Mode: is currently the prime forward error correction coding used for the proximity links. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 3. Variable Length Frame Aligned to Variable Length Codeblock (TC): is used for Direct from Earth links were power levels are high and the simple, least complex code i.e., the BCH code is used. This mode has been in use since the early 1970s. The BCH code is a short code and the decoder is easy to implement. 4. Fixed Length Frame Aligned to Fixed Length Codeblock (AOS/TM): was introduced when the concatenated Convolutional and Reed-Solomon Code was formulated to provide significant reduction in link data error rate and the ability to determine if there was an error in the decoded codeblock. The frame is aligned to the codeblock so that there is a one to one relationship of frame errors to codeblock errors without additional error detection coding being added. This mode requires the protocol frames to be the exact size of the message portion of the codeblock. 5. Frames Unaligned to Fixed Length Codeblocks (Currently used for very high rates and space to space links): This mode is currently used for missions that have a very high data rate that can be controlled adaptively as the environment changes and as the next generation operating mode for the proximity link. This mode from a coded data stream point of view is exactly like that described in 4. above, except that the frame need not be aligned to the codeblock. There is no requirement on frame length when using this mode. Thus when using USLP it can be used to support links that require short or long frames. There is also no mandatory requirement that frames cannot be separated by idle data reducing the tight data rate connection requirements between the data link protocol sublayer and the coding & synchronization sublayer. In conclusion, how these operational modes can be put to use in mission operational scenarios is described for Direct from Earth links (DFE), Direct to Earth links (DTE), and Proximity links.

Greenberg, E.↗

Supporting Exploration Missions by Enabling Exploration Mission System Software

Future exploration missions will consist of a multitude of data sources, systems, and operators collaborating to complete mission objectives. Presently, NASA is instantiating the contractual mechanisms, such as the xEVAS and HLS contracts, to produce these mission assets. Architectural planning is also underway to establish the networking protocols and infrastructure to digitally create and connect mission elements, such as LunaNET. However, without new horizontally integrated data systems, these advancements will be limited in their ability to get mission data appropriately integrated into the plan, train, fly, explore workflow of the operations workforce. Here we describe several mission system software development efforts underway that are designed to support human spaceflight missions. We describe the current iterations of a suite of tools to support EVA procedure authoring and execution, for both ISS and Artemis missions, as well as a software solution to establish and interact with mission context and data products. These tools have been developed iteratively and continue to be tested in several NASA facilities such as the Neutral Buoyancy Lab (NBL), Artemis field testing, and in present-day International Space Station (ISS) operations on orbit. Our solutions demonstrate how software development can be aligned with ongoing operations development activities to discover the features that best support future human spaceflight missions.

EVA Mission System Software↗

Ring Image Analyzer

Ring Image Analyzer software analyzes images to recognize elliptical patterns. It determines the ellipse parameters (axes ratio, centroid coordinate, tilt angle). The program attempts to recognize elliptical fringes (e.g., Newton Rings) on a photograph and determine their centroid position, the short-to-long-axis ratio, and the angle of rotation of the long axis relative to the horizontal direction on the photograph. These capabilities are important in interferometric imaging and control of surfaces. In particular, this program has been developed and applied for determining the rim shape of precision-machined optical whispering gallery mode resonators. The program relies on a unique image recognition algorithm aimed at recognizing elliptical shapes, but can be easily adapted to other geometric shapes. It is robust against non-elliptical details of the image and against noise. Interferometric analysis of precision-machined surfaces remains an important technological instrument in hardware development and quality analysis. This software automates and increases the accuracy of this technique. The software has been developed for the needs of an R&TD-funded project and has become an important asset for the future research proposal to NASA as well as other agencies.

Strekalov, Dmitry V.↗

Supporting Exploration Missions by Enabling Exploration Mission System Software

Future exploration missions will consist of a multitude of data sources, systems, and operators collaborating to complete mission objectives. Presently, NASA is instantiating the contractual mechanisms, such as the Exploration Extravehicular Activity Services (xEVAS) and Human Landing System (HLS) contracts, to produce these mission assets. Architectural planning is also underway to establish the networking protocols and infrastructure to digitally create and connect mission elements, such as LunaNET. However, without new horizontally integrated data systems, these advancements will be limited in their ability to get mission data appropriately integrated into the plan, train, fly, explore workflow of the flight operations workforce. Here we describe several mission system software development efforts underway that are designed to support human spaceflight missions. This paper describes the current iterations of a suite of tools to support EVA procedure authoring and execution, and mission context creation for both International Space Station (ISS) and Artemis missions. These tools have been developed iteratively and continue to be used in present-day ISS operations on orbit and in several NASA facilities such as the Neutral Buoyancy Lab (NBL) and Artemis field testing. These solutions demonstrate how software development can be aligned with ongoing operations development activities to discover the features that best support both current and future human spaceflight missions.

Matthew J. Miller↗

Supporting Exploration Missions by Enabling Exploration Mission System Software

Future exploration missions will consist of a multitude of data sources, systems, and operators collaborating to complete mission objectives. Presently, NASA is instantiating the contractual mechanisms, such as the Exploration Extravehicular Activity Services (xEVAS) and Human Landing System (HLS) contracts, to produce these mission assets. Architectural planning is also underway to establish the networking protocols and infrastructure to digitally create and connect mission elements, such as LunaNET. However, without new horizontally integrated data systems, these advancements will be limited in their ability to get mission data appropriately integrated into the plan, train, fly, explore workflow of the flight operations workforce. Here we describe several mission system software development efforts underway that are designed to support human spaceflight missions. This paper describes the current iterations of a suite of tools to support EVA procedure authoring and execution, and mission context creation for both International Space Station (ISS) and Artemis missions. These tools have been developed iteratively and continue to be used in present-day ISS operations on orbit and in several NASA facilities such as the Neutral Buoyancy Lab (NBL) and Artemis field testing. These solutions demonstrate how software development can be aligned with ongoing operations development activities to discover the features that best support both current and future human spaceflight missions.

Matthew Miller↗

Low SWaP Onboard Satellite Navigation, Guidance, and Control Technology

Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The first build of autoNGC, providing autonomous navigation for lunar orbiting spacecraft, is targeted for completion by Fall 2024. It provides sensor fusion of multiple measurement types including pseudo-range from a weak signal Global Navigation Satellite Service (GNSS) receiver, 1-way and 2-way direct to Earth (DTE) range and Doppler, bearing and range from optical camera sensed images, and an accelerometer. AutoNGC is also being targeted for future missions that involve small body proximity operations, Sun Earth Libration point orbits, and distributed systems missions (DSMs) including those at outer planets. AutoNGC flight software is being built upon the plug-and-play architecture of the core Flight System (cFS) [Ref. 1]. Figure (Slide 7) shows the message-based software bus layout of various software applications (“apps”) consisting of the standard cFS apps and autoNGC interface apps and libraries. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library [Ref. 2], which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are provided by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app [Ref. 3]. This app processes optical images to extract the bearing angles of the centroid of the imaged body (near or far), the range to the imaged body, and/or of the features on the surface of a body to perform terrain relative navigation (TRN). Measurement of range to the body’s center of mass can also be derived from the detection of the limb. The first build of autoNGC for a lunar orbiting spacecraft is a minimal size, weight, and power (SWaP) hardware design allowing for inclusion into CubeSats and SmallSat-size class buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z [Ref. 4] are utilized for low SWaP while maintaining a high level of performance. Figure (Slide 11) shows the composition of the first autoNGC build. The current enclosure design has dimensions 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. The hardware interfaces are designed for flexibility with a variety of sensor inputs. The achievable navigation performance depends on the sensors utilized, including the onboard clock for 1-way pseudo-range measurements. Analysis using a configuration that consists of weak signal GPS, TRN, and 1-way DTE has shown position and velocity accuracies of 10 meters and 2 cm/s (3-σ ) RSS, respectively, with onboard time knowledge estimated to better than 13 ns (3-σ ), for a spacecraft in a representative 12-hour eccentric lunar orbit. Other measurement types such as x-rays from known pulsars (called XNAV) and cross-links can also be processed in GEONS. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced, even after launch. Goddard is actively seeking partners to collaborate in the development of additional capabilities for autoNGC, including industry, academia, and others across the US Government. Plans are being formulated to make the autoNGC software platform available for use by any US government organization to leverage the non-recurring engineering associated with the development of onboard autonomous NGC 3 capabilities. As advancements in space qualified sensors, microprocessors, and algorithms are made, the autoNGC platform provides a ready starting point for inclusion of these technologies.

C. J. Gramling↗

The Standard Autonomous File Server, a Customized, Off-the-Shelf Success Story

The Standard Autonomous File Server (SAFS), which includes both off-the-shelf hardware and software, uses an improved automated file transfer process to provide a quicker, more reliable, prioritized file distribution for customers of near real-time data without interfering with the assets involved in the acquisition and processing of the data. It operates as a stand-alone solution, monitoring itself, and providing an automated fail-over process to enhance reliability. This paper will describe the unique problems and lessons learned both during the COTS selection and integration into SAFS, and the system's first year of operation in support of NASA's satellite ground network. COTS was the key factor in allowing the two-person development team to deploy systems in less than a year, meeting the required launch schedule. The SAFS system his been so successful, it is becoming a NASA standard resource, leading to its nomination for NASA's Software or the Year Award in 1999.

Semancik, Susan K.↗

T3CO (Transportation Technology Total Cost of Ownership) Open Source [SWR-21-54]

T3CO (Transportation Technology Total Cost of Ownership), is open source software for modeling total cost of ownership for commercial vehicles with advanced powertrains. T3CO is a modeling framework for determining geospatially and temporally optimized total cost of ownership (TCO) for vehicle powertrain technologies. T3CO runs NREL's FASTSim™ software for a representative set of operating conditions to minimize TCO based on vehicle parameters that affect purchase and operating costs (e.g., fuel/electricity consumption, asset depreciation, opportunity costs associated with charging time) while simultaneously ensuring that firm performance constraints (e.g. zero-to-sixty time, gradeability) are satisfied. T3CO will enable the user to control which powertrain parameters are used in optimizing TCO, and these parameters will be modified by a multi-objective optimization (MOO) algorithm to identify a Pareto-optimal solution set. The optimization algorithm will be modular so that users can choose from many different MOO options or insert their own user-defined optimization tool. NREL T3CO Homepage: https://www.nrel.gov/transportation/t3co.html PyPI package: https://pypi.org/project/t3co/

Lustbader, Jason↗

Development of Hierarchical Control for a Lunar Habitat DC Microgrid Model Using Power Hardware-in-the-Loop

As interest in space exploration grows, developing a lunar habitat has become a key component of extending missions into deep space. To guarantee reliable power management of a habitat’s DC microgrid, control schemes are needed that can manage the different assets (batteries, photovoltaics, loads) effectively. Proposed hierarchical control schemes are further developed into hardware solutions using Opal-RT’s real-time simulation software and Power Hardware-in-the-Loop platform. Experimental results of a simulated DC microgrid and physical DC/DC components can allow better realization and performance of applications such as battery discharge control.

PHIL↗

Towards Automated Assessment of Vulnerability Exposures in Security Operations

Current approaches for risk analysis of software vulnerabilities using manual assessment and numeric scoring do not complete fast enough to keep pace with the maintenance work rate to patch and mitigate the vulnerabilities. This paper proposes a new approach to modeling software vulnerability risk in the context of the network environment and firewall configuration. In the approach, vulnerability features are automatically matched up with networking, target asset, and adversary features to determine whether adversaries can exploit a vulnerability. The ability of adversaries to reach a vulnerability is modeled by automatically identifying the network services associated with vulnerabilities through a pipeline of machine learning and natural language processing and automatically analyzing network reachability. Our results show that the pipeline can identify network services accurately. We also find that only a small number of vulnerabilities pose real risks to a system. However, if left unmitigated, adversarial reach to vulnerabilities may extend to nullify the effect of firewall countermeasures.

Huff, Philip↗