dino peer review january 12, 2004 dino peer review software - fall 2003 cory maccarrone

DINO Peer Review January 12, 2004

DINO Peer Review

Software - Fall 2003

Cory Maccarrone

Colorado Space Grant Consortium 2


Introduction - Purpose

1. Interface the user with the hardware (i.e. actuate the h/w through commands given directly or with a schedule).

2. Maintain the safety of the spacecraft (i.e. autonomously take mitigating actions to fix problems).

3. To support the ADCS code so that their requirements are met.

4. To provide software at all Ground Stations to facilitate decision making and sending commands to the spacecraft.



Components

• Flight Software (FSW) – Reusing base FSW modules from 3CS– Detailed review of FSW (Documentation Project)– The changes needed for Linux conversion.

• Spacecraft Command Language (SCL) – An off-the-shelf product used for CX, 3CS and SmartSat. – Overview of SCL software– The changes needed for DINO model.

• Virtual Mission Operations Control Center (VMOCC) –Reusing the existing architecture as our ground station. – Overview of VMOCC– The changes needed to incorporate DINO.



FSW Concept of Operations

The Flight Software (FSW) will take incoming commands and perform the task requested (i.e. getting sensor readings, processing images, sending files or other calculations).

• A command will be posted on the Software Bus (i.e. a system of message queues) by a user or by another process.

• All processes listening for this particular command will pick up a copy of the command and perform the task associated with that command.

• If the process has to talk with a piece of hardware, it will send the appropriate hardware command to the appropriate driver.

• If the process expects a response before proceeding, it will wait, otherwise it will continue with its tasks.

• The FSW is low level code that performs the tasks it is given. When done, it will return a status to the calling function.



SCL Concept of Operations

The SCL Real Time Engine (RTE) will perform the high level mission operations (i.e. decisions of which tasks to run, when to retry a task, when events are supposed to happen, etc.)

• SCL will ask the FSW to obtain sensor readings (Health and Status) periodically throughout the mission. This data is sent to SCL via a software bus message and stored in the database.

• As sensors change in the database, rules will watch the values and act appropriately.

• If a schedule of events is provided by Mission Operators, this schedule is carried out at the prescribed times.

• If an event is scheduled to occur and SCL decides that there are insufficient resources to perform this task (i.e. not enough power, not enough daylight, hardware not available, etc.), SCL will choose a new time to perform this task based upon built in heuristic methods.

• If a science event indicates that a follow-up event should happen, this unscheduled opportunity will be acted upon within SCL.



VMOCC Concept of Operations

VMOCC is a product already developed for use on two other satellite systems. It is a group of software products that is used to get data to and from the spacecraft. The software was designed to satisfy future missions such as DINO.

• Commands are received from users worldwide via a webpage.• Commands are concatenated into a schedule.• The schedule is sent to the spacecraft via the most appropriate

ground station.• Telemetry from the spacecraft is received via a trusted or public

ground site.• The telemetry requested from the spacecraft is forwarded back to

the user via a webpage.



Requirements

• The flight software should try to make use of: – Linux as the embedded kernel and operating system per C&DH

hardware support restrictions– SCL for command and control, performance evaluation, fault

management, and on-board replanning– FSW from 3CS missions for hardware interaction

• Multiple tasks shall be operated concurrently, namely, SCL, FSW tasks, etc…, as individual processes

• The flight software shall have the capacity to control the operational state of every hardware component: ADCS, COMM, C&DH, Power, Science, etc.



Requirements (cont)

• The flight software should support processing software for simple target recognition, data compression, and stereo targeting, depending on Science requirements

• DINO may be able to obtain stereo measurements by determining the observation timing and instrument pointing

• The flight software should be a basic, modular system that can be tailored as the mission evolves and include reusable libraries, classes, processes, and structures

• The on-board data system should support the migration of autonomy through tailoring of flight applications software and updates to procedures, rules, constraints, etc.



Requirements (cont)

• The on-board data system shall constraint check commands using SCL

• The on-board data system shall monitor the health and status of the DINO satellite and generate compressed data summaries

• The on-board data system shall provide for scheduled and interactive control of spacecraft operations, payload operations, resource usage, and data transport

• Operational constraints, rules, target synchronization, timeline, and algorithms shall be updated by users and autonomously as the situation allows

• The fight data system should generate spacecraft health and status data sets for storage and/or downlink



Requirements (cont)

Imposed by other subsystems

0. Perform all Mission Operation tasks. The appropriate actions will be taken for each command in the Command List.

1. Science analysis on an image may need to begin very quickly, depending on the algorithm

2. The Systems Team will want corrective action to begin within X seconds of receiving notice of a failure.

3. MOPS shall be able to perform all operations manually if SCL fails.



Requirements (cont)

Imposed on other subsystems0. Interfacing with all subsystem hardware shall be through

known device drivers such as serial, I2C, USB1. C&DH will provide at least 32 MB of NVRAM. 2. C&DH will provide at least 16 MB of RAM.3. C&DH will provide at least XX MIPS of processing

power (any modern board should work)4. Reading sensors of all subsystems will occur quickly

enough and with enough frequency to form a reasonable estimate of the operating state of the hardware it’s sensing.



Requirements (cont)

Imposed on ourselves:

0. FSW shall return status from all commands it performs.

1. All FSW modules shall be less than 50 kb to facilitate uploading to the spacecraft on orbit.

2. Test harnesses and/or a testing plan will exist for each command and sensor on the spacecraft.

3. Testing of error correcting algorithms to evaluate radiation corruption risk



Flow Charts – FSW Uplink

= H/W Interface

Rou

te_c

md

SC

L D

B

----

---I

OB

LK

----

--

I2C_mgr

serialmgr

usbmgrMCMD

CMDIN

ADCS

SCI

SWM

POWER

SCL RTE

----

---C

MD

BL

K--

----

BPGEN/COMM



Flow Charts – FSW Downlink

= H/W Interface

ADCS

BPGEN/COMM

SCI

SWM

POWER

Ret

urn

_rep

ly

TMOUT

SCL RTE

SC

L D

B

----

---C

MD

BL

K--

----

----

---I

OB

LK

----

--

I2C_mgr

serialmgr

usbmgr

MCMD



Detailed Review (FSW)

• ProcessTask (FSW base class)– Receives cmd within the CMDBLK from route_cmd.– Initial processing drops into the Process_Cmd

function.– Responses are sent to and received from hardware

through IOBLK.– Processing a response from hardware is handled

though Process_Reply– Returning a status for each command is through

Process_Reply.



Detailed Review (FSW cont)

• Hardware I/O managers (i.e. serialmgr, I2Cmgr, usbmgr)– All hardware I/O managers inherit a base IOMGR

class• Data passed to hardware through odata• Data passed from hardware through idata

– Wireless 802.11 devices will be serially connected and so will inherit serialmgr

– Hardware I/O managers implement the driver specific for their hardware

– Protocol for talking to hardware could be uni-directional or bi-directional.




• Communication protocol– TCP/IP based

• Satellite will have an IP address• Satellite will have password/firewall security

– Use standard telnet and ftp daemons• A broken FTP upload or download can be resumed on next

pass• Standard UDP broadcasts (H&S) can be received by any

computer with a radio

– Use built-in socket connections for SCL




• Science analysis - Cloud height algorithm– Find common points on two images

• One is a height reference• One is a rotation reference

– Triangulate the pixel changes– Notify SCL if we image a significant cloud formation

• Science analysis - Topo map algorithm– Cloud heights taken on grid points are combined into

file– Interpolation between points may be possible



RTE

S/C Model

Flow Charts - SCL

CMDIN TMOUT

database

Scripts

Incoming

data

Outgoing

data

Rules

FSW



Detailed Review (SCL)

• SCL (Overview)– A command comes in via a socket– The RTE decides what to do with it: immediate

command, run a script, run a FSW command– The SCL model contains:

• Scripts to execute mission objectives• Rules to fix problems

– The database contains records that hold sensor and derived information

– Telemetry is gathered from the database and sent to the ground



Detailed Review (SCL cont)

• SCL model (DINO model needed)– Scripts to execute mission objectives

• The ICD from each subsystem will enable us to create scripts to run their components

• Software needs commands, parameter, and timing information

– Rules to fix problems• The System Team will tell us what can be done if a sensor goes out

of limits

– Database definition• Each sensors from every subsystem will have an entry

• Each value we want to calculate (derive) will have an entry

• Each piece of hardware will have a field to store operational status



Flow Charts – VMOCC Uplink

MySQL

STK

Disk/ Files

SCLRTE

TMOUT

Webbrowser

ScheduledCmds Events

Schedules

Schedules

Cmds Pkts

= H/W Interface

Immediate Cmds



Flow Charts – VMOCC Downlink

Disk/ Files

MySQL

STK

SCLRTE

CMDIN

Webbrowser

Sensor dataOrbit data

Pictures

Sci data (pictures)

Pkts

H&S (ADCS)

H&S (All)Sci data

= H/W Interface



Detailed Review (VMOCC)

• VMOCC (overview)– Get commands from users worldwide– Deliver archived data (if it satisfies request)– Create a schedule for the satellite– Automatically initialize a radio (anywhere in the world)

and send the command– Accept telemetry from any radio in the world and

integrate into VMOCC model– Deliver requested data back to users



Detailed Review (VMOCC cont)

• VMOCC (changes needed)– Use TCP/IP protocol similar to CX– Ground database (MySQL) needed for telemetry

being sent– Ground SCL model (i.e. ground scripts and ground

rules) to alert mission operators of problems– STK model needed to get communication

opportunities, science data, and an attitude visualization

– Web interface (i.e. webpage) needed for commanding and receiving data



Commands and Sensors• Each subsystem will need

to give us an Interface Control Document to talk to their components

• Each subsystem will provide a sensor list of what they want to monitor. Software will support all of these sensors.



Commands and Sensors

• MOPS will provide a command list of what they want to accomplish. Software will support all of these commands.



Commands and Sensors

• Software and MOPS will work together to provide a telemetry packet structure for Health & Status



Test Plans

• Test Harness for each component– A suite of tests – All possible input values and test for the right output

• Minimum and maximum inputs• Day-in-the-Life (i.e. typical) outputs

– Typically a hardware test platform with software support



Test Plans (cont)

• Test Plan for each command– A suite of tests – All possible input values and test for the right output

• Minimum and maximum inputs• Day-in-the-Life (i.e. typical) outputs

– Typically a software test platform with hardware support



Parts List

• FSW process tasks– ADCS– BPGEN/COMM– Science– SWM– Power

• FSW I/O components– usbmgr– serialmgr– i2cmgr

• FSW science analysis– Cloud height algorithm– Topo map algorithm



Parts List (cont)

• SCL model– Rules– Scripts– Database definition

• VMOCC– Communication interface– Ground database (MySQL)– Ground SCL model (i.e. ground scripts and ground

rules) – STK model – Web interface (i.e. webpage)



Analysis / Prototyping

• Documentation Project

– Low-level documentation of the workings of the current flight software, including functions, variables, and the ways in which they interact

– Provides a detailed view of the software, including VxWorks specific functions that need to be ported to Linux

– Allows for the creation of other documentation, including flow charts, manuals (both technical and user), etc



Analysis / Prototyping (cont'd)

• Documentation Project– Currently the ProcessTask base classes have been

completely documented with VxWorks specific functions already identified

• Linux Base System– An ARM-based software system is in the works using

the Open Embedded building system– Includes base libraries (glibc, etc), base system (init,

bash/ash, busybox, rc-scripts, networking)– Many of these packages have already been built




• Linux Base System– Current binary base takes ~60mb (including

documentation and optional files)– Most of this can be reduced by removing unnecessary

documentation, images, and files (~40-50mb)– Extra packages for camera manipulation (gphoto2) will

be required (not built)

• Linux Kernel– Based on a vanilla 2.4.x kernel– Patches needed from Arcom for hardware




• Linux Kernel– Will initialize most / all flight computer hardware (serial,

usb, i2c, etc)– Kicks off initial software bootup (bring up networking,

user authentication, ..., flight software)



Linux vs. VxWorks Trade Study

• Advantages for Linux– Very modern operating system– Documentation / support freely available– Large software / hardware support base (including i2c,

usb, serial, misc I/O)– Modular design allows for easy manipulation and

modification of flight software– Support for many more exotic types of hardware

(prebuilt libraries for access to cameras, native support for the ARM architecture)



Linux vs. VxWorks Trade (cont'd)

• Advantages for Linux– Well documented and developed TCP/IP stack– Kernel is easy to develop & configure (menu-driven

interface)– Standardized UNIX shell environment– Standard gcc compiler can be used to produce both

x86 and ARM binaries




• Disadvantages for Linux– Very different development environment from VxWorks

• Protected memory model instead of completely shared• Will need to investigate alternative methods of interprocess

communication• Pre-emptive multi-tasker will require a split of the software due

to completely modular nature of Linux

– Requires a complete porting of current flight software– Installation of new software tools– Never before used by Space Grant– Not commonly understood by inexperienced coders




• Advantages for VxWorks– Flight software is already built and known to work– Tools already exist to develop binaries– No need to port software over– Memory follows a completely shared model

• No reworking memory usage, processes can communicate with each other easily

– Supported by a well-known company (Wind River)– Built to be an embedded OS

• Extremely compact and well-integrated• Hardware base is extensive (I2C, serial)




• Disadvantages for VxWorks– USB cameras are not supported at all

• Drivers would need to be written / interface boards built to interface with these cameras

• No existing software built for camera communication

– Kernel is very confusing and difficult to develop and configure

– Flight software can not be completely modular due to limited multi-tasking support

– Not well documented at Space Grant




• Disadvantages for VxWorks– Programming for it can be extremely difficult for

inexperienced programmers

• Final Decision– We will use the Linux operating system and software

for the flight computer.– Existing flight software will be ported from VxWorks to

Linux




• Final Decision– Flight software will be split into individual processes

• Modules will run as separate programs• Software that is not needed can be unloaded, freeing up

memory and CPU resources

– Interprocess communication will be updated to use Linux compatible methods

– Software libraries will be installed to operate the cameras

– Due to radiation concerns, flight software and libraries may be duplicated with a checking algorithm in place



Issues and Concerns

• Major coding efforts (i.e. lead times)– Porting FSW from VxWorks to Linux

• Address space• Interprocess communications

– Putting Linux on the board (i.e. BSP)– Developing a communications protocol with the

wireless serial->802.11b radios– Testing with hardware (never seem to get enough

time)

dino peer review january 12, 2004 dino peer review software - fall 2003 cory maccarrone

Documents