Linux on a Small Satellite
The core Copperfield-2 payload processor provides two key functions for the mission. First, it is a sensor system that receives sensed data, processes the data and interacts with onboard communications equipment to transmit the results to other sensors and ground stations. Secondly, it serves as a general-purpose computer system that provides the infrastructure for storage and data handling. In fact, multiple general-purpose processors are part of the Copperfield-2 payload, each communicating by way of an Ethernet network. A COTS Ethernet switch serves as the center of the star Ethernet architecture.
Table 1. TacSat-1 Copperfield-2 Ethernet-Connected Embedded Systems
|High-Speed Interface (HSI)||Bright Star Engineering (custom adapter board)||Linux 2.4 custom distribution||PowerPC MPC823|
|IDM UHF Modem||Innovative Concepts||Proprietary||PowerPC 860|
|Copperfield-2 MR.DIG Card||Aeronix/NRL||Linux 2.4 custom distribution (DENX ELDK-based)||PowerPC PowerQuicc II 8260|
|RF Front End Controller||Bright Star Engineering (custom adapter board)||Linux 2.4 custom distribution||StrongARM SA1110|
To capitalize on the Ethernet, TCP/IP, standards-based architecture of the UAV payload while remaining compatible with the satellite bus' legacy OX.25 interfaces—which provide a means for downlinking science data and state-of-health telemetry—a different embedded computer module was designed specifically to serve as the bridge. This module is called the high-speed interface (HSI) and provides a 2MB synchronous serial bus connected to the spacecraft communication controller. The HSI hardware is implemented as a combination of FPGA hardware and a BSE ipEngine general-purpose PowerPC 823 embedded processor.
In the HSI, the FPGA provides the hardware necessary to meet timing requirements for the data link, decoupling the processor from the synchronous data link. The PowerPC runs a Linux 2.4-based kernel, and the HSI FPGA interface is implemented as a standard Linux device driver. No special real-time extensions are used, and a Linux-based application provides the interface between the TCP/IP networking stack, using standard protocols and the device driver implementation. The HSI system allows multiple processes and Ethernet-connected computers to access the data stream sent to the spacecraft. The PowerPC communications controller on the Copperfield-2 processor easily could have handled the HSI tasks on TacSat-1. However, due to the extremely limited availability of hardware and the desire to increase parallel development opportunities, this interface was developed independently.
The most “custom” part in any satellite program often is the payload control software. Because many of the Copperfield-2 payload components with processors run Linux, interesting software options are available. Much of the payload software was implemented as bash (Bourne again shell) scripts. During the rapid development of the payload software, the philosophy was to attempt to divide the software development into two parts, custom and reused software modules. This philosophy called for minimizing custom code to limited functions and programs with specific purposes. Occasionally, we did find that existing utilities did not quite fit the requirements, and these were modified or replacements were written.
These specific custom programs and drivers allowed for control of payload elements through small command-line utilities that could be tested completely and easily in their limited functionality. These programs were developed with the UNIX command-line functionality in mind, along with data input through standard in (STDIN) and data output through standard out (STDOUT). Developing software utilities with interfaces such as these in mind has been the standard for many legacy operating system concepts from the earliest UNIX developments. We intended to continue that strategy and build upon it, as it provides an amazingly flexible way of constructing thorough capabilities with simple although powerful utilities.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python