1. DINO Peer Review January 12, 2004 DINO Peer Review Software - Fall 2003 Cory Maccarrone

2. Colorado Space Grant Consortium2 DINO Peer Review January 12, 2004 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.

3. Colorado Space Grant Consortium3 DINO Peer Review January 12, 2004 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.

4. Colorado Space Grant Consortium4 DINO Peer Review January 12, 2004 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.

5. Colorado Space Grant Consortium5 DINO Peer Review January 12, 2004 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.

6. Colorado Space Grant Consortium6 DINO Peer Review January 12, 2004 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.

7. Colorado Space Grant Consortium7 DINO Peer Review January 12, 2004 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.

8. Colorado Space Grant Consortium8 DINO Peer Review January 12, 2004 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.

9. Colorado Space Grant Consortium9 DINO Peer Review January 12, 2004 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

10. Colorado Space Grant Consortium10 DINO Peer Review January 12, 2004 Requirements (cont) Imposed by other subsystems 1.Perform all Mission Operation tasks. The appropriate actions will be taken for each command in the Command List. 2.Science analysis on an image may need to begin very quickly, depending on the algorithm 3.The Systems Team will want corrective action to begin within X seconds of receiving notice of a failure. 4.MOPS shall be able to perform all operations manually if SCL fails.

11. Colorado Space Grant Consortium11 DINO Peer Review January 12, 2004 Requirements (cont) Imposed on other subsystems 1.Interfacing with all subsystem hardware shall be through known device drivers such as serial, I2C, USB 2.C&DH will provide at least 32 MB of NVRAM. 3.C&DH will provide at least 16 MB of RAM. 4.C&DH will provide at least XX MIPS of processing power (any modern board should work) 5.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.

12. Colorado Space Grant Consortium12 DINO Peer Review January 12, 2004 Requirements (cont) Imposed on ourselves: 1.FSW shall return status from all commands it performs. 2.All FSW modules shall be less than 50 kb to facilitate uploading to the spacecraft on orbit. 3.Test harnesses and/or a testing plan will exist for each command and sensor on the spacecraft. 4.Testing of error correcting algorithms to evaluate radiation corruption risk

13. Colorado Space Grant Consortium13 DINO Peer Review January 12, 2004 Flow Charts – FSW Uplink = H/W Interfac e Route_cmd SCL DB -------IOBLK------ I2C_mgr serialmgr usbmgr MCMD CMDIN ADCS SCI SWM POWER SCL RTE -------CMDBLK------ BPGEN/COMM

14. Colorado Space Grant Consortium14 DINO Peer Review January 12, 2004 Flow Charts – FSW Downlink = H/W Interfac e ADCS BPGEN/COMM SCI SWM POWER Return_reply TMOUT SCL RTE SCL DB -------CMDBLK------ -------IOBLK------ I2C_mgr serialmgr usbmgr MCMD

15. Colorado Space Grant Consortium15 DINO Peer Review January 12, 2004 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.

16. Colorado Space Grant Consortium16 DINO Peer Review January 12, 2004 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.

17. Colorado Space Grant Consortium17 DINO Peer Review January 12, 2004 Detailed Review (FSW cont) 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

18. Colorado Space Grant Consortium18 DINO Peer Review January 12, 2004 Detailed Review (FSW cont) 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

19. Colorado Space Grant Consortium19 DINO Peer Review January 12, 2004 RTE S/C Model Flow Charts - SCL CMDINTMOUT database Script s Incoming data Outgoing data Rules FSW

20. Colorado Space Grant Consortium20 DINO Peer Review January 12, 2004 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

21. Colorado Space Grant Consortium21 DINO Peer Review January 12, 2004 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

22. Colorado Space Grant Consortium22 DINO Peer Review January 12, 2004 Flow Charts – VMOCC Uplink MySQL STK Disk/ Files SCL RTE TMOUT Web browser Schedule d Cmds Events Schedules CmdsPkts = H/W Interfac e Immediate Cmds

23. Colorado Space Grant Consortium23 DINO Peer Review January 12, 2004 Flow Charts – VMOCC Downlink Disk/ Files MySQL STK SCL RTE CMDIN Web browser Senso r data Orbit data Picture s Sci data (pictures) Pkts H&S (ADCS) H&S (All) Sci data = H/W Interfac e

24. Colorado Space Grant Consortium24 DINO Peer Review January 12, 2004 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

25. Colorado Space Grant Consortium25 DINO Peer Review January 12, 2004 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

26. Colorado Space Grant Consortium26 DINO Peer Review January 12, 2004 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.

27. Colorado Space Grant Consortium27 DINO Peer Review January 12, 2004 Commands and Sensors MOPS will provide a command list of what they want to accomplish. Software will support all of these commands.

28. Colorado Space Grant Consortium28 DINO Peer Review January 12, 2004 Commands and Sensors Software and MOPS will work together to provide a telemetry packet structure for Health & Status

29. Colorado Space Grant Consortium29 DINO Peer Review January 12, 2004 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

30. Colorado Space Grant Consortium30 DINO Peer Review January 12, 2004 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

31. Colorado Space Grant Consortium31 DINO Peer Review January 12, 2004 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

32. Colorado Space Grant Consortium32 DINO Peer Review January 12, 2004 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)

33. Colorado Space Grant Consortium33 DINO Peer Review January 12, 2004 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

34. Colorado Space Grant Consortium34 DINO Peer Review January 12, 2004 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

35. Colorado Space Grant Consortium35 DINO Peer Review January 12, 2004 Analysis / Prototyping (cont'd) 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

36. Colorado Space Grant Consortium36 DINO Peer Review January 12, 2004 Analysis / Prototyping (cont'd) Linux Kernel –Will initialize most / all flight computer hardware (serial, usb, i 2 c, etc) –Kicks off initial software bootup (bring up networking, user authentication,..., flight software)

37. Colorado Space Grant Consortium37 DINO Peer Review January 12, 2004 Linux vs. VxWorks Trade Study Advantages for Linux –Very modern operating system –Documentation / support freely available –Large software / hardware support base (including i 2 c, 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)

38. Colorado Space Grant Consortium38 DINO Peer Review January 12, 2004 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

39. Colorado Space Grant Consortium39 DINO Peer Review January 12, 2004 Linux vs. VxWorks Trade (cont'd) 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

40. Colorado Space Grant Consortium40 DINO Peer Review January 12, 2004 Linux vs. VxWorks Trade (cont'd) 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 (I 2 C, serial)

41. Colorado Space Grant Consortium41 DINO Peer Review January 12, 2004 Linux vs. VxWorks Trade (cont'd) 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

42. Colorado Space Grant Consortium42 DINO Peer Review January 12, 2004 Linux vs. VxWorks Trade (cont'd) 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

43. Colorado Space Grant Consortium43 DINO Peer Review January 12, 2004 Linux vs. VxWorks Trade (cont'd) 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

44. Colorado Space Grant Consortium44 DINO Peer Review January 12, 2004 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)