Special Coverage

Supercomputer Cooling System Uses Refrigerant to Replace Water
Computer Chips Calculate and Store in an Integrated Unit
Electron-to-Photon Communication for Quantum Computing
Mechanoresponsive Healing Polymers
Variable Permeability Magnetometer Systems and Methods for Aerospace Applications
Evaluation Standard for Robotic Research
Small Robot Has Outstanding Vertical Agility
Smart Optical Material Characterization System and Method
Lightweight, Flexible Thermal Protection System for Fire Protection

ISO 26262 & Automotive Electronics Development

Compliance standards, especially those that involve relatively new functional safety elements, will likely add additional requirements to the development process. But ISO 26262, in particular, will add more than new requirements to the product life cycle for automotive hardware-software systems. This Functional Safety standard will act as a framework impacting integrated requirements traceability, risk management, validation, verification, documentation and collaboration throughout the systems engineering “V” model life cycle process (see Figure). ISO 26262 will also require the qualification of tools used to create automotive systems. This paper examines the impact of the standard on the development process and support tool chains for automotive electronics.

Posted in: Briefs, TSP, Electronics & Computers, Information Sciences, Semiconductors & ICs, Software


BPTables DTN Bundle Filtering Framework

The Internet Engineering Task Force (IETF) standardized Bundle Protocol (BP) enables data transfer using “bundles” over a Delay/Disruption Tolerant Network (DTN). BPTables is a bundle filtering framework that enables the establishment of barriers between more and less trusted BP network domains, and complements a security framework that includes the Simplified Bundle Security Protocol (SBSP). BPTables is implemented for the Linux port of the Interplanetary Overlay Network (ION) Bundle Protocol (BP) implementation of the DTN protocol stack. BPTables blocks forwarding of bundles whose source and destination node numbers are not explicitly allowed by the filtering policy, and by default all IPN bundles will be blocked. The current implementation presents a minimal resource footprint on embedded systems. The bundle filtering policy is determined by the contents of a rule file. Rules consist of ordered pairs (A, B) where traffic is permitted to flow from node A to node B. The rule parser understands wildcards (to simplify rule construction), and is able to optimize and combine rules to speed up evaluation.

Posted in: Briefs, Software, Architecture, Communication protocols, Data exchange


A Systems Engineering Approach to Architecture Development

Architecture development often is conducted prior to system concept design when there is a need to determine the best-value mix of systems that works collectively in specific scenarios and time frames to accomplish a set of mission area objectives. Conducted prior to Pre-Phase A of the project lifecycle, the scope of architecture studies is broader and shallower than that of concept design studies conducted in Pre-Phase A. Results are used to advise senior planners on recommended capabilities and investment profiles for mission areas 15-25 years in the future.

Posted in: Briefs, Software, Architecture, Life cycle analysis, Systems engineering


Timeline Builder Assistant

Current human spaceflight requirements limit the number of hours a crewmember can be outside of the habitation unit to 8 hours in a 48-hour period, and 24 hours in a seven-day period. This time must be appropriately balanced to complete science, exploration, and maintenance tasks. Off-days can be used for site transit (traverse), crew rest, or intra-vehicular activities (IVA). The “building blocks” approach to mission design organizes crewmember activities for extra-vehicular activities (EVA) at each investigation site based on the types of tasks that must be completed and the tools required to complete each task. Building blocks colocate payload and crewmember information for timeline construction. Similar tasks or tasks that accomplish similar goals are grouped into blocks and distributed according to EVA requirements for a specified number of days, including allocations for site arrival activities and departure preparations.

Posted in: Briefs, Software, Computer software and hardware, Logistics, Personnel, Spacecraft


JPF-NAS Extension of Java Pathfinder

Java PathFinder (JPF) version 7 provides basic support for verifying the distributed Java applications. It can receive a distributed Java application as input that is perceived as multiple Java processes. However, JPF does account for communication between processes of the distributed application, and it thus cannot be used to verify any realistic distributed Java application. Applying JPF on distributed applications requires a model of inter-process communication (IPC) and process aware scheduling.

Posted in: Briefs, Electronics & Computers, Information Sciences, Software, Architecture, Communication protocols, Computer software and hardware


Institutional Budgeting Tool (IBT)

The Jet Propulsion Laboratory's Institutional Budgeting Tool (IBT) was designed and developed to meet the needs of JPL's budget planners, numbering 1,600, who required a robust and state-of-the-art budgeting application. JPL's budgeting process had been constrained by legacy tools that presented usability and performance issues and lacked critical innovative budgeting features. IBT delivered superior user experience, system performance, and modern features necessary for essential laboratory budgeting.

Posted in: Briefs, Electronics & Computers, Information Sciences, Software, Computer software and hardware, Financial management


Tubes Standards-Compliant C Header Library

Due to limitations imposed by transistor physics as device geometries continue to get finer and finer, the time when each new generation of processors was clocked faster than its predecessors is largely over. Nevertheless, as individual processor cores get smaller, chip manufacturers have turned instead to cramming a large number of cores onto a single die. Consequently, nearly all commercially available CPUs (central processing units), even those used in smartphones, already depend upon a multicore architecture. Unfortunately, the programming languages used for nearly all commercial software projects are really intended for generating code for a single CPU core. Though extensions exist that support multiple cores, it is something that is essentially tacked on, not part of the core language's constructs.

Posted in: Briefs, Electronics & Computers, Information Sciences, Software, Architecture, Computer software and hardware, Transistors, Terminology


The U.S. Government does not endorse any commercial product, process, or activity identified on this web site.