-
Notifications
You must be signed in to change notification settings - Fork 3
ORCA2Sat Requirements
This document outlines the design and implementation requirements of the OBC for ORCA2Sat.
Each requirement has an ID for tracking. Requirements are referred to as DRs, meaning "design requirements." Requirements can reference other requirements for clarity, but should stand on their own. Requirements should follow the EARS syntax, which basically just means that they are concise, clear, and encapsulate only the required information to determine their scope.
To add an unknown item, please tag it as todo: and wrap with [ ].
Conditions or signals can be defined as all caps such as OFF_STATE and can be used in requirements. They must have a DR that defines them.
Headings for requirements sections are H3, which use a ### prefix.
Design requirement IDs are H4, #### prefix.
The OBC will have enough nonvolatile storage to save 7 days of telemetry logs and flags with 40 % magin.
The OBC will have a realtime clock with minimum 1 second resolution.
The RTC will start counting at 0 upon the first system power-on (shortly after deployment from the p-pod).
The RTC shall be provided with a backup power source good for at least 7 days of backup power at the beginning of the mission.
[removed]
The RTC shall communicate with the OBC over an SPI interface.
The RTC shall have a customizable alarm with an ALERT pin that will go HIGH when the alarm triggers. The OBC will configure the alarm to generate the ALERT signal at some point (defined in seconds) in the future. The OBC can also cancel an alarm.
The OBC shall conform to the UVIC backplane standard and will be a single blade.
This is the STATE_SAFE condition. The following conditions will trigger entry into SAFE mode:
- A WD_RESET
- RTC time not incrementing
- No command received in 2 days
The STATE_SAFE condition is entered automatically upon WD reset or after any power cycle of the OBC.
In STATE_SAFE, the following tasks will run:
- BMS checker
- temperature logger
- [todo: others]
- BEACON_TX
In STATE_SAFE, the following tasks will be suspended:
- payload operations
- time-scheduled commands
In STATE_SAFE, the BEACON_TX task shall be executed. BEACON_TX will do the following:
- if power level permits, send out a standard telemetry packet 10 times with 5 seconds between packets, once every 5 minutes [todo: determine actual times]. This is used
STATE_SAFE can be exited into:
- STATE_READY by a command from the ground
- STATE_LOW_POWER upon battery SoC dropping below [todo: level]
This is the STATE_LOW_POWER condition. The following conditions will trigger entry into this state:
- battery SoC below 30 %
- command from the ground
The OBC shall have a LOW_POWER state that suspends all substantial activity [todo: define this better] and places the MCU in a low power state with wakeup conditions that are consistent with OBC.LP.2.
Note: this will probably use tickless idle
The LOW_POWER state can be exited on the following conditions:
- RTC ALERT
- Message received over the radio
The OBC shall utilize the FreeRTOS idle task hook to place itself in a lower power mode as frequently as possible.
The OBC shall run FreeRTOS version 10. Unless a critical bug fix comes out, the version will not be upgraded during the life of the project.
A task with maximum priority will be created to pet the external watchdog. It will be configured to run 2x as fast as the watchdog expires, nominally. This task can be suspended in an operation known as a WD_RESET.
This is the RTC_ERROR condition.
If the RTC ceases to function, a 1 second timer shall be started and used to increment the epoch. This will be driven by a state machine in the RTC driver. The 1 second timer will be used to increment the onboard epoch instead of the hardware RTC until the RTC_ERROR condition is cleared from the ground.
Interface drivers (CAN, SPI, I2C) shall be designed not to lock up. They must all have timeouts and report error codes if timeouts fail. All internal error registers will be checked in the driver functions.
All interface drivers will be protected from multiple accesses by a FreeRTOS mutex.
If upstream functions receive an error code from a driver, they must be able to continue operation. They shall log the error code and revert to default values.
Note: the interval for these items should be the same so they can nicely go into one task.
A check every [todo: interval] will ensure that the RTC time is incrementing. If RTC is not incrementing, STATE_SAFE will be invoked and RTC_ERROR will be invoked.
Flag file entries will be checked for consistency against the OBC's onboard flag struct. If they are not the same, the mismatch shall be logged as an error and STATE_SAFE entered. This check will occur at [todo: interval].
The OBC shall implement a file system for access to nonvolatile storage. The filesystem will allow creation, deletion and retrieval of files.
Two categories of files will be used. Log files will contain timestamped data. Flag files will be persistent and will contain backups of system configuration parameters.
All entries to log files will be automatically timestamped with the mission epoch at time of write.
An estimate of space remaining on the file system will be available by command.
A new set of log files will be created every 24 hours.
If there is insufficient space on the filesystem to support a write, the oldest set of log files will be deleted and a message logged.
The filesystem shall have a convenient, printf-style API for writing to telemetry log files.
The chosen filesystem library shall provide error checks and codes.
If a filesystem operation does not succeed, it shall not be reattempted. An error will be logged. A filesystem clean operation will be executed. A detected failure of a filesystem clean will not trigger another filesystem clean operation (this prevents loops).
The number of failed filesystem operations will be logged. If it reaches 5 since last hard reset, an attempt will be made to log the error. Then a WD_RESET will be invoked. The stdtelem error code will be set to FS_CRITICAL_ERR.
The OBC telemetry packet will consist of the following fields:
- stdtelem_error_code
- [todo: add other things]
The stdtelem_error_code is a prioritized error code that is kept in context without nonvolatile memory, with the idea being that it can be invoked even if external flash is not working.
It has the following fields, with priority 10 being highest (most urgent or critical) priority FS_CRITICAL_ERR - 10
Upon receiving a command from the ground, a software timer shall be reset. The timer shall have an expiry period of 2 days. If the timer expires, STATE_SAFE will be entered.
WIPE_AND_RESET command shall completely erase all nonvolatile memory and then issue a WD_RESET to promote re-generation of flag files.
The ability for the RTC_ERROR status flag to be cleared from the ground will be present.
A command shall be provided to read the current RTC epoch, regardless of RTC_ERROR status.
This is a placeholder for operational requirements.
Upon detecting FS_CRITICAL_ERR stdtelem_error_code, the ground crew will issue WIPE_AND_RESET command to the satellite after attempting to downlink data.