Rover II Software Functional Requirements

1	Main Vehicle Computer
1.1	General
1.1.1	Soft Real-Time control – RTOS not required, POSIX threads OK (Concept Design)
1.1.2	Time
1.1.2.1 The real-time clock on the main vehicle computer shall maintain GMT – using local time
1.1.2.2 The software shall log data with a GMT timestamp – using local time
1.2	Platform Control
1.2.1.1 Start-up Sequence- minimal
1.2.1.2 The MVC shall execute BIOS and load the operating system - done
1.2.1.3 The OS shall automatically execute the main vehicle application - TBD
1.2.2	Shutdown Sequence – During normal shutdown, the MVC shall execute a series of operations that place the vehicle in a “safe” state – controlled by scripts, not automatic or assured
1.2.2.1 The sequence shall include operations that return instrument platforms to a known safe state - TBD
1.2.2.2 During shutdown, onboard instruments will be allowed an opportunity to execute their own shutdown operations - TBD
1.2.3	Motor Control (Applies to motion control motors, not the stir motors)
1.2.3.1	All motors shall be PID tuned, moved with constant velocity control, and torque-limited to prevent mechanical and motor damage – PID, not torque limited yet
1.2.3.2 Motor current shall be monitored and over-current conditions shall be logged and displayed - TBD
1.2.3.3 Motor encoder position shall be displayed in counts, and degrees or millimeters at least once per second and logged for engineering analysis – not logged or displayed (Ethernet connection only – MARS) Needs clarification

1.2.4	Shall provide flexible and configurable control for autonomous operations (Concept Design)
1.2.4.1 Shall provide configurable vehicle navigation that considers both platform and environmental data – e.g. available power, current, tilt, heading, etc. (Concept Design) – needs clarification
1.2.4.2 Shall provide configurable control of standard platform components – e.g. cameras, scanners, scanning grid motors, lighting, optode, etc., to the precision required by science (Concept Design) – configuration file? Needs clarification
1.2.5	Shall monitor and log engineering data for mission operations and post-mission analysis – e.g. motor commands, mission and vehicle state, etc. (Concept Design) – Logging implemented
1.2.5.1 Shall maintain accurate vehicle state vector and accessors for external monitoring. – TBD (event channel, or monitor/communicator)
1.2.6	Shall have some level of power management, including ground fault monitoring (Concept Design) - TBD
1.2.7	Shall have the ability to upload data files to a client upon request. – using secure copy

1.3	Instrument Control
1.3.1	Software on the MVC shall log science data of interest from all standard onboard science instruments – e.g. Oxygen sensor (Concept Design) - Done
1.3.2	The MVC software shall support transparent serial mode (tunneling) for instruments for configuration and debugging (Concept Design) – needs clarification

2	Dry-side Computer
2.1	Mission Set-up and Management
2.1.1	There shall be an application supporting set-up of batch-mode missions including saving and loading mission scripts – configuration manager? Needs clarification
2.2	Vehicle Control
2.2.1	Shall be able to configure and test vehicle operations via TCP/IP or serial communication (Concept Design) - Done

2.3	Data Management and Transfer
2.3.1	Shall manage data files by mission and experiment - TBD
2.3.2	Shall be able to download mission data files from MVC - scp