Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “gui”

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 217 records · Page 12

Use of Generalized Fluid System Simulation Program (GFSSP) for Teaching and Performing Senior Design Projects at the Educational Institutions

This paper describes the experience of the authors in using the Generalized Fluid System Simulation Program (GFSSP) in teaching Design of Thermal Systems class at University of Alabama in Huntsville. GFSSP is a finite volume based thermo-fluid system network analysis code, developed at NASA/Marshall Space Flight Center, and is extensively used in NASA, Department of Defense, and aerospace industries for propulsion system design, analysis, and performance evaluation. The educational version of GFSSP is freely available to all US higher education institutions. The main purpose of the paper is to illustrate the utilization of this user-friendly code for the thermal systems design and fluid engineering courses and to encourage the instructors to utilize the code for the class assignments as well as senior design projects. The need for a generalized computer program for thermofluid analysis in a flow network has been felt for a long time in aerospace industries. Designers of thermofluid systems often need to know pressures, temperatures, flow rates, concentrations, and heat transfer rates at different parts of a flow circuit for steady state or transient conditions. Such applications occur in propulsion systems for tank pressurization, internal flow analysis of rocket engine turbopumps, chilldown of cryogenic tanks and transfer lines, and many other applications of gas-liquid systems involving fluid transients and conjugate heat and mass transfer. Computer resource requirements to perform time-dependent, three-dimensional Navier-Stokes computational fluid dynamic (CFD) analysis of such systems are prohibitive and therefore are not practical. Available commercial codes are generally suitable for steady state, single-phase incompressible flow. Because of the proprietary nature of such codes, it is not possible to extend their capability to satisfy the above-mentioned needs. Therefore, the Generalized Fluid System Simulation Program (GFSSP1) has been developed at NASA Marshall Space Flight Center (MSFC) as a general fluid flow system solver capable of handling phase changes, compressibility, mixture thermodynamics and transient operations. It also includes the capability to model external body forces such as gravity and centrifugal effects in a complex flow network. The objectives of GFSSP development are: a) to develop a robust and efficient numerical algorithm to solve a system of equations describing a flow network containing phase changes, mixing, and rotation; and b) to implement the algorithm in a structured, easy-to-use computer program. The analysis of thermofluid dynamics in a complex network requires resolution of the system into fluid nodes and branches, and solid nodes and conductors as shown in Figure 1. Figure 1 shows a schematic and GFSSP flow circuit of a counter-flow heat exchanger. Hot nitrogen gas is flowing through a pipe, colder nitrogen is flowing counter to the hot stream in the annulus pipe and heat transfer occurs through metal tubes. The problem considered is to calculate flowrates and temperature distributions in both streams. GFSSP has a unique data structure, as shown in Figure 2, that allows constructing all possible arrangements of a flow network with no limit on the number of elements. The elements of a flow network are boundary nodes where pressure and temperature are specified, internal nodes where pressure and temperature are calculated, and branches where flowrates are calculated. For conjugate heat transfer problems, there are three additional elements: solid node, ambient node, and conductor. The solid and fluid nodes are connected with solid-fluid conductors. GFSSP solves the conservation equations of mass and energy, and equation of state in internal nodes to calculate pressure, temperature and resident mass. The momentum conservation equation is solved in branches to calculate flowrate. It also solves for energy conservation equations to calculate temperatures of solid nodes. The equations are coupled and nonlinear; therefore, they are solved by an iterative numerical scheme. GFSSP employs a unique numerical scheme known as simultaneous adjustment with successive substitution (SASS), which is a combination of Newton-Raphson and successive substitution methods. The mass and momentum conservation equations and the equation of state are solved by the Newton-Raphson method while the conservation of energy and species are solved by the successive substitution method. GFSSP is linked with two thermodynamic property programs, GASP2 and WASP3 and GASPAK4, that provide thermodynamic and thermophysical properties of selected fluids. Both programs cover a range of pressure and temperature that allows fluid properties to be evaluated for liquid, liquid-vapor (saturation), and vapor region. GASP and WASP provide properties of 12 fluids. GASPAK includes a library of 36 fluids. GFSSP has three major parts. The first part is the graphical user interface (GUI), visual thermofluid analyzer of systems and components (VTASC). VTASC allows users to create a flow circuit by a 'point and click' paradigm. It creates the GFSSP input file after the completion of the model building process. GFSSP's GUI provides the users a platform to build and run their models. It also allows post-processing of results. The network flow circuit is first built using three basic elements: boundary node, internal node, and branch.

Majumdar, A. K.↗

Station Program Note Pull Automation

Upon commencement of my internship, I was in charge of maintaining the CoFR (Certificate of Flight Readiness) Tool. The tool acquires data from existing Excel workbooks on NASA's and Boeing's databases to create a new spreadsheet listing out all the potential safety concerns for upcoming flights and software transitions. Since the application was written in Visual Basic, I had to learn a new programming language and prepare to handle any malfunctions within the program. Shortly afterwards, I was given the assignment to automate the Station Program Note (SPN) Pull process. I developed an application, in Python, that generated a GUI (Graphical User Interface) that will be used by the International Space Station Safety & Mission Assurance team here at Johnson Space Center. The application will allow its users to download online files with the click of a button, import SPN's based on three different pulls, instantly manipulate and filter spreadsheets, and compare the three sources to determine which active SPN's (Station Program Notes) must be reviewed for any upcoming flights, missions, and/or software transitions. Initially, to perform the NASA SPN pull (one of three), I had created the program to allow the user to login to a secure webpage that stores data, input specific parameters, and retrieve the desired SPN's based on their inputs. However, to avoid any conflicts with sustainment, I altered it so that the user may login and download the NASA file independently. After the user has downloaded the file with the click of a button, I defined the program to check for any outdated or pre-existing files, for successful downloads, to acquire the spreadsheet, convert it from a text file to a comma separated file and finally into an Excel spreadsheet to be filtered and later scrutinized for specific SPN numbers. Once this file has been automatically manipulated to provide only the SPN numbers that are desired, they are stored in a global variable, shown on the GUI, and transferred over to a new Excel worksheet for comparison. I managed to get my application to acquire the CSWG (Computer Safety Working Group) and the SPNWG (Space Station Working Group) SPN's with just two mouse clicks for each pull, as opposed to several from the original process. When all three pulls are performed, an Excel sheet containing all three different results will be generated for the user to compare and determine which SPN's will be presented or reviewed the following month. The experience from this internship has been spectacular. As a high school senior who will begin attending college in the fall, this internship has been both educationally and occupationally beneficial. The internship has allowed me the opportunities to learn new programming languages, effectively network with NASA personnel from a variety of departments at JSC, and allowed me to learn new professional skills and etiquette. My internship at NASA's Johnson Space Center has further motivated me to pursue a Master's degree in Software Engineering and strive for a prosperous career with NASA as a civil servant.

Delgado, Ivan↗

Ground System Architectures Workshop GMSEC SERVICES SUITE (GSS): an Agile Development Story

The GMSEC (Goddard Mission Services Evolution Center) Services Suite (GSS) is a collection of tools and software services along with a robust customizable web-based portal that enables the user to capture, monitor, report, and analyze system-wide GMSEC data. Given our plug-and-play architecture and the needs for rapid system development, we opted to follow the Scrum Agile Methodology for software development. Being one of the first few projects to implement the Agile methodology at NASA GSFC, in this presentation we will present our approaches, tools, successes, and challenges in implementing this methodology. The GMSEC architecture provides a scalable, extensible ground and flight system for existing and future missions. GMSEC comes with a robust Application Programming Interface (GMSEC API) and a core set of Java-based GMSEC components that facilitate the development of a GMSEC-based ground system. Over the past few years, we have seen an upbeat in the number of customers who are moving from a native desktop application environment to a web based environment particularly for data monitoring and analysis. We also see a need to provide separation of the business logic from the GUI display for our Java-based components and also to consolidate all the GUI displays into one interface. This combination of separation and consolidation brings immediate value to a GMSEC-based ground system through increased ease of data access via a uniform interface, built-in security measures, centralized configuration management, and ease of feature extensibility.

Software Development/Agile↗

Recent Developments in the Code RITRACKS (Relativistic Ion Tracks)

The code RITRACKS (Relativistic Ion Tracks) was developed to simulate detailed stochastic radiation track structures of ions of different types and energies. Many new capabilities were added to the code during the recent years. Several options were added to specify the times at which the tracks appear in the irradiated volume, allowing the simulation of dose-rate effects. The code has been used to simulate energy deposition in several targets: spherical, ellipsoidal and cylindrical. More recently, density changes as well as a spherical shell were implemented for spherical targets, in order to simulate energy deposition in walled tissue equivalent proportional counters. RITRACKS is used as a part of the new program BDSTracks (Biological Damage by Stochastic Tracks) to simulate several types of chromosome aberrations in various irradiation conditions. The simulation of damage to various DNA structures (linear and chromatin fiber) by direct and indirect effects has been improved and is ongoing. Many improvements were also made to the graphic user interface (GUI), including the addition of several labels allowing changes of units. A new GUI has been added to display the electron ejection vectors. The parallel calculation capabilities, notably the pre- and post-simulation processing on Windows and Linux machines have been reviewed to make them more portable between different systems. The calculation part is currently maintained in an Atlassian Stash® repository for code tracking and possibly future collaboration.

Plante, Ianik↗

AIRNOISE: A Tool for Preliminary Noise-Abatement Terminal Approach Route Design

Noise from aircraft in the airport vicinity is one of the leading aviation-induced environmental issues. The FAA developed the Integrated Noise Model (INM) and its replacement Aviation Environmental Design Tool (AEDT) software to assess noise impact resulting from all aviation activities. However, a software tool is needed that is simple to use for terminal route modification, quick and reasonably accurate for preliminary noise impact evaluation and flexible to be used for iterative design of optimal noise-abatement terminal routes. In this paper, we extend our previous work on developing a noise-abatement terminal approach route design tool, named AIRNOISE, to satisfy this criterion. First, software efficiency has been significantly increased by over tenfold using the C programming language instead of MATLAB. Moreover, a state-of-the-art high performance GPU-accelerated computing module is implemented that was tested to be hundreds time faster than the C implementation. Secondly, a Graphical User Interface (GUI) was developed allowing users to import current terminal approach routes and modify the routes interactively to design new terminal approach routes. The corresponding noise impacts are then calculated and displayed in the GUI in seconds. Finally, AIRNOISE was applied to Baltimore-Washington International Airport terminal approach route to demonstrate its usage.

aircraft noise↗

NASA Orbital Debris Engineering Model ORDEM 3.1 - Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.1 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.1. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.1 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.1, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.1 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.1 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Vavrin, Andrew B.↗

Introduction to ISS Crew Displays

The International Space Station (ISS) began payload operations in earnest in 2000 with the arrival of the Expedition 1. To date, ISS has offered Principal Investigators (PIs) a reliable platform for microgravity research, having hosted thousands of onboard science experiments. Most of this research is supported by experiment hardware and software and many include a crew‐operated Graphical User Interface (GUI). The purpose of this article is to share information with PIs and Payload Developer (PD) teams about the processes, standards, and guidelines applicable to crew GUI design that must be complied with when planning payload software. The goal is not to enumerate all of the ISS display standards, but rather to highlight design guidelines and the ISS Program milestones for verification and approval of onboard crew displays.

Graphical User Interface↗

An Advanced Operator Interface Design with Preview/Predictive Displays for Ground-Controlled Space Telerobotic Servicing

Recent advances in real-time 3-D graphics and graphical user interface (GUI) technologies enable development of advanced operator interfaces for telerobotic systems. In particular, we have employed preview/predictive displays with calibrated graphics overlay and X/Motif-based GUI's for efficient and reliable ground-controlled space telerobotic servicing under communication time delay.

Telerobotic↗

Developing a Dashboard Interface to Display Assessment of Hazards and Risks to sUAS Flights

The Supplemental Data Services Provider-Consolidated Dashboard (SDSP-CD) is a graphical user interface (GUI) that displays the results of predictive tools in a single location. It is intended to be used in the preflight planning phase of an operation to allow users to proactively assess predicted flight hazards off-line; expanding an operator’s overall situational awareness of a flight plan and providing an opportunity for decision making and assessing the associated risks prior to flight. Hazard data and risk predictions are informative but can be complex to read and understand. However, presented visually and in relation to flight parameters (such as flight path), the nature and significance of hazards become much more evident. The SDSP-Consolidation Dashboard interface was designed to offer a means to present the results of hazard services in an easy to-use format. Two usability studies were run to explore what features might make a suite of hazard assessment services easy to use, and to assess the SDSP-CD interface. The first study evaluated the presentation of information on the GUI and the second evaluated users’ ability to understand and use the information. The studies gathered valuable information about how users approach a hazard assessment task and interpret information from the interface. Many suggestions were given for improving the interface’s information display, to allow users to more quickly understand and interpret the information being presented.

UAV display↗

Developing a Dashboard Interface to Display Assessment of Hazards and Risks to sUAS Flights

The Supplemental Data Services Provider-Consolidated Dashboard (SDSP-CD) is a graphical user interface (GUI) that displays the results of predictive tools in a single location. It is intended to be used in the prefight planning phase of an operation to allow users to proactively assess predicted flight hazards off-line; expanding an operator’s overall situational awareness of a flight plan and providing an opportunity for decision making and assessing the associated risks prior to flight. Hazard data and risk predictions are informative but can be complex to read and understand. However, presented visually and in relation to flight parameters (such as flight path), the nature and significance of hazards become much more evident. The SDSP-Consolidation Dashboard interface was designed to offer a means to present the results of hazard services in an easy to-use format. Two usability studies were run to explore what features might make a suite of hazard assessment services easy to use, and to assess the SDSP-CD interface. The first study evaluated the presentation of information on the GUI and the second evaluated users’ ability to understand and use the information. The studies gathered valuable information about how users approach a hazard assessment task and interpret information from the interface. Many suggestions were given for improving the interface’s information display, to allow users to more quickly understand and interpret the information being presented

UAV display↗

RadLab and the Environmental Data Application Dashboard: Graphical and Programming Interfaces for Interrogation of Space Telemetry Data

Sensors on the International Space Station (ISS) and multiple spacecraft elsewhere in Earth orbit and in deep space continuously monitor and collect environmental data, transmitting this information back to Earth. These data include ionizing radiation and, on the ISS, CO2, relative humidity levels, and temperature, and are of great importance to space biology research. Ionizing radiation in particular has been established in ground-based experiments as being correlated with increased risk of carcinogenesis and cardiovascular and neurological effects. Looking ahead to future long duration crewed missions beyond low Earth orbit, the ability to study how factors including CO2 levels, light cycle, temperature modulate the response to ionizing radiation and microgravity is essential. To date, access to these data has been fragmented across space agencies, spacecraft, and databases. To address this issue, NASA’s Open Science Data Repository (osdr.nasa.gov) has developed two Web applications: the Environmental Data Application (EDA) and a radiation-specific RadLab. Each consists of an API (application programming interface) and an associated GUI (graphical user interface) that provide single points of access to the data. To date, OSDR has focused on the sensors from payloads and radiation detectors located on the ISS. The Web applications process telemetry information and associated data, such as spacecraft location and orientation, from multiple international databases. The applications’ request syntax enables users to interrogate these data by craft, sensor type, time range, radiation type (galactic cosmic rays, solar particle events, the contribution of the South Atlantic Anomaly), facilitating arbitrary comparisons of original source data at varying time resolutions. The applications provide programmatic access for use in computational pipelines and GUIs for data visualization and exploration, making these data FAIR (Findable, Accessible, Interoperable, and Reusable), complementing the biological data contained in OSDR, and providing the space science community with a valuable resource for scientific analyses.

radiation↗

L2-Charged Particle Environment (L2-CPE)Low Energy Radiation Fluence Model

The L2 Charged Particle Environment (L2-CPE) model provides estimates of number flux and fluence for the low energy electron, proton, and alpha particle populations in the near Earth solar wind and the Earth’s distant magnetosheath and magnetotail. The model is an engineering tool for specifying radiation environments over an energy range from a few eV to a few MeV of importance to surface dose and radiation damage to thin space exposed materials and is intended for use in space system design applications. Mission fluences are obtained by simulating a spacecraft flight trajectory through time-dependent bow shock and magnetopause boundaries with dimensions and orientations driven by solar wind parameters. Monte Carlo sampling of flux environments within individual plasma regimes and/or fluence accumulated along a fight trajectory through multiple regimes is used to determine statistical variations (means and extremes) of the differential number flux and fluence environments for each of the three charged particle species. Model output is differential (in energy) number fluence and flux for the three particle species in units of particles/cm2-keV and particles/cm2-sec-keV, respectively. Users can select the energy range of interest but the current version of the code (L2-CPE Version 1.4.2d) is limited to an energy range of 1 eV to 10 MeV. Flux is integrated over angle to give flux and fluence to surfaces in the ±XGSE, ±YGSE, and/or ±ZGSE directions. Figure 1 shows the opening screen from the L2-CPE graphical user interface (GUI) with options for flux, fluence, plotting model output. The flux scene generate is not currently implemented in the GUI.

Joseph I Minow↗

RadLab: Graphical and Programming Interfaces for Interrogation of Space Telemetry Data

Sensors on multiple spacecraft in and beyond low Earth orbit continuously monitor and collect space radiation data and transmit it back to Earth. These data are of vast importance to space biology research, as ionizing radiation affects living organisms—astronauts and non-human experiment subjects alike—placing them at higher risk of carcinogenesis, degenerative diseases, and radiation sickness. Therefore, knowledge of the biological effects of space radiation is essential for planning future crewed missions beyond low Earth orbit. The RadLab project, initiated by GeneLab and ALSDA (the Open Science Data Repository; OSDR) and sponsored by the NASA Human Research Program, is a new effort aimed at connecting dosimetry data from radiation detectors located on the International Space Station (ISS), as well as other spacecraft. To date, access to these data has been fragmented across space agencies and databases; to address this issue, we have developed an application programming interface (API) and an associated graphical user interface (GUI) designed to provide a single point of access to the data. As of now, OSDR has focused on the detectors located on the ISS, with the long-term goal to establish a self-sustained portal receiving continuous updates through APIs connecting to multiple radiation databases of varying scope, as well as individual investigator contributions. The RadLab API implements a request syntax enabling users to query data by craft, sensor type, timespan, etc, allowing for arbitrary combinations of original source data, thus providing programmatic access for use in computational pipelines, while the GUI facilitates data visualization and exploration, making these data FAIR (Findable, Accessible, Interoperable, and Reusable), complementing the biological data contained in OSDR, and providing the space science community with a valuable resource for scientific analyses.

radiation↗

NASA Orbital Debris Engineering Model ORDEM 3.2 – Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.2 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.2. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.2 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.2, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.2 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.2 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Andrew Vavrin↗

OverFlight: Graphical Flight Operations Planning

OverFlight is an in-development graphical user interface (GUI) that implements a state-of-the-art rotorcraft maneuvering noise model using a source noise hemisphere approach coupled with the Aircraft NOise Prediction Program 2 (ANOPP2). This GUI stems from a demand for easy-to-use mission planning and community impact acoustic tools that can model the maneuvering flight of a rotary-wing vehicle. This paper covers the models used for the development of OverFlight and model validation efforts. Data from a joint NASA/Army flight test of an MD530F aircraft are used both for source noise hemispheres as well as maneuvering flight data. Analysis of the predicted maneuvering noise shows better agreement that traditional methods currently employed, while also demonstrating maneuvers where the underlying assumptions fail to hold.

rotorcraft↗

Use of Assistive Technology to Augment API Capabilities

Application Programming Interfaces (APIs) allow for access to data and capabilities of computer applications by developers or users with experience in computer programming. Recent development with both Thermal Desktop and ESATAN-TMS have provided APIs to allow users to develop their own capabilities that interface with the Graphical User Interfaces (GUI) or manipulate the thermal model data. However, these APIs are only as good as the breadth of features in the native code accessible through the API. If a particular code’s feature is not accessible through the API, then users have very limited options besides waiting for updates to the API that expose the necessary functionality, particularly if model data access or user action, such as a button click, is required. However, Assistive Technology features that allow for users with a disability to more fully experience a software’s capabilities may be creatively utilized to gain further access to data and capabilities not yet exposed by the API. This paper describes the process to augment the features of the OpenTD API via assistive technology and describes how to identify the application instance, navigate GUI elements, updates values on forms, and execute actions such as selecting a listbox item or clicking a button. It concludes with identifying some of the pitfalls to avoid and describes methods to best implement this approach.

Application Programming Interface↗

Use of Assistive Technology to Augment API Capabilities

Application Programming Interfaces (APIs) allow for access to data and capabilities of computer applications by developers or users with experience in computer programming. Recent development with both Thermal Desktop and ESATAN-TMS have provided APIs to allow users to develop their own capabilities that interface with the Graphical User Interfaces (GUI) or manipulate the thermal model data. However, these APIs are only as good as the breadth of features in the native code accessible through the API; if a particular code’s feature is not accessible through the API, then users have very limited options besides waiting for updates to the API that expose the necessary functionality, particularly if model data access or user action, such as a button click, is required. However, Assistive Technology features that allow for differently-abled users to more fully experience a software’s capabilities may be creatively utilized to gain further access to data and capabilities not yet exposed by the API. This paper describes the process to augment the features of the OpenTD API via assistive technology and describes how to identify the application instance, navigate GUI elements, updates values on forms, and execute actions such as selecting a listbox item or clicking a button. It concludes with identifying some of the pitfalls to avoid and describes methods to best implement this approach.

Application Programming Interface↗

Systems and methods for monitoring traffic on industrial control and building automation system networks

Technologies relating to monitoring communications traffic to detect potential attacks on industrial control system networks and building automation system networks are described herein. In an embodiment, a monitoring device receives a plurality of communications from a control network. The monitoring device transmits the communications to a computing device. Based on the communications, the computing device generates a listing of devices that communicated by way of the control network over a period of time, and computes a volume of traffic between each pair of devices in the listing of devices. The computing device then outputs a graphical user interface (GUI) by way of display, the GUI comprising data indicative of the computed volumes of traffic, which may be indicative of a potential attack on the control network.

Jenkins, Chris↗