Architecting a software architect
The objective of this paper is to describe the structure of the SWAP, the program's background, how the program has evolved, and the lessons learned from the implementation of this educational program.
software↗
SEARCH · Engineering Papers
Results for “Software Architecting”
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.
Software Development Standard Processes (SDSP)
A JPL-created set of standard processes is to be used throughout the lifecycle of software development. These SDSPs cover a range of activities, from management and engineering activities, to assurance and support activities. These processes must be applied to software tasks per a prescribed set of procedures. JPL s Software Quality Improvement Project is currently working at the behest of the JPL Software Process Owner to ensure that all applicable software tasks follow these procedures. The SDSPs are captured as a set of 22 standards in JPL s software process domain. They were developed in-house at JPL by a number of Subject Matter Experts (SMEs) residing primarily within the Engineering and Science Directorate, but also from the Business Operations Directorate and Safety and Mission Success Directorate. These practices include not only currently performed best practices, but also JPL-desired future practices in key thrust areas like software architecting and software reuse analysis. Additionally, these SDSPs conform to many standards and requirements to which JPL projects are beholden.
Lavin, Milton L.↗
Architectural Analysis of Complex Evolving Systems of Systems
The goal of this collaborative project between FC-MD, APL, and GSFC and supported by NASA IV&V Software Assurance Research Program (SARP), was to develop a tool, Dynamic SAVE, or Dyn-SAVE for short, for analyzing architectures of systems of systems. The project team was comprised of the principal investigator (PI) from FC-MD and four other FC-MD scientists (part time) and several FC-MD students (full time), as well as, two APL software architects (part time), and one NASA POC (part time). The PI and FC-MD scientists together with APL architects were responsible for requirements analysis, and for applying and evaluating the Dyn-SAVE tool and method. The PI and a group of FC-MD scientists were responsible for improving the method and conducting outreach activities, while another group of FC-MD scientists were responsible for development and improvement of the tool. Oversight and reporting was conducted by the PI and NASA POC. The project team produced many results including several prototypes of the Dyn-SAVE tool and method, several case studies documenting how the tool and method was applied to APL s software systems, and several published papers in highly respected conferences and journals. Dyn-SAVE as developed and enhanced throughout this research period, is a software tool intended for software developers and architects, software integration testers, and persons who need to analyze software systems from the point of view of how it communicates with other systems. Using the tool, the user specifies the planned communication behavior of the system modeled as a sequence diagram. The user then captures and imports the actual communication behavior of the system, which is then converted and visualized as a sequence diagram by Dyn-SAVE. After mapping the planned to the actual and specifying parameter and timing constraints, Dyn-SAVE detects and highlights deviations between the planned and the actual behavior. Requirements based on the need to analyze two inter-system communication protocols that are representative of protocols used in the Aerospace industry have been specified. The protocols are related: APL s Common Ground System (CGS) as used in the MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) and the Radiation Belt Space Probes (RBSP) missions. The analyzed communications were implementations of the Telemetry protocol and the CCSDS File Delivery Protocol (CFDP) protocol. Based on these requirements, three prototypes of Dyn-SAVE were developed and applied to these protocols. The application of Dyn-SAVE to these protocols resulted in the detection of several issues. Dyn-SAVE was also applied to several Testbeds that have previously been used for experimentation earlier on this project, as well as, to other protocols and logs for testing its broader applicability. For example, Dyn-SAVE was used to analyze 1) the communication pattern between a web browser and a web server, 2) the system log of a computer in order to detect offnominal computer shut-down behavior, and 3) the actual test cases of NASA Goddard s Core Flight System (CFS) and automatically generated test cases in order to determine the overlap between the two sets of test cases. In all cases, Dyn-SAVE assisted in providing insightful conclusions about each of the cases identified above.
Lindvall, Mikael↗
PHM for Ground Support Systems Case Study: From Requirements to Integration
This session will detail the experience of members of the NASA Ames Prognostic Center of Excellence (PCoE) producing PHM tools for NASA Advanced Ground Support Systems, including the challenges in applying their research in a production environment. Specifically, we will 1) go over the systems engineering and review process used; 2) Discuss the challenges and pitfalls in this process; 3) discuss software architecting, documentation, verification and validation activities and 4) discuss challenges in communicating the benefits and limitations of PHM Technologies.
Prognostics↗
The Automated Instrumentation and Monitoring System (AIMS) reference manual
Whether a researcher is designing the 'next parallel programming paradigm,' another 'scalable multiprocessor' or investigating resource allocation algorithms for multiprocessors, a facility that enables parallel program execution to be captured and displayed is invaluable. Careful analysis of execution traces can help computer designers and software architects to uncover system behavior and to take advantage of specific application characteristics and hardware features. A software tool kit that facilitates performance evaluation of parallel applications on multiprocessors is described. The Automated Instrumentation and Monitoring System (AIMS) has four major software components: a source code instrumentor which automatically inserts active event recorders into the program's source code before compilation; a run time performance-monitoring library, which collects performance data; a trace file animation and analysis tool kit which reconstructs program execution from the trace file; and a trace post-processor which compensate for data collection overhead. Besides being used as prototype for developing new techniques for instrumenting, monitoring, and visualizing parallel program execution, AIMS is also being incorporated into the run-time environments of various hardware test beds to evaluate their impact on user productivity. Currently, AIMS instrumentors accept FORTRAN and C parallel programs written for Intel's NX operating system on the iPSC family of multi computers. A run-time performance-monitoring library for the iPSC/860 is included in this release. We plan to release monitors for other platforms (such as PVM and TMC's CM-5) in the near future. Performance data collected can be graphically displayed on workstations (e.g. Sun Sparc and SGI) supporting X-Windows (in particular, Xl IR5, Motif 1.1.3).
Yan, Jerry↗
The Automated Instrumentation and Monitoring System (AIMS): Design and Architecture
Whether a researcher is designing the 'next parallel programming paradigm', another 'scalable multiprocessor' or investigating resource allocation algorithms for multiprocessors, a facility that enables parallel program execution to be captured and displayed is invaluable. Careful analysis of such information can help computer and software architects to capture, and therefore, exploit behavioral variations among/within various parallel programs to take advantage of specific hardware characteristics. A software tool-set that facilitates performance evaluation of parallel applications on multiprocessors has been put together at NASA Ames Research Center under the sponsorship of NASA's High Performance Computing and Communications Program over the past five years. The Automated Instrumentation and Monitoring Systematic has three major software components: a source code instrumentor which automatically inserts active event recorders into program source code before compilation; a run-time performance monitoring library which collects performance data; and a visualization tool-set which reconstructs program execution based on the data collected. Besides being used as a prototype for developing new techniques for instrumenting, monitoring and presenting parallel program execution, AIMS is also being incorporated into the run-time environments of various hardware testbeds to evaluate their impact on user productivity. Currently, the execution of FORTRAN and C programs on the Intel Paragon and PALM workstations can be automatically instrumented and monitored. Performance data thus collected can be displayed graphically on various workstations. The process of performance tuning with AIMS will be illustrated using various NAB Parallel Benchmarks. This report includes a description of the internal architecture of AIMS and a listing of the source code.
Yan, Jerry C.↗
Smart Contract Architectures and Templates for Blockchain-based Energy Markets (V.1.0)
Within the field of Transactive Energy Systems (TES), there is an active need for tools that can support and accelerate the development of these new grid solutions. Among the many tools available, blockchain stands out as a viable instrument that can help researchers develop decentralized, autonomous, and tamper-resistant grid applications. In this work, we explore the use of smart contracts (SCs), a subset of blockchain technology, and analyze their applicability to facilitating the implementation of TES solutions. In particular, we focus on presenting areas of opportunity and potential drawbacks, along with use cases that can benefit from this technology building upon previous research developed by Pacific Northwest National Laboratory and other research organizations. This work builds upon the fundamentals of TES and smart contract technology to develop a series of software templates that can be used by industry to build TES-oriented grid solutions. These templates are intended to be platform agnostic and take into consideration the unique properties of SCs and distributed ledger storage mechanisms to ensure actual code implementations remain aware of the limitations of the technology. The proposed templates have the potential to enable software architects to mix and match components to satisfy their application requirements, thereby reducing the number of resources required to implement blockchain-based solutions. These templates are divided into two main components—data and behavioral models. The data models are intended to help software engineers represent the underlying grid objects along with their properties in a ledger-based storage system. The behavioral models are used to describe the processes and actions that actors within a system must perform to achieve a given outcome such as registering an asset, placing a bid, and performing bid clearances. These two components are documented in a Unified Modeling Language (UML) format and are intended for use in SC-based implementations, with special behavioral considerations to account for the asynchronous properties of the underlying ledger and the typical execution model of smart contracts. Finally, future research ideas and potential extensions to this work are discussed. In particular, known limitations and potential improvements of the developed product are identified and expected to be addressed in future revisions of the template model.
24 POWER TRANSMISSION AND DISTRIBUTION↗
Deciphering Discrepancies: A Comparative Analysis of Docker Image Security
As the use of microservices continues to grow and become a foundational approach to architecting software solutions, ensuring the security of microservices is paramount. Docker images have emerged as the predominant solution to containerize microservices–and thus, Docker images are becoming a large attack surface. Thus, reducing vulnerabilities in Docker images will reduce microservice cyberattacks. A common way to find vulnerabilities in Docker images employs static analysis tools like Trivy and Grype. However, these tools frequently generate disparate vulnerability reports when analyzing the same Docker image, thus causing uncertainty in tool selection. We collected 927 Docker images, analyzed them with Trivy and Grype, and compared the vulnerabilities reported in each image. Among the 865 images found to have vulnerabilities, Trivy and Grype disagreed on both the number of vulnerabilities and the vulnerability IDs found therein. Since both tools interface with external vulnerability databases, some discrepancies can be attributed to how the tools interface with these external resources. The external vulnerability databases partially overlap and frequently contradict one another, thereby creating challenges for static analysis tool developers and end users alike. This New Ideas and Emerging Results (NIER) study contains new and critical information that practitioners need for selecting and using static analysis tools–given that increases in the use of Docker technologies means increases in the size of the attack surfaces.
Boles, Brittany [Montana State University]↗
A Cybersecurity Threat Profile for a Connected Lighting System
In this paper we analyze a threat profile performed on a fault-detection use case for streetlights. A threat profile establishes security requirements, justifies security measures, yields actionable controls, and effectively communicates risk to stakeholders. This effort provides critical information for making threat-based decisions to increase security at a reasonable cost, and can effectively be used by development teams, software architects, and managers to make cybersecurity a part of their ongoing culture of awareness, training, and prevention. This leads to more secure systems and better-understood security. On-premise, cloud, and hybrid architectures with different authentication mechanisms were modeled and later categorized using the Microsoft STRIDE framework. An analysis of the recommended controls for each threat was performed to determine which controls could and should be put in place by manufacturers or third-party suppliers, and which controls need to be left up the end-user to implement.
97 MATHEMATICS AND COMPUTING↗
A Cybersecurity Threat Profile for a Connected Lighting System
In anticipation of improved energy performance and cost savings, cities and building owners are increasingly considering “smart lighting initiatives” that aim to convert their collection of simple luminaires (i.e., lighting fixtures) into an intelligent connected lighting system (CLS) capable of remotely monitoring energy consumption and fault conditions, and possibly implementing adaptive lighting schemes. The U.S. Department of Energy (DOE) has set an national goal of tripling the energy efficiency and demand flexibility of the buildings sector by 2030, relative to 2020 levels 1. It is forecast that connected lighting systems can contribute to that goal by delivering 125 TWh of annual energy savings by 2035 2, equivalent to the annual output of 50 typical (500 MW) power plants. However, these energy savings and the DOE goal are put at significant risk if connected technologies are not adopted due to real or perceived cybersecurity concerns. Connected IoT devices such as these have historically been rife with vulnerabilities which sometimes put security considerations secondary to functionality and operability. What are the cybersecurity threats that will impact these systems, as formerly banal luminaires transition into intelligent connected devices that collect information about themselves, their surrounding environment, and possibly us? In this paper we analyze a threat profile performed on a fault-detection use case for streetlights. A threat profile establishes security requirements, justifies security measures, yields actionable controls, and effectively communicates risk to stakeholders. This effort provides critical information for making threat-based decisions to increase security at a reasonable cost, and can effectively be used by development teams, software architects, and managers to make cybersecurity a part of their ongoing culture of awareness, training, and prevention. This leads to more secure systems and better-understood security. On-premise, cloud, and hybrid architectures with different authentication mechanisms were modeled and later categorized using the Microsoft STRIDE framework. An analysis of the recommended controls for each threat was performed to determine which controls could and should be put in place by manufacturers or third-party suppliers, and which controls need to be left up the end-user to implement. Fifty-seven threats were identified. Among our key findings: (1) 65% (37/57) of the threats did not involve the luminaires, but rather the other components needed to communicate with and manage them; (2) 63% (36/57) of the threats could have been mitigated through manufacturer-implemented defensive techniques or “controls”; and (3) 23% (13/57) of the threats were dependent on the network configuration. Recommendations based on the results of this work are made to key stakeholder groups. Notably, lighting technology developers are advised to address all threats that can be reasonably controlled with baked-in technology solutions (e.g., encryption or authentication controls), and employ some form of secure supply chain management and tracking where other parts (e.g., sensors, microprocessors) of a luminaire must also be built and manufactured with the proper security controls in place. Developers should also review threats involving assets not developed in-house to understand how connectivity with other devices will affect their product during system operation and determine if a compensating control for a defense-in-depth strategy will be needed. Finally, those interested in deploying CLS should compare the differences between cloud and on-premise models to determine which is more suitable for their needs and the abilities of their security team.
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
Quality Attributes for Mission Flight Software: A Reference for Architects
In the international standards for architecture descriptions in systems and software engineering (ISO/IEC/IEEE 42010), "concern" is a primary concept that often manifests itself in relation to the quality attributes or "ilities" that a system is expected to exhibit - qualities such as reliability, security and modifiability. One of the main uses of an architecture description is to serve as a basis for analyzing how well the architecture achieves its quality attributes, and that requires architects to be as precise as possible about what they mean in claiming, for example, that an architecture supports "modifiability." This paper describes a table, generated by NASA's Software Architecture Review Board, which lists fourteen key quality attributes, identifies different important aspects of each quality attribute and considers each aspect in terms of requirements, rationale, evidence, and tactics to achieve the aspect. This quality attribute table is intended to serve as a guide to software architects, software developers, and software architecture reviewers in the domain of mission-critical real-time embedded systems, such as space mission flight software.
Software architecture↗
Quality Attributes for Mission Flight Software: A Reference for Architects
No abstract available
Dvorak, Dan↗
DLIO: A DATA-CENTRIC BENCHMARK FOR DEEP LEARNING APPLICATIONS
SF-22-136 Deep learning has been shown as a successful method for various tasks, and its popularity results in numerous open-source deep learning software tools. Deep learning has been applied to a broad spectrum of scientific domains such as cosmology, particle physics, computer vision, fusion, and astrophysics. Scientists have performed a great deal of work to optimize the computational performance of deep learning frameworks. However, the same cannot be said for I/O performance. As deep learning algorithms rely on big-data volume and variety to effectively train neural networks accurately, I/O is a significant bottleneck on large-scale distributed deep learning training. DLIO, is a novel representative benchmark suite built based on the I/O profiling of the selected workloads. DLIO can be utilized to accurately emulate the I/O behavior of modern deep learning applications. Using DLIO, application developers and system software solution architects can identify potential I/O bottlenecks in their applications and guide optimizations to boost the I/O performance leading to lower training times. The storage vendor can also use DLIO as a guide for designing and optimize the storage and filesystem targeting at deep learning application.
ZHENG, HUIHUO↗
Nisar L-band Digital Electronics Subsystem
The NASA-ISRO Synthetic Aperture Radar (NISAR) L-band SAR instrument employs multiple digital channels to optimize resolution while keeping a large swath on a single pass. High-speed digitization with fine synchronization and digital beam forming are necessary in order to facilitate this new technique called SweepSAR. An architecture employing multiple FPGA based digital signal processors has been conceived to facilitate digital calibration on an individual channel basis as well as digital signal processing to optimize the receive signal. On-board processing and data compression has been implemented to reduce the volume of data in order to satisfy the operational requirements of near global coverage for the desired science targets. A novel command and timing architecture was developed to manage this complex system to meet the challenging project requirements. The NISAR L-band Digital Electronics Subsystem is the combination of the hardware, firmware and software components architected and implemented to operate this radar and return the desired quantity and quality of data for the science community.
SweepSAR↗
NISAR L-SAR Digital Electronics Subsystem - A Multichannel Distributed Processing System with Synchronous Timing Control for Digital Beam Forming and Multiple Echo Tracking
The NASA-ISRO Synthetic Aperture Radar (NISAR) L-band SAR instrument employs multiple digital channels to optimize resolution while keeping a large swath on a single pass. High-speed digitization with fine synchronization and digital beam forming are necessary in order to facilitate this new technique called SweepSAR. An architecture employing multiple FPGA based digital signal processors has been conceived to facilitate digital calibration on an individual channel basis as well as digital signal processing to optimize the receive signal. On-board processing and data compression has been implemented to reduce the volume of data in order to satisfy the operational requirements of near global coverage for the desired science targets. A novel command and timing architecture was developed to manage this complex system while providing detailed control of individual channel receive window timing required for digital beam forming. The NISAR L-band Digital Electronics Subsystem is the combination of the hardware, firmware and software components architected and implemented to operate this radar and return the desired quantity and quality of data for the science community.
Chuang, Chung-Lun↗
Refactoring the Curiosity Rover's sample handling architecture on Mars
The Curiosity Mars rover sample handling hardware and software were architected assuming that end-to-end sampling operations would occur in a single rover position, from acquisition of a powdered sample with a scoop or drill, through to the cleaning out of all sample residue in the sample chain. However, after analysis of the first drilled samples in Yellowknife Bay, the science team wanted to iterate with additional experiments on Mars and in laboratories on Earth to better understand their results and increase the value of science returned. With the architecture as conceived, the time needed to do so was in direct competition with the exploration of other targets and satisfaction of success criteria during the prime mission.
Kuhn, Stephen↗
Toward Performance Portable Programming for Heterogeneous System-on-Chips: Case Study with Qualcomm Snapdragon SoC
Future heterogeneous Domain-Specific System-on-Chips (DSSoC) will be extraordinarily complex in terms of processors, memory hierarchies, and interconnection networks.To manage this complexity, architects, system software designers, and application developers need programming technologies that are flexible, accurate, efficient, and productive. These technologies will need to be as independent of any one specific architecture as is practical, because the sheer dimensionality and scale of the complexity will not allow porting and optimizing applications foreach given DSSoC. To address these issues, we are developing Cosmic Castle, a performance portable programming toolchain for streaming applications on heterogeneous architectures. The primary focus of Cosmic Castle is on enabling efficient and performant code generation through the smart compiler and intelligent runtime system. This paper presents the preliminary evaluation of our ongoing work toward Cosmic Castle. Specifically, we detail our code porting efforts and evaluate various benchmarks on the Qualcomm Snapdragon SoC using tools developed through Cosmic Castle.
Cabrera, Anthony↗
AutoGNC Testbed
A simulation testbed architecture was developed and implemented for the integration, test, and development of a TRL-6 flight software set called Auto- GNC. The AutoGNC software will combine the TRL-9 Deep Impact AutoNAV flight software suite, the TRL-9 Virtual Machine Language (VML) executive, and the TRL-3 G-REX guidance, estimation, and control algorithms. The Auto- GNC testbed was architected to provide software interface connections among the AutoNAV and VML flight code written in C, the G-REX algorithms in MATLAB and C, stand-alone image rendering algorithms in C, and other Fortran algorithms, such as the OBIRON landmark tracking suite. The testbed architecture incorporates software components for propagating a high-fidelity truth model of the environment and the spacecraft dynamics, along with the flight software components for onboard guidance, navigation, and control (GN&C). The interface allows for the rapid integration and testing of new algorithms prior to development of the C code for implementation in flight software. This testbed is designed to test autonomous spacecraft proximity operations around small celestial bodies, moons, or other spacecraft. The software is baselined for upcoming comet and asteroid sample return missions. This architecture and testbed will provide a direct improvement upon the onboard flight software utilized for missions such as Deep Impact, Stardust, and Deep Space 1.
Carson, John M., III↗