Home
OpenSatKit provides a complete desktop solution for learning how to use NASA's open source flight software (FSW) platform called the core Flight System (cFS). The OSK Quick Start Guide is the best place to get an OSK overview and to start using its features. The cFS is a reusable FSW architecture that provides a portable and extendable platform with a product line deployment model. See the cFS Community for more information. As an open architecture, the cFS can be technically challenging for new users to configure and deploy. The cFS has significant flight heritage, provides a complete set of command and data handling functions required by most spacecraft, and is very reliable, so the return on time invested to learn it is worth it. The primary goals of the kit are to provide a complete cFS system to simplify the cFS learning curve, simplify the cFS deployment, simplify application development and integration into a cFS system, and assist in porting the cFS to a new platform. The cFS is a complex system so not every cFS feature is covered by the kit. A conscious effort was made to limit the kit’s complexity while supporting enough cFS functionality to allow a new user to successfully use the cFS with pre-configured applications.
The kit combines three powerful open source tools to achieve these goals: Ball Aerospace Corporation's COSMOS command and control platform for embedded systems, NASA's cFS ( NASA cFS Homepage), and NASA's 42 Simulator.
Follow these instructions to get started...
Currently only Ubuntu 18.04 LTS is supported. COSMOS is not compatible with Ubuntu 20.04. See OSK issue 31 and COSMOS issues 1169 and 1171 for details. To install OpenSatKit, copy and paste the following line in an Ubuntu terminal window to run the installation shell script. Root privilege is required to install and run OpenSatKit.
bash <(\wget -qO- https://raw.githubusercontent.com/OpenSatKit/OpenSatKit/vendor/install.sh)
Note when you try to run 'ruby Launcher' for the first time you'll get en error stating you need to run 'bundle install' which you should do. The 'bundle install' in the installation script doesn't seem to work and this issue is captured in OpenSatKit ticket 12.
If you have any problems with the installation don't hesitate to contact dmccomas63@gmail.com. OSK has many dependencies that sometime change wihtout notice.
Please be patient, the installation can take around 30 minutes depending upon your internet and computer resources.
Open a terminal window, change directory to OpenSatKit-master/cosmos, and launch COSMOS by typing "ruby Launcher". Next click the "cFS Starter Kit" button to launch the OpenSatKit home page.
Click the green "Start cFS" button to start the cFS. A new terminal window will open displaying the startup messages. The cFS runs in privileged mode so enter your user password when prompted. This window is not used to interact with the flight software (FSW), it only displays log/event messages written by the FSW.
All interaction with the FSW is through OpenSatKit Windows or the COSMOS command and telemetry server. The screen shot above shows the cFS apps included with the kit.
There are slide decks, videos and exercises for learnng the cFE and for how to write a cFS application. OSK comes pre-configured for a fictitious spacecraft called Simple Satellite(SimSat) that provides context for learning how to configure and use cFS applications to meet a mission's objectives. There are slide decks, videos and demos to support learning cFS apps. Learning material is integrated with OSK screens to provide an interactive learning environment that is relevant to a screen's context.
The cFS's 3-tiered architecture is shown below. NASA maintains the cFS Framework which is released under the Apache 2.0 license. The cFS user community including NASA contributes platform ports and applications.
OSK is considered a cFS Distribution. It's primarily a cFS learning platform but it can also be used as an application development environment and even reconfigured so the COSMOS front end interfaces to a remote target. This is a powerful application technology development environment because it supports a "write once run anywhere the cFS Framework has been ported" paradigm.
OSK comes pre-configured with the following SimSat applications. This 'lollipop' diagram depicts all of the applications communicating on the cFE's Software Bus with some external interfaces identified.
OSK provides tools for adding, removing, and creating new applications. The current OSK community applications include:
| Community Application | OSK v2.8 | Published |
|---|---|---|
| NASA/Goddard Checksum (CS) | 2.4.1 | 2.4.1 |
| NASA/Goddard Data Storage (DS) | 2.5.2 | 2.5.2 |
| NASA/Goddard File Manager (FM) | 2.5.2 | 2.5.3 |
| NASA/Goddard Housekeeping (HK) | 2.4.1 | 2.4.2 |
| NASA/Goddard Health & Safety (HS) | 2.3.0 | 2.3.0 |
| NASA/Goddard Limit Checker (LC) | 2.1.1 | 2.1.1 |
| NASA/Goddard Memory Dwell (MD) | 2.3.3 | 2.3.3 |
| NASA/Goddard Memory Manager (MM) | 2.4.1 | 2.4.1 |
| NASA/Goddard Stored Command (SC) | 2.5.0 | 2.5.0 |
Mission design is a complex process with many technical trades. This overview highlights the important steps and their relevance to FSW and the OSK. It primarily asks questions to help you think about your own situation. If you are interested in training or consultation services please send an email to OSK Support. It's helpful to consider both architectural views. The layered view shows that the cFE Framework must be ported to the mission's target platform.
The lollipop diagram shows which applications need to be developed for a mission.
The complexity of the FSW solution should correspond to the mission complexity. Maintain a balance between over simplification and “what if” scenarios postulating every conceivable problem or failure. There are challenges with operating and maintaining a remote system that need addressing and the cFS architecture and reusable apps help with many of them. The robustness, reliability, data retention, and diagnostics should focus on the mission objectives. For example, if it’s a tech demo mission then if possible record all of the relevant data associated with the demo and preserve it across processor resets.
2. What is the orbit (or orbits) and what communications will be available for each phase of the mission?
This will drive the data recording requirements.
The ADC accuracy often drives the real-time response and system synchronization requirements. Tight pointing requirements are often because of an instrument that will have similar real-time requirements.
The duration will influence onboard FSW maintenance and fault detection isolation and recovery requirement (FIDR) requirements
The processor, memory, and device interface selection criteria, are a combination of mission requirements and other subsystem (non-FSW) design constraints and interfaces. Project managers and engineers make trades between subsystems and far too often Size, Weight, and Power (SWaP) are the dominant trade criteria. FSW should have equal weighting and the entire mission lifecycle should be taken into consideration.
Use the resources at the cFS Community to understand which platforms are available from the cFS community. You will be responsible for developing the green components platform layer in the layered architecture diagram.
Once you start using the target board you can still use OSK but you will have to customize the interface between COSMOS and the cFS. The level of effort depends upon the platform’s hardware I/O and operating system. If the board supports Ethernet and the OS supports the IP stack then it is trivial.
As shown above OSK comes preconfigured with cFS apps (blue) and kit apps (yellow). You can use this environment to configure/test cFS apps for your mission, develop new mission apps, and develop preliminary mission system tests and operations scripts.
There’s nothing restricting kit apps or libraries from being used for a mission, but note that they have not been formally tested
Use the resources at cFS Community to understand which apps are available from the cFS community.
What ground system are you using for FSW development & test, spacecraft integration & test, and operations?
If you change ground systems you should define a strategy for command-telemetry definition translations and app table tool migration.