Space Shuttle Mission 2007 Hack Tool
Ingelore Clason
PyCubed is an open-source, radiation-tested CubeSat avionics platform that integrates power, computing, communication, and attitude determination and control functionality into a single low-cost PC104-compatible module programmable entirely in Python.
POC: sup...@pycubed.org
SatLib is a python library for constellation based calculations. Much of it is based on Poliastro and extends it for use with satellite constellations. Fundamental functionality such as propagating constellations, determining constellation access to ground stations, and determining when satellites in the constellation have windows of opportunity to perform inter-satellite links are included in the library. The main classes are contained in satbox.py and instructions to run an example notebook that showcase some of the capabilities are included below. Note: This library is still under development.
POC: Manwei Chan
SPRINT can be used to simulate the actions of a constellation by utilizing crosslinks to consolidate data to be downlinked at scheduled times. It schedules, plans, and replans the activities of large Earth-observing satellite constellations under changing conditions. The SPRINT framework seeks to maximize observation data, minimize latency, and autonomously adapt to unexpected events. This is done by utilizing crosslink capabilities on the satellites, a master ground planner, and onboard local planners on each satellite.
POC: Kerri Cahoy
Virtual Constellation Engine is a cloud framework to prototype and emulate line-of-sight, latency, and bandwidth of satellite applications. It provides support for orbits calculation, instrument control, and constellation monitoring (positions, CPU/memory/disk/network usage, configuration changes made to the emulated onboard instruments).
POC: Marco Paolieri
ORDEM offers flux as a function of debris size and year. The technology can be operated in spacecraft mode or telescope mode. An upgraded user interface uses project-oriented organization and provides graphical representations of numerous output data products.
POC: NASA JSC
The Trajectory Browser is a website hosted at NASA Ames Research Center. It has an enabled search engine, a visualizer, and mission summaries for designing trajectories to planets and small-bodies, asteroids and Near Earth Objects (NEOs).
POC: Andres Dono Perez
This website is managed by experienced astrodymanists (John Carrico and Mike Loucks) who supply trajectory related articles on mission design and operations, trajectory solving solutions and design using STK/Astrogator, launch targeting, trajectory files, tutorials, and STK scenarios.
POC: John Carrico and Mike Loucks
SPICE supports CubeSat and smallsat missions and offers the following capabilities: trajectory planning, mission engineering analyses, planning an instrument pointing profile, observation geometry visualization, and science data archiving and analysis.
POC: Boris Semenov
F Prime is a managed, open-source and flight-proven flight software development ecosystem developed at the NASA Jet Propulsion Laboratory that is tailored for small-scale systems such as CubeSats, SmallSats, and instruments. F Prime comprises several elements: an architectural approach that decomposes flight software into discrete components with well-defined interfaces that communicate over ports; a C++ framework providing core capabilities such as message queues and an OS abstraction layer; a growing collection of generic components for basic features such as command dispatch, event logging, and memory management that can be incorporated without modification into new flight software projects; and a suite of tools that streamline key phases of flight software development from design through integrated testing.
This tool predicts Single Event Effects (SEE). It has been almost a decade since the introduction of CREME96, the current state-of-the art tool for SEE rate prediction. CREME96 uses phenomenological models to predict SEE rates. These models were based on two assumptions. First it was assumed that the ionization trail left by the particle was much narrower than the minimum feature size in the microelectronic circuits. Second, it was assumed that the SEE sensitivity of individual microcircuits could be idealized as being due to a single sensitive junction. The cross section of this junction versus the linear energy transfer (LET) rate of the ionizing particle could then be measured and used to estimate the SEE rate. Since CREME96 was developed, the minimum feature size has shrunk by more than a factor of 100. As a result, the interaction between track microstructure and device characteristics can no longer be ignored. This assumption in CREME96 has been shown to have significant shortcomings when applied to new and emerging technologies like advanced complementary metal-oxide-semiconductor (CMOS), silicon-germanium heterojunction bipolar transistors (SiGe HBT), photodiodes, and infrared (IR) focal plane arrays (FPAs). The solution is to replace current models in CREME96 with a physics-based model that correctly accounts for the distribution of energy deposition about the track and the possible existence of multiple sensitive junctions in each microcircuit.
POC: Brian Sierawski
Over 1000 NASA released software packages covering: Project Management, System Testing, Operations, Design, Vehicle Management, Data Processing, Propulsion, Structures and Mechanisms, Crew and Life Support, Materials Processes, Electronics and Power, Environmental Science, Autonomous Systems and Aeronautics.
Successfully building, flying, and maintaining the space shuttles was an immensely complex job that required a high level of detailed, precise engineering. After each shuttle landed, it entered a maintenance, repair, and overhaul (MRO) phase. Each system was thoroughly checked and tested, and worn or damaged parts replaced, before the shuttle was rolled out for its next mission.
During the MRO period, workers needed to record exactly what needed replacing and why, as well as follow precise guidelines and procedures in making their repairs. That meant traceability, and with it lots of paperwork.
The strain of such inefficiency was bad enough that slow electrical repairs jeopardized rollout on several occasions. Knowing there had to be a way to streamline operations, Kennedy asked Martin Belson, a project manager with 30 years experience as an aerospace contractor, to co-lead a team in developing software that would reduce the effort required to document shuttle repairs. The result was System Maintenance Automated Repair Tasks (SMART) software.
Knowing that the Space Shuttle Program would be ending in several years, Belson decided in 2007 to start planning for life after NASA. He spent his spare time building a business, eventually incorporated as Orlando, Florida-based Diversified Industries (DI) C&IS Inc., with the long-term goal of applying the expertise he gained at NASA to commercial products.
NASA filed a patent for SMART in 2007, and in 2011 it granted DI a license on the product. Now licensed, and armed with his intimate knowledge of the program, Belson adapted the software for general aviation, including commercial and military markets.
SMART is primarily a discrepancy resolution and unplanned maintenance tool that automates many of the steps required to determine the correct action for a specific repair. The software draws on a preapproved library of repair procedures to guide technicians, providing them with a decision tree that lists a sequence of predefined actions, tools, parts, and materials appropriate for a given problem.
I was a NASA contractor working on the same contract, but with 3 different companies, writing GN&C code for the space shuttles from 1989 until 1995. Initially, it was Ford Aerospace, then Loral, then Lockheed-Martin. IBM was the prime most of that time. It has been a long time since I did any work like that, so don't hold what I write below as gospel. Memories of a middle-aged guy.
The Shuttle OS isn't general purpose. It is purpose built, designed to be loaded with 1 program, instruction pointer set to 0 and then started running. I honestly don't know how that worked, since we never touched any of the flight computers. I've only seen photos and recently saw one inside a glass case at a museum. When I worked there, we didn't have access to the computers directly. Because the computing hardware is modified IBM 360-based systems, that is the machine language used by all the main systems. There were 5 GPCs - general processing computers. During ascent and landing, 4 ran the PASS - Primary Avionics System Software and 1 ran the BFS (backup flight software). The BFS was written and maintained by a different contractor, Rockwell. I know nothing about the BFS except it was never used. Heard rumors that eventually that contract was canceled because the PASS was of such high quality there wasn't any need for the BFS. Perhaps someone from Rockwell can answer?
The vast majority of programming for the GPCs was written in HAL/S. This is a compiled language similar to PL/1, but with matrix calculation extensions and a multi-priority scheduling system. Basically, it supported 254 threads, but we only used 3. HFE, MFE, LFE - Hi, Mid, Low Frequency Executives. The priority was H, M, L as well. HFE ran at 25Hz. MFE ran at 12.5Hz and Low ran at 0.5Hz. Mid-instruction, a higher priority could interrupt a lower one. It was important to leave time so that lower priority tasks would have sufficient time to run. Some complex guidance code would overrun the allotted time and had to be highly optimized. Since these were real-time systems, a late answer is just a bad as a wrong answer.
The PASS software ran in a redundant set with break points along the code paths (managed outside our application code). Periodically, each computer would get to a checkpoint and compare with the other computers in the "redundant set". Basically, they would vote. Majority rule. Any computers outside the majority would be dropped and all future values from that one would be ignored. If only 2 systems are in the redundant set and they disagree, the computer which arrived first was deemed correct. I don't believe they ever had fewer than 3 GPCs running. Basically, only 1 was dropped over code path disagreements (1996 and earlier). I don't know anything after 1996 when I left the NASA area.
b1e95dc632