Embedded Files
Software Block Diagram
Software Block Diagram
This block diagram represents the software architecture for the Flight Software on CDH. Software should be modular, as this makes it easier to design and test individual modules. Layering the software properly also makes the software easier to reuse or change. Arrows from one software module to another means “this module uses this module”.
The HAL (hardware access level) contains modules for talking to the hardware (i.e. CAN drivers, SPI drivers, GPIO drivers), and abstracts the low-level details of the hardware from the higher levels. Unique to the hardware.
The CAN and SPI “drivers” are already provided for our processor (which is expected). The CAN and SPI “modules” will abstract the low-level details and make the drivers easier to use.
The Platform Framework contains the rest of the modules that are needed for writing the application / operations. T
The Application layer contains the subsystems' applications. The PCU, ADCS, etc blocks are modules that are used to do the operations needed for these subsystems and to command or handle messages from those boards. Unique to the spacecraft.
Inter-subsystem Communication:
Inter-subsystem Communication:
The inter-subsystem communication is based on:
CAN for most of the subsystems including Power, Communication, and Payload.
SPI only for ADCS subsystem.
Thermal subsystem uses indirect connections to CDH through other subsystems.
CAN:
CAN:
The inter-subsystem communication using CAN (Controller Area Network) is based on the following network protocol stack:
Physical Layer: Messages between subsystems on the satellite are sent as frames over the CAN bus. The CAN specification includes bus arbitration, error detection, fault confinement, message priority, acknowledgement and message framing. All frames sent on the CAN bus must use 29-bit identifiers due to a silicon issue of the smart fusion. Frames with a lower identifier will win bus arbitration and therefore have a higher priority.
Data Link Layer[1]: The layer 2 protocol software defines a frame-format that is suitable for the media. The CAN interface included in the CSP library is used for sending messages longer than the 8 bytes allowed in a single CAN frame. This interface specifies a header, which is used as the 29-bit CAN id. The header format for the has a source and destination field. The first frame of a message is also marked in the type bit of the header, and the number of remaining frames and a message-unique identifier are also included.
Network Layer: The router core is the backbone of the CSP implementation. The router works by looking at a 32-bit CSP header which contains the delivery and source address together with port numbers for the connection. Each router supports both local delivery and forwarding of frames to another destination. There is no routing protocol for automatic route discovery, all routing tables are pre-programmed into the subsystems. The table itself contains a separate route to each of the possible 32 nodes in the network and the additional default route. This means that the overall topology must be decided before putting sub-systems together
Transport Layer: UDP or RDP?[JH1]
[1] These functions would be part of the transport layer according to the OSI model and most of the CAN features would be listed as the data link layer, but this classification is based on the CSP documentation.
[JH1]Not sure if we have to use these or not. It’s unclear from the csp documentation. Using udp would not really do anything for us, since all that functionality is included in the lower layers. RDP would add packet reordering, handshakes, etc, but more overhead.
CAN Network Addresses and Ports:
CAN Network Addresses and Ports:
Each subsystem has been assigned an address to be used for CSP. To stay consistent with the CSP documentation, all addresses with a leading 0 (less than 8) are on the spacecraft, and all addresses with a leading 1 are on the ground segment. Additionally the addresses were chosen with a lower address corresponding to higher priority.
[2] The default CSP address for the AX100 Radio is 5, so it must be changed to 3!
Within a CSP node, all messages are also filtered by the port number.
The following port numbers are the standard functions provided by any computer running CSP:
The following ports should be used across all subsystems using CSP:
CAN Commands
CAN Commands
Each command will have a 1 byte number that will identify the command. This along with the port number, completely specifies a command/telemetry packet. Each command has a fixed length which includes any parameters that are part of the command.
The most common parameter is a timestamp for any time-tagged task. The timestamp format is 8 bytes and is described in the rtc_common.h file:
Command List:
Command List:
A description of all commands is found here: https://docs.google.com/spreadsheets/d/1dhstFjEo2_i3Ru0mXuOIapyvm_8e9fw6OsJPqAwlkK8/edit?usp=sharing
The command codes will be described in command_codes.h
Inter-subsystem Telemetry
Inter-subsystem Telemetry
Each telemetry packet will have a 1 byte identifier that will identify the data. The identifier along with the port number, completely specifies a telemetry packet. Any telemetry packets received by the onboard computer will be timestamped and saved to long-term storage.
Between systems on the satellite:
When required the timestamped data will be sent to ground station, using the same identifier. To reduce overhead, data with the “same” timestamps will be combined and sent with one timestamp. For telemetry sent to ground, the packets consists of a timestamp followed by any number (up to 255 bytes total length) of identifiers followed by data.
Between satellite and ground:
SPI
SPI
ADCS subsystem uses SPI for communication.
Scheduling
Scheduling
During typical operation, a scheduler will be used to manage the tasks for the on-board computer, with 3 priorities of periodic tasks. Tasks should run only while tasks of higher priority are not running.
0. Interrupts - Interrupts are not periodic tasks, but they will execute at "higher priority" than all other tasks.
- Messages from radio/CAN should be placed into a queue via an interrupt mechanism.
1. High Priority Tasks - Tasks that should always occur when possible.
- Process messages received via radio.
- Transmit messages via radio.
- Operations control (i.e. management of spacecraft states).
2. Medium Priority Tasks - Tasks that should occur as often as possible, but have less strict timing requirements.
- Process messages received via CAN.
- Transmit messages via CAN.
- Service watchdog timer.
3. Low Priority Tasks - These tasks are not essential to the health and operation of the satellite, and therefore are placed lower priority than other tasks.
- Take payload readings and measurements, process them, and then store them in non-volatile memory (for later transmission).
- Store diagnostic data to non-volatile memory (for later transmission). Note that diagnostic data will be logged throughout the lifetime of the software.
At some point, when entering typical operations, data should be written to non-volatile memory, indicating that if a power reset occurs, to resume normal execution.
Data Reading, Ground Telemetry, Logging, Commands, and Tasks Document
Data Reading, Ground Telemetry, Logging, Commands, and Tasks Document
NOTE: The Payload data size is listed at 635355 for 2 images, at 92% crop. This was determined from a test conducted by the payload team using a 3D printed Payload EM and taking images of the sample plate from both camera locations and counting pixels of each sample. Payload verifications detail both the camera pixel test plan and test results.
Error Logging
Error Logging
All errors that are produced through the software will be assigned a unique 1-byte identifier. The error will be structured as an internal telemetry packet for transmission from the satellite systems to the onboard computer. This allows for data related to an error to be included if necessary. All received/generated errors will be timestamped and stored in long-term memory.
In order to work with existing software libraries, errors from each system should have a base value that is added to all internal errors. If the software of a system cannot be modified, the onboard computer will convert any error codes to global error codes. The following structure will be used for identifying errors
Based on these start values the internal error codes for each system are translated into global error codes. The errors are listed below, including the error name, internal identifier, global identifier, data and a description that can be used by the ground station to provide a human-readable notification.
CDH Error Codes:
POWER Error Codes:
Error Conditions
Error Conditions
Memory Corruption
If ROM (Flash) corruption is detected, the flight software is expected to:
1. Log the event.
2. If it cannot be corrected, discard the corrupted data.
If RAM corruption is detected, the flight software is expected to:
1. Log the event.
2. If it cannot be corrected, write any unsaved data to non-volatile memory.
3. Once unsaved data is saved to non-volatile memory, trigger a watchdog failure, thereby resetting the device.
Note: If RAM corruption is not "detected", 3 will presumably occur, as a lock-up will cause the software to stop functioning.
Power Loss
If power loss occurs (e.g. due to watchdog failure), the flight software is expected to:
1. Once powered back on, return to regular operation.
2. Log the event to non-volatile memory.
3. Check the health of other subsystems on the spacecraft.
Compression and Decompression
Compression and Decompression
Compression will be performed on the payload images and telemetry sent to ground. Compression will be performed before storing data in the long term storage flash memory prior to sending it to ground station. Currently, we are investigating the possibility of using FPGA for compression.
For image compression, the Huffman algorithm will be used to compress images by 37%. The compression technique is a two-step based compression technique called linear prediction coding. The first step predicts the pixel values in the image and the second step encodes the prediction error. In order to recover the image, these codes need to be decoded to recover the prediction error which can then be used to reconstruct the image. This is an efficient compression technique due to that there is much redundant information in an image and instead of encoding each pixel value it is more efficient to encode the differences between pixels. The differences contains the same information but may be encoded using shorter codewords [1].
Floating point number will use differential-finite-context-method predictor (DFCM) in our compression algorithm to perform 60% compression. It performs a table lookup using the hash as an index to retrieve the differences that followed the last two times the same hash was encountered. The retrieved differences are used to predict the next value by adding them to the previous value in the array. Once a prediction has been made, the predictor is updated with the true difference and value [2].
Reference
Reference
Datasheets: https://drive.google.com/drive/u/1/folders/1pkJzmoVMTWDInZiFpxeZwjKN1kCDA3s2
[1] M. Åhlander and A. Jonsson, “Hardware Efficient Lossless Realtime Compression of Raw Image Data,” May 2018. https://drive.google.com/file/d/1d5o6lNLK4MNPE_OxTTPmG1KPV7uvm2w1/view?usp=sharing
[2] P. Ratanaworabhan, J. Ke, and M. Burtscher, “Fast Lossless Compression of Scientific Floating-Point Data.” https://drive.google.com/file/d/1USx3YbSSkkYl9ygC2qo-aAN0ZsiI57qN/view?usp=sharing
Page updated
Google Sites
Report abuse