Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “reference language”

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.

311 records · Page 18

Precursor Analysis Report: SQL Slammer Worm Infection of Davis-Besse Nuclear Power Plant 2003

The SQL Slammer Worm Infection of Davis-Besse Nuclear Power Plant 2003 Precursor Analysis Report leverages publicly available information about Davis-Besse’s 2003 cyber attack and catalogs anomalous observables for each technique employed in the attack. This analysis is based upon the methodology of the Cybersecurity for the Operational Technology Environment (CyOTE) program. On 25 January 2003, the SQL Slammer worm infected more than 90% of vulnerable hosts and crashed the internet in 10 to 15 minutes, making it one of the fastest spreading worms in history. SQL Slammer is a fileless, memory-resident worm that remotely exploits a stack-based buffer overflow vulnerability on local hosts to intensively scan and rapidly self-propagate across the internet. The worm infected approximately 300,000 unpatched hosts running Microsoft Structured Query Language (SQL) Server 2000 or Microsoft Desktop Engine (MSDE) 2000 with SQL Server Resolution Service. The SQL Slammer worm indirectly infected FirstEnergy’s Davis-Besse nuclear power plant by first infecting a consultant’s company network server and then propagating through an external misconfigured connection into Davis-Besse’s site network. The infection caused major network congestion, slow performance, data overloads, and the inability of local hosts to communicate with each other, which eventually caused a loss of availability and a loss of view when the Safety Parameter Display System (SPDS) and Plant Process Computer (PPC) crashed. At the time of the infection, the plant was already offline, the digital monitoring systems had redundant analog backups, and the plant control and safety functions were not affected, so there were no concerns of a safety breach. However, this incident resulted in many lessons learned and spawned important discussions about cybersecurity’s role in nuclear safety and electric power reliability regulation, policy, and guidance. Researchers and analysts identified 10 unique techniques utilized during the attack with a total of 640 observables using MITRE ATT&CK® for Industrial Control Systems. The CyOTE program assesses observables accompanying techniques used prior to the triggering event to identify opportunities to detect malicious activity. If observables accompanying the attack techniques are perceived and investigated prior to the triggering event, earlier comprehension of malicious activity can take place. Eight of the identified techniques used during Davis-Besse cyber attack were precursors to the triggering event. Analysis identified 596 observables associated with these precursor techniques, 428 of which were assessed to have an increased likelihood of being perceived in the 331 days preceding the triggering event. The response and comprehension time could have been reduced if the observables had been identified earlier. The information gathered in this report contributes to a library of observables tied to a repository of artifacts, data sources, and technique detection references for practitioners and developers to support the comprehension of indicators of attack. Asset owners and operators can use these products if they experience similar observables or to prepare for comparable scenarios.

45 MILITARY TECHNOLOGY, WEAPONRY, AND NATIONAL DEF↗

AENET–LAMMPS and AENET–TINKER : Interfaces for accurate and efficient molecular dynamics simulations with machine learning potentials

Machine-learning potentials (MLPs) trained on data from quantum-mechanics based first-principles methods can approach the accuracy of the reference method at a fraction of the computational cost. To facilitate efficient MLP-based molecular dynamics and Monte Carlo simulations, an integration of the MLPs with sampling software is needed. Here, we develop two interfaces that link the atomic energy network (ænet) MLP package with the popular sampling packages TINKER and LAMMPS. The three packages, ænet, TINKER, and LAMMPS, are free and open-source software that enable, in combination, accurate simulations of large and complex systems with low computational cost that scales linearly with the number of atoms. Scaling tests show that the parallel efficiency of the ænet–TINKER interface is nearly optimal but is limited to shared-memory systems. The ænet–LAMMPS interface achieves excellent parallel efficiency on highly parallel distributed memory systems and benefits from the highly optimized neighbor list implemented in LAMMPS. We demonstrate the utility of the two MLP interfaces for two relevant example applications: the investigation of diffusion phenomena in liquid water and the equilibration of nanostructured amorphous battery materials.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

The SPASE Data Model for Heliophysics Data: Is it Working?

The Space Physics Archive Search and Extract (SPASE) Data Model was developed to provide a metadata standard for describing Heliophysics (Space and Solar Physics) data within that science discipline. The SPASE Data Model has matured over the many years of its creation and is presently represented by Version 2.2.1. Information about SPASE can be obtained from the website group.org. The Data Model defines terms and values as well as the relationships between them in order to describe the data resources in the Heliophysics data environment. This data environment is quite complex, consisting of Virtual Observatories, Resident Archives, Data Providers, Partnering Data Centers, Services, Final Archives, and a Deep Archive. SPASE is the metadata language standard intended to permeate the complexity and provide a common method of obtaining and understanding data. Is it working in this capacity? SPASE has been used to describe a wide range of data. Examples range from ground-based magnetometer data to interplanetary satellite measurements to space weather model results. Has it achieved the goal of making the data easier to find and use? To find data of interest it is necessary that all the data of importance be described using the SPASE Data Model. Within the part of the data community associated with NASA (supported through NASA funding) there are obligations to use SPASE and (0 describe the old and new data using the SPASE XML schema. Although this pan of the community is not near 100% compliance with the mandate, there is good progress being made and the goal should be reachable in the future. Outside of the NASA data community there is still work to be done to convince the international community that SPASE descriptions are w011h the cost of their generation. Some of these groups such as Cluster, HELlO, GAIA, NOAA/NGDe. CSSDP, VSTO, SuperMAG, and IUGONET have agreed to use SPASE. but there are still other groups of importance that need (0 be reached. It is also assumed that the terminology is sufficiently broad and the descriptions are sufficiently complete that researchers needing data of a specific type or from a specific period can find and acquire what they need. A valid SPASE description can be very brief or very thorough depending on the willingness of the author to spend the time necessary to make the description useful. There is evidence that users are finding what they need through the SPASE descriptions, and this standard is a big step forward in Heliophysics data location. Does SPASE make it easier to use the data once they are found,) Thorough descriptions of data using SPASE can describe the data down to the level of individual parameters and exactly how the data are organized and stored. Should the SPASE data descriptions be written in such a way that they can be automatically ingested and understood by software tools'? Heliophysics instruments are becoming morc versatile all the time and the complexity of the data makes it tedious and time consuming to write SPASE descriptions with this level of sophistication even with the improvement of the tools used to generate the descriptions. Is it better to just write human-readable descriptions of the data at the parameter level or to refer to references that provide this information? This is a debate that is presently taking place and software is being developed to test what is possible.

Thieman, James↗

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗

Prevalence of Self-Reported Bothersome Tinnitus in U.S. Army Soldiers From January 1, 2015, Through September 30, 2019

Purpose: Tinnitus is a symptom of auditory dysfunction or injury and can be a precursor to permanent hearing loss. Tinnitus can interfere with communication, sleep, concentration, and mood; when this occurs, it is referred to as bothersome tinnitus. Annual hearing surveillance in the U.S. Army includes screening for bothersome tinnitus. Estimating the prevalence of self-reported bothersome tinnitus can facilitate prioritization of prevention and education efforts. The objective of this study was to examine Army hearing conservation data to estimate the prevalence of self-reported bothersome tinnitus as a function of age, hearing, sex, service component, and pay grade. Method: The study employed a cross-sectional, retrospective design. Records from 1,485,059 U.S. Army Soldiers retrieved from the Defense Occupational and Environmental Health Readiness System–Hearing Conservation were analyzed. Descriptive statistics and multinomial logistic regression analysis were used to estimate the prevalence of bothersome tinnitus and its associations with Soldiers' demographic characteristics. Results: The estimated prevalence of self-reported bothersome tinnitus was 17.1% between January 1, 2015, and September 30, 2019; 13.6% of the Soldiers reported “bothered a little” and 3.5% reported “bothered a lot.” Proportionally, the prevalence of self-reported bothersome tinnitus was higher for males, older Soldiers, and Reserve Component Soldiers. For every 1-year increase in age, the odds of self-reporting “bothered a little” tinnitus relative to “bothered not at all tinnitus” would be expected to increase by 2.2% (2.1%, 2.3%), and the odds of self-reporting “bothered a lot” tinnitus relative to “bothered not at all” tinnitus would be expected to increase by 3.6% (3.5%, 3.7%). Conclusions: The self-reported prevalence of bothersome tinnitus in the U.S. Army (17.1%) is substantially higher than that of the general population, where prevalence of bothersome tinnitus is estimated at 6.6%. Examination of bothersome tinnitus among Soldiers is an important step toward optimizing prevention, education, and intervention efforts.

Audiology & Speech-Language Pathology↗