Full article in PDF format - Estonian Academy Publishers
Contents
1. 20 C up to 80 C Various signal injection tests were performed on multiple engineering models and their components including short circuiting stuck at fault overvoltage reverse polarity application and electrostatic discharge Results of these tests indicated that 1 C devices were most susceptible to noise on data lines and incorrect signal level applications while the other devices continued to function without problems The performance of the CDHS was measured by running an in house implementation of a Kalman filter 24 with predefined input values The electric current consumption during the idle state with disabled peripherals is 47 mA During the active phase when memory devices are accessed constantly it increases to 54 mA During the sleep mode with wake up frequency of 1 kHz the average current consumption decreases to 30 mA Further improvements are possible with the implementation of the tickless sleep mode Vibration tests were performed according to the launch vehicle user manual of the launch provider Vega 25 The resonant frequency of the populated board dur ing the sweep scan was found to be at 383 Hz Sucha high resonant frequency can be explained by the design where the placement of the 120 pin connector and large components bus switches microcontrollers stiffens the construction The functionality test performed after the vibration tests revealed one non functioning flash memory module due to a loose sol2. Proceedings of the Estonian Academy of Sciences 2014 63 2S 222 231 doi 10 3176 proc 2014 2S 03 Available online at www eap ee proceedings ESTCUBE Design of the fault tolerant command and data handling subsystem for ESTCube 1 Kaspars Laizans gt Indrek S nter Karlis Zalite Henri Kuuste Martin Valgur Karl Tarbe Viljo Allik Georgi OlentSenko Priit Laes Silver L tt P and Mart Noorma 2 Tartu Observatory Observatooriumi 1 61602 T ravere Tartumaa Estonia b Institute of Physics Faculty of Science and Technology University of Tartu T he 4 111 51010 Tartu Estonia Received 15 August 2013 revised 26 February 2014 accepted 7 March 2014 available online 23 May 2014 Abstract This paper presents the design implementation and pre launch test results of the Command and Data Handling Subsystem CDHS for ESTCube 1 ESTCube 1 is a one unit CubeSat which will perform an electric solar wind sail experiment The development process of the CDHS for ESTCube 1 was focused on robustness and fault tolerance A combination of hot and cold hardware redundancy was implemented Software including a custom written internal communications protocol was designed to increase the system s fault tolerance further by providing fault detection and fall back procedures Tests were carried out to validate the implementation s performance and physical endurance The final CDHS design is operational within the set req
3. ability approaching that of space qualified alternatives Nevertheless little attempt has been made to present a CDHS design that incorporates the aforementioned ideas advances in microelectronics and CubeSat design specifications On Delfi n3Xt satellite basic on board computer functions were to be implemented on a micro controller at the primary radio transceiver 14 CanX 1 had error detection and correction on external memories and an implemented boot strap code for carrying out basic spacecraft operations in the case of failure 6 AAUSAT 3 avoided single points of failure by adopting a decentralized design philosophy where each subsystem has enough processing power and data storage to carry out its tasks 15 In this paper we present a CDHS design with an improved fault tolerance scheme for ESTCube 1 16 a one unit CubeSat which will perform an electric solar wind sail E sail 17 experiment Great emphasis during the ESTCube 1 project was put on fault tolerance which resulted in the development of robust subsystems including a CDHS Here we describe the requirements that were derived from both the general CubeSat specifications and the specific scientific mission We propose a combination of hot and cold hardware duplication redundancy methods as a possible solution for improving CubeSat fault tolerance Software solutions ensure further reduction of risks by detecting failures and executing fall back procedures Finally r
4. software is considered to be fault tolerant when the CDHS remains operable after experiencing software or hardware faults Fault tolerance of the CDHS software does not necessarily include the ability to continue the operations that were interrupted by a fault 4 2 Operating system and drivers FreeRTOS was chosen as the operating system for the CDHS mainly because of its low Flash and RAM footprints and low performance overhead On the CDHS FreeRTOS takes about 11 KB of Flash and 64 KB of RAM most of which is reserved for the heap of dynamic memory management On top of a minimalistic hardware abstraction layer for STM32F1 and STM32F2 peripheral and device drivers were implemented for FreeRTOS The Universal Asynchronous Receiver Transmitter UART IC and SPI drivers each have a daemon running in the background which processes enqueued transactions and propagates the error codes back to the caller For the CDHS and the CAM exception handling was implemented in C 4 3 File systems In order to fulfil the storage requirements on the CDHS two types of files are needed 1 image files for CAM photos and calibration tables and 2 circular journal files for housekeeping log entries mission data and buffering telemetry For these types of files it is unnecessary to buffer block contents before erasure Image files are erased and rewritten as a whole whereas journal files are erased and overwritten block wise oldest entries fi
5. 2010 67 1289 1298 Rennels D A Architectures for fault tolerant spacecraft computers Proc IEEE 1978 60 1255 1268 Aalbers G T Gaydadhiev G N and Amini R CDHS design for a university nano satellite In Proc 57th Int Astronautical Congress Valencia 2006 AC 06 B5 7 05 McLoughlin I V Gupta V Sandhu G S Lim S and Bretschneider T R Fault tolerance through redundant COTS components for satellite processing applications In Proc 2003 Joint Conf of the Fourth Int Conf on Multimedia 2003 1 296 299 de Jong S Aalbers G T and Bouwmeester J Improved command and data handling system for the Delfi n3Xt nanosatellite In Proc 59th Int Astronautical Congress Glasgow 2008 IAC 08 D1 4 11 Nielsen J D and Larsen J A A decentralized design philosophy for satellites In 2077 5th Int Conf Recent Advances in Space Technologies RAST Istanbul 2011 543 546 L tt S Slavinskis A Ilbis E Kvell U Voor mansik K Kulu E et al ESTCube 1 nanosatellite for electric solar wind sail in orbit technology demonstration Proc Estonian Acad Sci 2014 63 2S 200 209 Janhunen P Toivanen P K Polkko J Merikallio S Salminen P Haeggstr m E et al Electric solar wind sail toward test missions Review Sci Instruments 2010 81 111301 1 11 Slavinskis A Kvell U Kulu E S nter I Kuuste H and L tt S High spin rate magnetic controller for nanosa
6. Payload high voltage CAM Fig 2 Data channels of the CDHS ADCS Attitude Determination and Control Subsystem COM Communications subsystem EPS Electrical Power Subsystem CAM Camera subsystem USART Universal Synchronous Asynchronous Receiver Transmitter SPI Serial Peripheral Interface C Inter Integrated Circuit 226 Proceedings of the Estonian Academy of Sciences 2014 63 2S 222 231 Gyroscope 1 i Gyroscope 2 if Magnetometer ausse SS ADC 3x FRAM SPI1 SPI2 2x back up SS ADC CDHS 2 Flash memory Gyroscope 1 Payload HV Backup Gyroscope 2 Backup 2x Flash magnetometer memories SPI3 FRAM Fig 3 Peripheral device distribution on data buses 1 C 2x FRAM EEN Inter Integrated Circuit SPI Serial Peripheral Interface FRAM Ferroelectric Random Access Memory ADC Analogue to Digital Converter SS Sun Sensor HV High Voltage RTC Real Time Clock According to SN74CB3Q16211DL bus switch specifications each device can be considered as con sisting of a relatively small number of Field Effect Transistors FETs order of magnitude lt 100 which makes it a low density device A probability of such a low density device experiencing a radiation induced single upset event is much smaller than the same event happening within a microcontroller 3 5 Storage Storage of the CDHS and CAM firmware images pictures telemetry and science data is one of the m
7. and number of errors will be recorded On the ground these data will be correlated to the solar activity In future missions improvements could be made to the subsystem to ease the implementation of advanced functionality and increase fault tolerance Processor core with an inbuilt floating point unit support cold redundant memory units based on microSD cards ability to power down or power recycle parts of the subsystem could be considered to be able to resolve a single event latch up in one device without having to power cycle the whole CDHS ACKNOWLEDGEMENT This research was supported by the European Social Fund s Doctoral Studies and Internationalisation Pro gramme DoRa REFERENCES 1 CubeSat Design Specification Rev 12 The CubeSat Pro gram Cal Poly SLO California 2009 2 Woellert K Ehrenfreund P Ricco A J and Hertz feld H Cubesats Cost effective science and technol ogy platforms for emerging and developing nations Ady Space Res 2011 47 663 684 3 Cutler J Bennett M Klesh A Bahcivan H and Doe R The radio aurora explorer a bistatic radar mission to measure space weather phenomenon In Proc 24th Annu Small Satellite Conf Logan Utah 2010 4 Deschamps N C Grant C C Foisy D G Zee R E Moffat A F J and Weiss W W The BRITE space telescope using a nanosatellite constellation to measure stellar variability in the most luminous stars Acta Astronaut 200
8. due to its higher throughput The routing mechanism of the ICP is very simple due to both the simple network topology and the tight RAM constraints Routes from one subsystem to another are manually and statically defined as a list of data links to be attempted ordered by preferability After a packet sending times out and is re sent a predefined number of times on a data link usually three sending via the next data link in the routing table is attempted Since only a single loop exists in the network topology infinite loops are avoided by refusing to route a packet through the subsystem from which the packet originated The user is only acknowledged of a successful delivery of a packet over a data link and not of a delivery to the intended destination to keep the protocol lightweight 4 5 Command scheduler Commands received by the CDHS are scheduled by priority or executed immediately The satellite s internal command structure supports for three different priorities low high and immediate For low and high priorities separate scheduler queues are used There is no queue for commands of immediate priority On each scheduler update either an immediate command is handled or a command is fetched from either the low or high queue It is guaranteed that high priority commands are handled twice as often as low priority commands and that no more than a single command is executed on each scheduler update Commands received by the CD
9. the current injected into the bus by another microcontroller By default both processors are isolated from all peripherals and I O lines When the MCU is powered up from the EPS the respective bus switch logic is enabled allowing signals to pass through Care must be taken to avoid bus switch logic being enabled for both microcontrollers at the same time In this case signals would be drained by the inactive MCU Physically outputs from bus switches are tied together making a single input on the peripheral Each MCU has its own set of bus switches through which peripherals are connected Unlike the typical signal division where MCUs share one bus switch this approach helps to alleviate the risk of a single bus switch causing the CDHS to fail as well as keeps current consumption to a minimum because only half of the bus switches are active simultaneously K Laizans et al Fault tolerant CDHS for ESTCube 1 229 Data and I O Main processor Power A On Peripheral 1 i meaa eea EPERERA ne Peripheral 3 EPS On Peripheral power Bus switch 2B Bus switch 3B OO Os cs on n e nn Power B Off Backup processor Fig 1 Bus switch logic control via processor power buses I O Input Output EPS Electrical Power System COM ramming pins Power 2XSPI S ADCS 2xI C USART EPS CDHS Heartbeat Motor control Feedback Payload motor contro SPI 12C Peripherals Snapshot Voltage control
10. 9 65 643 650 5 10 11 12 13 14 15 16 T7 18 19 Proceedings of the Estonian Academy of Sciences 2014 63 2S 222 231 Borgeaud M Scheidegger N Noca M Roethlis berger G Jordan F Choueiri T et al SwissCube the first entirely built swiss student satellite with an Earth observation payload In Small Satellite Missions for Earth Observation Sandau R Roeser H P and Valenzuela A eds Springer 2010 207 213 Sarda K Eagleson S Caillibot E Grant C Kekez D Pranajaya F et al Canadian advanced nanospace experiment 2 scientific and technological innovation on a three kilogram satellite Acta Astronaut 2006 59 236 245 Hamann R J Verhoeven C J M Vaartjes A A and Bonnema A R Nano satellites for micro technol ogy prequalification the delfi program of delft university of technology In Selected Contributions of the 6th IAA Symposium on Small Satellites for Earth Observations Berlin 2007 319 330 Nielsen J F Larsen J A Grunnet J D et al AAUSAT II A Danish Student Satellite 7 S A S Nyusu 2009 Nielsen J D and Larsen J A Experiences and lessons learned during the Launch and Early Orbit Phase LEOP of AAUSAT 3 In 5th European CubeSat Symposium Book of Abstracts Brussels 2013 Scholz A Ley W Dachwald B Miau J J and Juang J C Flight results of the COMPASS 1 picosatellite mission Acta Astronaut
11. HS are enqueued for handling in the command scheduler task Although the satellite s internal command structure supports commands of three different priorities this feature was rarely used and has been dropped from the command scheduler in favour of simplicity Commands scheduling other commands are used to provide support for looped execution and conditionals All commands are stored with a Fletcher 16 check sum and queue entries with invalid checksum are discarded To avoid memory corruption the whole queue is cleared in the case of invalid queue entry lengths Clearing the queue stops active operations and prevents corrupt commands from being executed A date time scheduler is used for executing com mands at specified date and time Date time commands are attached to FreeRTOS millisecond timers and handled from the woken command scheduler task Task wake up time can be up to 1 millisecond Due to possible clock drifts in the microcontroller cumulative error might be caused in the FreeRTOS timers configured for long periods of time The effects of microcontroller clock drifts shall be monitored in orbit 4 6 Custom bootloader For both the CDHS and CAM a custom bootloader was designed and implemented The bootloader allows for copying a firmware image from an external FRAM device and booting into a boot image chosen by the EPS It processes a list of bootloader commands stored in the FRAM and logs status to a page in a microcontroll
12. ain tasks of the CDHS Three fast Spansion SF25FL 128 Mbit SPI Flash memories are used for the storage of non critical data such as logs of housekeeping and mission data camera images etc Five Ramtron FM25 series ferroelectric 2 Mbit SPI Random Access Memory RAM modules store firmware images ADCS constants scheduler queues and file system metadata for which data integrity is crucial For redundancy purposes memory devices are placed on all three SPI buses Fig 3 i e the subsystem internal memory bus and two SPI buses shared with the ADCS Use of shared buses for redundancy purposes was deemed to be an acceptable risk due to the fact that the probability of high density internal SPI peripheral breaking down is much higher than the probability of a bus becoming unavailable due to a damaged low density secondary device 22 Since the CDHS has external memory devices connected via serial buses structures or variables in the external memory cannot be addressed directly This poses an additional challenge for software development All external memories are shared between both CDHS microcontrollers and memory contents need to be back wards compatible with the different firmware images stored on board the CDHS These features could be considered risks which are minimized by extensive testing and use of safe fall back default configurations for cases when backwards compatibility issues arise 3 6 Real time clock Tether unreeling a
13. der joint connection No other damage was observed after two repeated tests Acceptance and qualification tests for launch were done on the system level 16 25 The purpose of the thermal vacuum test was to measure the change in temperatures during the operation of the subsystem and to ensure that radiative and conductive heat dissipation were sufficient to keep the subsystem within the operational temperature range 229 during uninterrupted operations Physical connections of the subsystem for heat exchange consist of a main system bus connector total conductive surface area of 43 5 mm and four corner mounts 27 3 mm with the total area of around 70 mm which is negligible compared to the heat capacity of the PCB Temperature measurements were performed in a vacuum chamber at the level of 10e 4 mBar which is enough to remove convectional heat dissipation The engineering model of the subsystem was placed on a special aluminium heat transfer plate that emulates total heat capacity of the satellite Contact between the heat transfer plate and the device tested was maintained only via special mounting rods through PCB corner mount slots which represent the real assembly installation Two calibrated temperature sensors were used one placed on the microcontroller and the other on the aluminium heat transfer plate In addition the internal RTC temperature sensor and the internal microcontroller temperature sensor were tested Temperatu
14. er Flash Before an attempt to boot a firmware image its cyclic redundancy is calculated and compared against the one stored in the firmware image header Without any bootloader commands or in the case of a problem with the FRAM the bootloader selects the default firmware based on the CDHS firmware select pin that can be toggled via the EPS K Laizans et al Fault tolerant CDHS for ESTCube 1 5 HARDWARE TESTING Several tests were carried out to ensure that the CDHS is able to survive the launch and operate in the space environment These included functionality tests performance and current consumption tests as well as physical tests such as vibration and thermal vacuum tests During these tests only hardware fault tolerance meaning the ability to remain functional in the case of physical or electrical damage to components was considered Functionality tests are a set of basic unit tests to ensure that hardware is functioning as intended These involve communication tests with all attached devices read and write tests on memory devices and the operating system with device drivers and error logging The microcontroller supports overclocking of up to 128 MHz while remaining stable at room temperature Instabilities of the overclocked microcontroller start to appear when the operational environment temperature exceeds 50 C At nominal 72 MHz frequency the device is able to operate within the ranges set in the specifications from
15. esults from pre flight tests are presented and discussed 2 REQUIREMENTS 2 1 Satellite design requirements From a mission specific perspective the CDHS on board ESTCube 1 is required to handle data needed for controlling the satellite and for the E sail experiment 16 The experiment involves a centrifugal unreel ing of a 10 m long conductive tether Next a 500 volt potential is generated on the tether to observe its 223 interaction with ionospheric plasma The observation will be carried out indirectly by estimating changes in the satellite spin rate Estimation is performed using a Kalman filter with readings from magnetometers Microelectromechanical Systems MEMS angular rate sensors and analogue sun sensors The implementa tion of the Kalman filter on ESTCube 1 requires the input data measurements to be carried out 2 5 times per second 18 Furthermore the CDHS has to 1 store data from the Camera subsystem CAM in the form of multiple binary images of up to 600 KB each 2 store housekeeping data of all subsystems and 3 compile the beacon and data packets for downlink For redundancy purposes direct connections from all subsystems to the CDHS are preferred to sequential or daisy chain type As a backup method direct connections between the subsystems bypassing the CDHS have to be implemented Thus a non functioning subsystem cannot hinder the operation of any other node This can be used in case the CDHS is re
16. nd camera image trigger events during the mission have to be scheduled with a timing accuracy of 100 ms A processor independent external RTC is needed to periodically synchronize millisecond timers that are used for scheduling the CDHS events and commands MAX DS3234 RTC which is connected to the internal SPI bus Fig 3 was implemented This device has integrated temperature compensated crystal oscillator and voltage reference Since the only device on the satellite directly powered by the batteries is the EPS the start up sequence of the CDHS had to include K Laizans et al Fault tolerant CDHS for ESTCube 1 Fig 4 Populated board bottom side the polling satellite date and time from the EPS and reconfiguring its own RTC 3 7 Printed circuit board and manufacture The CDHS is assembled on a six layer R1755V Medium Tg 170 Printed Circuit Board PCB Fig 4 No blind or buried vias are used to avoid their dislodging and short circuits generated by free floating via material Board cut outs were needed to provide space for sun sensor cabling to the ADCS The dimensions of the assembled board are 92 mm x 94 mm x 8 6 mm and the mass of the populated board is 48 54 g 4 SOFTWARE DESIGN 4 1 General design The CDHS software has been designed to be configur able in orbit and to tolerate failure of attached devices From the CDHS device configuration table external ferroelectric RAM FRAM Flash memories SPI RTC and micr
17. ndered unusable or as a redundant communication channel if the primary data bus is damaged According to Bouwmeester and Guo 19 an Inter Integrated Circuit C communication bus has been favoured for the design of small satellites How ever a bus busy state can occur while using the C for inter subsystem communications If one or more subsystems are powered down during the communica tions a mismatch in open drain collector configurations of devices can occur which can lead to the bus busy state blocking the whole bus Other bus types used on small satellites are Universal Serial Bus USB and Controller Area Network CAN bus The USB consumes much power while the CAN bus is not supported by many devices For these reasons the USB and CAN were not selected for ESTCube 1 Due to physical limitations of the satellite with a worst case power production of 2 W a 180 mW average and 250 mW peak power consumption constraint for the CDHS was set by the Electrical Power Subsystem EPS 20 To ensure lower power consumption the use of 3 3 V supply for the whole system was adopted at the cost of higher susceptibility to noise The general trend of commercial off the shelf devices is to reduce voltages even further with higher supply voltage devices becoming obsolete To diminish the influence of digital noise on the signals the use of analogue signals has been discouraged Furthermore physical requirements were introduced primarily b
18. ocontroller internal peripherals can be enabled or disabled individually In the case a device failure is detected on startup the device is disabled automatically A table of integer variables is used for setting processor clock frequency fall back modes for error logging and command scheduler beacon transmission period and other CDHS operational parameters Coefficients required for attitude determination and control are stored in a table of floating point values Configuration variables are grouped by linker regions which allows them to be easily synchronized with internal Flash pages making changes non volatile A safe fall back configuration is applied automatically in the case a corrupted active configuration passes CDHS limit checks 221 and causes the CDHS to reset six times without sending a single telemetry frame to the ground For error logging once the system has at least partially recovered again there are multiple levels of storage to ensure the delivery of the list of errors Errors during boot up or interrupts are stored in a RAM section that retains its contents till the next CDHS power recycle After the initialization of the external FRAM memories and file systems the list of errors is appended to a larger error log file Software induced fault tolerance by means of modular redundancy was not used due to the per formance requirements and restrictions for the use of Flash and RAM In the scope of this paper the CDHS
19. rd ing the satellite life time schedule and functionality which enables implementation of unplanned tasks in orbit Such an approach allows for additional experi ments with different attitude control algorithms and varying manners of detection of radiation effects on electronic devices In order to improve the fault tolerance of the system it must be possible to enable disable and configure CDHS software components Configurability also pro vides some flexibility without the need to upgrade the firmware 3 SATELLITE DESIGN AND FAULT TOLERANCE IMPLEMENTATION 3 1 Fault tolerance One of the main classic methods of increasing hardware fault tolerance is having hardware redundancy or multiplication of essential parts and components rather than modular result weighing Having one of the duplicated or triplicated components damaged might lead to different results depending on the general system architecture either the system switches and starts to use another component cold redundancy or it experiences loss of performance while maintaining functionality graceful degradation of the hot redundant system 21 A blend of a mixed hot cold redundant system with software fault check routines is used to create a system with enhanced fault tolerance 3 2 Microcontrollers Two STM32F103 Microcontroller Units MCUs are used in cold redundancy mode and switched by the EPS Switching on one of the MCU s power buses powers up the MCU i
20. re measurements were performed every 10 to 30 min while running the Kalman filter program The cooling of the prototype was done with a stream of evaporated liquid nitrogen as a heat removing transfer agent from the aluminium heat exchange plate During the cooling phase the temperature of the heat exchange plate dropped by 35 C while the board temperature as registered by both the RTC and microcontroller internal sensors dropped by 8 C The heating of the board was performed for an hour after the cooling phase using an infra red lamp located underneath the heat exchange plate A steep rise in the base plate temperature of 100 C was observed for half an hour then the CDHS PCB started to absorb heat energy in much higher amounts than it was able to radiate into the surrounding environment The temperature of both the MCU and RTC rose by 40 C which is not critical After the removal of the heat source all sensors cooled down indicating successful heat dissipation The whole process took about five hours which is approximately three times longer than the expected orbital period Temperature fluctuations in orbit should not be as severe and operational conditions are expected to be at 30 of the test values The built in temperature sensor was found to be imprecise due to the unstable reference voltage Effects of thermal noise on the reference voltage source were found to be relatively large up to 5 of 1 3 V Other device inb
21. rgi Olent enko Priit Laes Silver L tt ja Mart Noorma On kirjeldatud ESTCube 1 k su ja andmehalduss steemi projekteerimist selle tehnilist lahendust ning stardieelseid katsetusi S steemi arendamisel p rati erilist t helepanu selle robustsusele ja veatolerantsusele Riistvara kom ponentide puhul rakendati kombinatsiooni kuumast ja k lmast liiasusest Tarkvaras realiseeriti protseduurid vigade avastamiseks ja vea korral s steemi t korra taastamiseks Lisaks riistvara t kindlusele simuleeritud rikete korral testiti ka k su ja andmehalduss steemi f silist vastupidavust laias temperatuurivahemikus ning kontrollitud vibrat siooni tingimustes Artiklis on v lja pakutud ideid s steemi veatolerantsuse kontrollimiseks orbiidil
22. rst Additional simplifications were made 256 files per file system hard or soft links no directories filenames are numeric and files are of constant length It was also decided to have only one volume per file system Since the CDHS has only 96 KB of static RAM most of the available Flash file systems could not be used The Transactional Flash File System was found to have exceptionally low requirements for RAM less than 200 B On the other hand this system assumes a not OR NOR Flash memory with Single Level Cells to re program individual bits of a Flash page The 228 Proceedings of the Estonian Academy of Sciences 2014 63 2S 222 231 S25FL128P NOR Flash used on the CDHS is manu factured on MirrorBit technology Furthermore because of the limited amount of static RAM and the need for file systems for three serial NOR Flash devices with multiple bits per cell and six FRAM devices custom Flash and RAM file systems with a low memory footprint had to be developed The Flash file system counts bad bytes and blocks by reading back the data written to the Flash Mismatched bytes are recorded in the file system metadata Single bytes are corrected on file reads If more than ten bad bytes are detected in a single block the block is marked as a bad block Bad blocks are skipped on read and write attempts resulting in data loss The number of detected bad bytes and bad blocks shall be monitored in orbit As FRAM is more radiation
23. tellites Acta Astronaut 2013 95 218 226 Bouwmeester J and Guo J Survey of worldwide pico K Laizans et al Fault tolerant CDHS for ESTCube 1 and nanosatellite missions distributions and sub system technology Acta Astronaut 2010 67 7 8 854 862 20 Pajusalu M Ibis E Ilves T Veske M Kalde J Lillmaa H et al Design and pre flight testing of the electrical power system for the ESTCube 1 nanosatellite Proc Estonian Acad Sci 2014 63 2S 232 241 21 Johnson B W Fault tolerant microprocessor based systems IEEE Micro 1984 4 6 6 21 22 Fleetwood D M Winokur P S and Dodd P E An overview of radiation effects on electronics in the space telecommunications environment Micro electronics Reliability 2000 40 1 17 26 251 23 Wrachien N Advanced memories to overcome the flash memory weaknesses a radiation viewpoint reliability study Ph D dissertation Dept Inf Eng Padova University Padova Italy 2010 24 Slavinskis A Kulu E Viru J Valner R Ehrpais H Uiboupin T et al Attitude determination and control for centrifugal tether deployment on the ESTCube 1 nanosatellite Proc Estonian Acad Sci 2014 63 2S 242 249 25 VEGA User s Manual Issue 3 2006 France ESTCube 1 veatolerantse k su ja andmehalduss steemi projekteerimine Kaspars Laizans Indrek S nter Karlis Zalite Henri Kuuste Martin Valgur Karl Tarbe Viljo Allik Geo
24. tions 2 Advances in miniaturized integrated circuit technol ogies have improved environmental tolerances stability and functionality while decreasing the size and reduc ing power consumption of satellites Such satellites as RAX 3 BRITE 4 SwissCube 5 CanX 2 6 Delfi C3 7 AAUSAT II 8 AAUSAT 3 9 and COMPASS 1 10 have demonstrated the versatility of CubeSats for fulfilling a variety of missions With the increasing K Laizans et al Fault tolerant CDHS for ESTCube 1 scientific importance of CubeSat missions fault tolerance is now becoming critical However while the topic has been covered for larger spacecraft since the beginning of the space age 11 redundancy and fault tolerance of the Command and Data Handling Subsystem CDHS on board micro and nanosatellites are yet to be discussed The fundamentals of the fault tolerant CDHS for CubeSats can be drawn largely from several decades of experience acquired by designing and operating large spacecraft As discussed by Rennels 11 avail ability of commercial off the shelf single chip micropro cessors allows for implementing several processors for redundancy purposes Furthermore it allows for a dis tributed system design with fault recovery algorithms 12 This general approach is also presented by McLoughlin et al 13 who propose a parallel archi tecture that enables commercial devices to be incor porated into a computational unit with the total reli
25. tolerant than the Flash memory the file system metadata and system files are stored on FRAM 23 4 4 Internal communications protocol A Satellite wide Internal Communications Protocol ICP was designed in addition to USART communications The ICP was loosely based on the asynchronous version of the High Level Data Link Control HDLC and is used by the EPS CAM Communications subsystem COM and the CDHS for inter subsystem data and command transfer The protocol covers both data link and network layers of the Open Systems Interconnection OSI model The ICP s design was mostly constrained by the EPS 16 MHz clock frequency 2 KB of RAM dedicated to ICP and no operating system The developed ICP inherits the HDLC s framing mechanism packets are delimited by 0x7E and any 0x7E and 0x7D bytes occurring inside a packet are XORed with 0x20 and have 0x7D added before them Similarly to HDLC a 16 bit Fletcher s checksum is computed from the packet header and the payload is included in the tail of the packet To ensure a reliable in order delivery of packets the Go Back N Automatic Repeat Request ARQ data transmission protocol a variant of sliding window protocol with the transmit window size of N and receive window size of 1 is used on direct links The transmit window size is configurable with a maximum size of 8 packets The Go Back N ARO was preferred over the simpler stop and wait ARQ protocol transmit window size of 1
26. tself and drives the logic to enable the corresponding peripheral lines through the bus switches Fig 1 All the devices are available for both MCUs as hot redundant enabling access to them by the other MCU as a backup processor in the case the main one is damaged 3 3 Data buses Direct connections between all subsystems and the CDHS were designed Fig 2 In particular magneto meters and 3 axis MEMS angular rate sensors were duplicated in cold redundancy Fig 3 Readings from six sun sensors are digitized by two Analogue to Digital Converters ADCs and sent via two separate Serial Peripheral Interface SPI buses Due to the limited amount of buses available the SPI buses have to be shared between the Attitude Determination and Control Subsystem ADCS and the CDHS internal memories and the Real Time Clock RTC Universal Synchronous Asynchronous Receiver Transmitter USART communications were chosen for communication between subsystems which have their own MCU because it is robust and supported by the majority of microcontrollers Apart from the standard USART FC and SPI buses additional digital Input Output I O signals are needed for subsystem specific control and feedback 3 4 Switching All buses and peripheral lines are connected to both microcontrollers via SN74CB3Q16211DL bus switches Bus switching is required in the case two MCUs are connected directly in parallel and the inactive MCU is able to sink all of
27. uilt thermal sensors were found to be more accurate due to lower internal thermal variations 6 DISCUSSION AND CONCLUSIONS An operational CDHS was developed and tested for ESTCube 1 Redundancy and fault tolerance were emphasized during the development process While the pre launch tests carried out were not specifically designed to test the fault tolerance of the system test 230 results indicate that a robust system has been developed The CDHS operates in a stable manner within the physical limits set before development Furthermore thermal vacuum tests did not indicate any problems with either the vacuum environment or the ability to dissipate heat generated by the subsystem Tests confirmed that excessive heat build up in vacuum which could disrupt operations of the system was not probable Even in case of direct infrared radiation heat the capacity of the board was high enough to withstand heat build up for a period of multiple orbits Accumulated heat was rapidly dissipated via infrared radiation and thermal exchange through the physical connections Temperature cycles did not impact performance and during the cycles changes in power consumption remained below 5 In the future regular in orbit functionality and memory integrity tests will be performed to acquire data on the reliability performance and radiation tolerance of the design In addition changes in current consumption communication latencies number of resets
28. uirements Tests that verify fault tolerance of the system in orbit are suggested Key words command and data handling subsystem fault tolerance redundancy nanosatellite CubeSat ESTCube 1 Acronyms and abbreviations ADC Analogue to Digital Converter ADCS Attitude Determination and Control Subsystem ARQ Automatic Repeat Request CAM Camera subsystem CAN Controller Area Network CDHS Command and Data Handling Subsystem COM Communications subsystem EPS Electrical Power Subsystem E sail Electric solar wind sail FET Field Effect Transistor FRAM Ferroelectric Random Access Memory HDLC High level Data Link Control FC Inter Integrated Circuit I O Input Output ICP Internal Communications Protocol MCU Microcontroller Unit MEMS Microelectromechanical System NOR Negative OR logic function OSI Open Systems Interconnection PCB Printed Circuit Board RAM Random Access Memory RTC Real Time Clock Corresponding author kaspars laizans estcube eu SPI Serial Peripheral Interface SS Sun Sensor UART Universal Asynchronous Receiver Transmitter USART Universal Synchronous Asynchronous Receiver Transmitter USB Universal Serial Bus XOR Exclusive OR logic function 1 INTRODUCTION Since the introduction of the CubeSat standard 1 small satellite development has seen rapid growth encompassing an increasing number of na
29. y the CubeSat standard for outer satellite dimensions of 10 cm x 10 cm x 10 cm with additional constraints for internal satellite structure derived from those Table 1 Mass and environmental parameter estimates were set in early Phase B of the satellite development based on the preliminary design The vibration tolerance requirements were derived from launcher specific documentation 224 Proceedings of the Estonian Academy of Sciences 2014 63 2S 222 231 Table 1 Constraints for the internal structure of ESTCube 1 Requirement parameter Maximum value Dimensions 94 mm x 92 mm x 18 mm Mass 60 g Operating temperature 10 to 70 C Vibration tolerance sine 2258 PSD random 18 g shock 1410 g 2 2 Software requirements Logging housekeeping and mission data boot loader events warnings and errors has been set as the main task of the CDHS Part of the mission would be carried out above the Earth s poles with no direct communications available Thus the command scheduler must be able to execute time specific commands unsupervised The on board software of the satellite is not required to be autonomous All operations that involve a risk must be started manually or it must be possible for the satellite operator to stop these operations and disable them permanently The ability to upgrade the CDHS firmware via an access port device at the launch site as well as in orbit is needed In flight upgrades also provide flexibility rega
Download Pdf Manuals
Related Search