built using low cost Commercial Off The Shelf components, that everybody could buy and assemble from a kit. AraMiS (acronym for Modular ...... a dedicated path other than the Cross-Bus medium to achieve the desired performance. This is ... built-in web server running on the processor can be used to monitor the system ...
58th International Astronautical Congress , Hyderabad, India, 24 - 28 September 2007. Copyright IAF/IAA. All rights reserved.
IAC-07-B4.7.09
MODULAR ARCHITECTURE FOR SATELLITES Stefano Speretta, Leonardo M. Reyneri, Claudio Sanso´e, Maurizio Tranchero, Claudio Passerone, Dante Del Corso Dipartimento di Elettronica Politecnico di Torino Corso Duca degli Abruzzi, 24 10129 Torino — ITALY ABSTRACT Avionics for satellites is a market which is continuously growing in these years, especially thanks to the availability of low cost launch vectors. This cost reduction enabled many institutions (industries but also universities) to develop their own satellites. A first result of this process was the CubeSat concept: a really small satellite, built using low cost Commercial Off The Shelf components, that everybody could buy and assemble from a kit. AraMiS (acronym for Modular Architecture for Satellites in Italian) is a project that wants to go beyond the CubeSat concept and create a true modular architecture, in particular in the electronic subsystem. Our main idea is the development of distributed and intercommunicating on-board units, built with COTS components, in order to increase fault tolerance and allow a graceful performance degradation, while keeping the costs at acceptable levels. The satellite can use as many basic modules as needed to perform the tasks of the mission. Since the same module design is used in several satellites, the AraMiS architecture achieves an effective cost sharing between different missions.
I. I NTRODUCTION Today the industrial and academic interest in space and space-related activities is rapidly growing. A costeffective access to space would open a wide range of new opportunities and markets, especially for SMEs (Small Medium Enterprise) and Universities, which otherwise cannot access space due to high cost. Lower costs would allow to test on the field (that is, in space) theories and ideas which would otherwise be unaffordable to do. Unfortunately, the cost-effective access to space, which is also envisaged by ESA, is still many years ahead. There is still a lack of devices, circuits, systems suited to develop satellites, ground stations and related services at costs compatible with the budget of academic institutions and SMEs. As soon as the development time and cost of small satellites will fall below a certain threshold (e.g. 100,000 to 500,000 euros), appropriate business models will likely develop to ensure a costeffective and pervasive access to space, and related infrastructures and services. This is the major reason for our activity described in this paper, which is aimed at: 1) proving the feasibility of low-cost satellites using COTS (Commercial Off The Shelf) devices; this is a new trend in the space industry, which is not yet exploited due to the belief that COTS devices are not reliable enough for the application;
2) developing a flight model of a flexible and reliable nanosatellite with less than 25,000 e; 3) training students in the field of avionics space systems; the design is developed by a team containing at least 50% of undergraduate students working towards their graduation work. The educational nature of our activity has therefore been one of the leading objectives and brought to the development of specific university courses; 4) developing expertise in the field of low-cost avionic systems, both internally (university staff) and externally (graduated students will bring their expertise in their future work activity); 5) gathering expertise and resources which were available inside our university around a common high-tech project. The first step in this direction was the development of a small low cost nanosatellite, which started in the year 2004: the name of this project was PiCPoT [1], [2] and it was performed by some departments of our university, in particular the Electronics and the Aerospace departments. The main goal of the project was to evaluate the feasibility of using COTS components in a space project in order to greatly reduce costs; the internal subsystems modularity was also a key goal to allow a further cost reduction for future missions. Starting from the PiCPoT experience, in 2006 we began a new project called AraMiS[3] which is the
Telecommunication (see sect. IX), which are composed mostly of: i) a microcontroller-based programmable transceiver; ii) a 437 MHz or 2.4 GHz modem; iii) a power amplifier (for transmission) and low-noise amplifiers (for reception); iv) an antenna system. At least one such tile is placed as one of the faces of the satellite, preferably pointing to ground, and takes care of reliable data and command exchange to/from ground. The user, who needs not take care of any telecommunication detail, sends/receives data, via the internal data busses (see sect. VI), to/from this tile and, consequently, to/from ground, in a completely transparent manner. The inner tiles can be of many types. At present we are developing only one of them: • On-board processor and payload support (see sect. VII, VIII), which takes care of all data handling for housekeeping, and interfaces to the userdefined payload. This tile has some CPU power and memory available for the user, such that simple payloads may use it instead of having their own processor.
Italian acronym for Modular Architecture for Satellites. The paper describes the architecture of the AraMiS satellite and its operations, giving some details of the major subsystems.
•
II. G ENERAL A RCHITECTURE The most effective way to reduce the cost of a nano- or micro-satellite mission is to reduce as much as possible design and non-recurrent fabrication costs, which usually account for more than 90% of the overall budget. Reducing them can be achieved only by sharing the design among a large number of missions. Design reuse is the rationale behind the AraMiS project, that is, to have a modular architecture based on a small number of flexible and powerful modules which can be reused as much as possible in different missions. Using the same module(s) more times obviously allows to share design, qualification and testing costs and to reduce the time-to-launch. The first step in the AraMiS project has been to identify the most common and critical subsystems. We have then concentrated our efforts on the following subsystems, which are described in details in the rest of this paper: i) mechanical subsystem; ii) power management subsystem; iii) telecommunication subsystem; iv) on-board processing subsystem; v) payload support; vi) ground segment. The basic architecture of AraMiS is based on one or more modular intelligent tiles. Most of them are to be regularly placed on the outer surface of the satellite and have a double function: mechanical (see sect. III) and functional (see sect. V and following). The inner part of the satellite is mostly left empty (except for the onboard processor and payload support tile), to be filled by the user-defined payload, which is the only part to be designed and manufactured ad-hoc for each mission. Each tile is designed, manufactured and tested in relatively large quantities. Reuse also allows to put an increased design effort to compensate for the lower reliability of COTS devices, therefore achieving a reasonable system reliability at a reduced cost. The outer tiles are of two types: •
III. M ECHANICAL S UBSYSTEM The mechanical subsystem of AraMiS, which is intended for very-low cost nano- and micro-satellites, should be as simple as possible, at least for smaller satellites. The basic idea of the AraMiS project is that the outer tiles should also have structural properties, that is, they are a significant part of the mechanical subsystem. This allows to reduce the overall weight and cost and should also simplify assembling and testing of the satellite. Of course this idea is intended for small satellites (that is, with side not longer than 50 cm). We have achieved this aim by: 1) standardizing the size of the tiles: 15×15 cm2 . We have decided not to use the CubeSat [4] standard, as it was felt to be too much constraining for larger satellites, while not offering significant advantages for the intended applications. 2) using a self-bearing 1.5 mm thick anodized Al, which is also the mechanical support for solar panels, batteries, antennas, processors, PCBs, etc. (depending on the tile); 3) having screw holes at 15 mm apart, which ensures high mechanical strength together with an excellent electromagnetic sealing also at 2.4 GHz; 4) reducing the rest of the mechanical subsystem to one 6 × 6 mm2 Al square rod per edge, which is screwed to the outer tiles, fixing them together, as shown in fig. 1; 5) having a very simple internal mechanical frame, which is fixed to the external mechanical frame,
Power management (see sect. V), which are composed mostly of: i) a solar panel; ii) a rechargeable battery to store energy; iii) a battery charger; iv) a microcontroller-based housekeeping module to keep track of voltages, currents and temperatures inside the tile; v) an active magnetic and/or inertial asset control. An appropriate number of such tiles (depending on power requirements of the mission) are placed around a cubic or prismatic shape (or displaced after satellite release) and represent a pre-designed and pre-assembled modular power management subsystem. 2
to hold the predefined on-board processor and the user-defined payload hardware and circuits (if any). This choice allows a certain degree of freedom in the shape and size of the satellite. A few possibilities are listed below: 3 • smallest cubic shape (15 × 15 × 15 cm satellite): 5 power management tiles plus one telecommunication tile, together with 12 rods; one internal processing tile and the user-defined payload. About 1,000 cm3 are available for the payload. If the payload requires access to the external satellite surface (e.g. a small camera), two are the solutions: i) using the available free part of the telecommunication tile; ii) substituting one power management tile with an empty Al plate. • larger cubic (or prismatic) shape (15n × 15m × 15q cm3 satellite, as shows in fig. 2, where n, m, q are integer values): each surface is made of n × m or m×q or n×q tiles, either power management or telecommunication or payload-specific. Sides with at least 2×2 tiles require a cross-shaped rod; one or more internal processing tiles and the user-defined payload. More than nmq · 1, 000 cm3 are available for the payload. • small hexagonal/octogonal satellite: six/eight power management or telecommunication tiles with two hexagonal/octogonal Al sides (possibly telecommunication or payload-specific). • larger satellites (larger than 50 cm in side) can still be assembled with an appropriate number of tiles but they require a stiffer mechanical frame to survive vibrations during launch.
Fig. 2: The mechanical structure of a larger AraMiS satellite with m, n, q = 2 and two telecommunication tiles.
In detumbling mode, the controller is responsible of dumping the initial angular velocity which the launcher gives the satellite upon release: only after this preliminary phase the real stabilization phase could begin. In stabilization mode the actuators are used to control the orientation of the satellite to align antennas toward the Earth while in spin compensation mode the controller is responsible of compensating the satellite spin-axis rotation. Sensors are dual-axis magnetometers and photodiodes, both housed on Power Management tiles: data are collected by the OBC which also executes the attitude stabilization algorithm. Corrections to the attitude are sent to Power Management tiles, which control the actuators. For orienting the satellite we used a combination of magnetic torquers and small reaction wheels: all the actuators mounted on a single tile are 1-axis but, connecting all the tiles together we get a 3 axis stabilization.
IV. ATTITUDE C ONTROL S YSTEM
V. P OWER M ANAGEMENT
The Attitude Control System (ACS) is used to stabilize the spacecraft against attitude disturbing influences resulting from the environment in the Earth orbit and in order to orient the satellite in the desired direction. First of all, it is necessary to define the modes of operations of this system: • Detumbling, • Stabilization, • Spin compensation.
This module is responsible for gathering power from solar panels and control the energy storage process in order to grant an adequate power level to all subsystems during the orbit. Furthermore it is responsible for scheduling the power-on time for all the other subsystems, to reduce the overall power consumption, and it also houses the attitude control sensors and actuators, as described in section IV.
Fig. 1: A detail of the mechanical subsystem of AraMiS: the external panels screwed to the mechanical structure.
Fig. 3:
3
Power Management Tile (external view).
two different signals (solar panel voltage and current) and then multiply them in order to get the power. In AraMiS we adopted both these control strategies because they allow an accurate maximum power tracking and the use of two different control systems reduces the probability of common mode faults (see [5] for further details). We in fact developed an analog mean temperature MPPT, built with bipolar technology components in order not be prone to latch-up events and a digital maximum power MPPT implemented using a low power TI MSP430 microcontroller [6]: both systems act as a single controller increasing fault tolerance. The analog controller is always available but it suffers from errors in the characterization of solar cells which leads to small losses in tracking the maximum power point. The digital controller is instead not always available (due to possible latch-up events) but it is able to correct the maximum power point extimated by the other controller to reduce losses.
A. Power generation and Storage As for most satellites, the main power sources are solar panels: in AraMiS they are mounted all around the satellite to reduce the complexity of mechanical assembly (see Fig. 3). Since they are mounted on different faces, experiencing different light and thermal conditions, their output power is highly variable: we therefore need a separate solar panel controller for each of them and this controller should be as small and lightweight as possible. Since our goal is to use COTS components to build a highly reliable system we need to implement different strategies to keep the cost as low as possible and to increase fault tolerance. The basic Power Management tile is therefore made of a solar cell, its control electronics, a rechargeable battery and the Al-alloy panel which holds everything together and encloses the satellite. All these basic units are connected with a power bus to share the generated power and with a communication channel to exchange system status information (see section VI-B). The power generation system is therefore really modular, since it is composed by this tile, replicated as many times as needed to get the desired power. All these tiles work in parallel and this redundant solution helps also from the fault tolerance point of view, making the system able to tolerate multiple faults and allowing a graceful performance degradation. For example, if we put onboard two different payloads with different power consumptions, when all the Power Management tiles are working, we are able to use both payloads; if some of the power generating modules get faulty, we are still able to use one of the payloads. The system is still running but with reduced performances. The solar panel controllers (SPC), a Maximum Power Point Tracker (MPPT), is responsible for tracking the maximum power point of the solar panel according to instantaneous environmental conditions. The system is a switch-mode power supply which allows to change the load seen by the solar cells to extract maximum power. We adopted an hysteretic boost converter because it causes a reduced current stress to solar panels and it requires fewer components and in particular could be implemented without using CMOS integrated circuits, prone to latch-up in space environment. Temperature based quasi-MPPT controllers are quite widespread because their control scheme is simple: they infer the maximum power point from the solar panel temperature and track it. This is based on the precise knowledge of the temperature / voltage plot at the maximum power point: this is a disadvantage of this strategy since solar cells should be precisely characterized and changing the solar cell would mean changing some parameters in the MPPT. Instantaneous power tracking solar panel controller is based instead on the measurement of instantaneous power: this type of controller has to sample
B. Latch-up protection Latch-up occurs when the parasitic SCR made by the couple of CMOS devices is turned on by high input voltages (this is the usual LU in ICs, caused for instance by static charges) or by high energy particles which induce a small current (this is the case for a space device). The effect is a high, self-sustaining current flow, which can bring to high power dissipation and in turn to device disruption. Latch-up free circuits can be designed by avoiding CMOS devices, or by using radiation hardened devices; since one of the goals of AraMiS is to use COTS components, we decided to keep using CMOS devices and to develop specific protection circuits, able to protect CMOS circuits from latch-up events. The basic idea behind the protection is to constantly measure current and to immediately turn the power off if anomalous absorption is detected. Once the transient event is over, normal operation can be restored. Each supply path should have its own protection circuit, which should itself be LU-free, e.g. by using only bipolar technology for its components. The block diagram of the protection circuit of a single supply path is shown in Figure 4, and includes: • a current sense differential amplifier (CSA), • a monostable circuit, • isolating and current-steering switches (IS and CS). When the current crosses the limit set for anti-latch-up intervention (usually 2× the maximum regular current), the monostable is triggered and isolates the load from the power sources (with IS switch) for about 100 ms. To fully extinguish the LU, the shunt switch (CS) steers residual current away from the load. The main problem in the design of LU protection is to balance the LU current threshold with current limit of the power supply. Namely, if the regulator current limit 4
PW Supply
IS CS
CSA
Load SPC
Users
Solar
Monostable
Panel
1
Fig. 4:
2
3
Block diagram of latch-up protection circuit. Fig. 5:
Power generation and distribution.
A
is activated before the LU, the current is limited but not brought to 0, and LU continues for indefinite time.
SPC1
Controller
A1 A1 B1
B1
VI. S IGNAL AND P OWER B USSES B SPC2
On AraMiS reliability at low-cost is the main keyword. This concept is applied in each subsystem starting from power distribution and system communications which are the infrastructures the modules have to share. Since many entities have to access the same physical medium, it is necessary to avoid a single user to block the others or to damage the infrastructure. Now we detail the shared resources on AraMiS i.e., the power and the communication busses.
Controller
Fig. 6:
A2 A2 B2
B2
An approach for sharing different batteries.
using a diode-OR connection (see Fig. 7). In this way the output is not regulated by an ad hoc converter, but the power required is purchased by the most charged battery. We loose in power efficiency since the voltage drop over the diode is not negligible, but we gain in redundancy because if one or more power-path are damaged the system still continues to receive energy and no extra software controls are needed. Due to these reasons, the users have to convert the power bus voltage (about 8 V) into a regulated one, depending on the electronic subsystem to be powered.
A. Power Bus A power bus has to allow all the energy producers and all the energy consumers to respectively distribute and receive all the energy available. In Fig. 5 we can see the power path from the solar panels to the users. This structure is replicated as many times as are the external tiles. Each replica can be connected to the others using physical redundancy to increase fault tolerance. Indeed if we join together every power-path in the sections shown by dashed lines we can move energy from one point to another by-passing any faulty modules. These solutions can lead to advantages and drawbacks: 1) if we allow a solar panel to be shared by multiple SPCs we gain in redundancy, since if one SPC is damaged, another one can use its solar panel for recharging batteries, but we have to introduce extra-hardware to manage multiple panels and we dramatically increase (i) the number of connections among modules and (ii) software complexity for SPC; 2) if we allow a single battery to be re-charged by many SPC, again, we gain in redundancy, but, as in the previous case, we increase global complexity in hardware, software and interconnects (see Fig. 6); 3) joining the power-path after batteries is quite simple since it can be done using a simple diode and leaving the output voltage unregulated, the extrahardware overhead is small, no extra connections are needed and also software remains the same. For above reasons we decided to have separated power-paths that are merged together only on the load
B. Communication Bus Each AraMiS module needs to communicate with the others for interchanging information (i.e., sensors acquisition), for handling attitude control actuators and to communicate with the radio-frequency transceiver. We need a way to communicate with high reliability, able to tolerate faults, with a bit-rate of about 200 kbps. On the other hand we want to have a collision detection system able to manage multi-master communications. For this purpose we define an ad hoc interconnection system, called Cross-Bus, which solves all these issues. It is divided into levels as ISO/OSI [7] advices, but only the 2 lower one are specified, leaving the others to user implementation.
Output Voltage
Fig. 7:
5
Diode-OR connection of unregulated battery voltages.
uC
Fig. 8:
Fig. 9:
Basic module of cross-bus infrastructure.
Cross-Bus network infrastructure.
Preamble
1) Physical Layer: The physical layer defines the medium used to communicate among modules. In our case we have many constraints given by the application field: • redundancy • tolerance to electromagnetic disturbances • power consumption These are electrical specifications, but we also have to deal with several others i.e., the number of signal used (in order to reduce the number of wires in the satellite) and the cost. To achieve high redundancy we can use a fullyconnected infrastructure, but the number of interconnection increases with the nodes number, so it is not suitable for a modular platform. Using a star topology can be more modular, since each node is connected to only one node (the central node). But this impacts dramatically on redundancy, indeed if the central node stops all the net is lost. The simplest solution for multi-master communication is to share a common medium as a bus. But a shared bus has its main disadvantage in redundancy: a single fault on a bus driver completely locks the bus. We propose to use an isolated redundant bus as shared medium: each AraMiS module has a bus like the one depicted in Fig. 8. connecting the modules together leads to the structure drafted in Fig. 9. Redundancy is very high, since you should have 4 faults on different points to make one or more node unreachable. Our idea takes the best characteristics in each previous solution i.e., the full connection among modules, the possibility of making broadcast communications (without dealing with statically privileged nodes) and an high level of redundancy. All these goals are achieved using low power commercial circuits attaining both energy save and low costs. Let us consider the data encoding over the bus. Each tile is coupled to the others by means of inductors, that do not allow transmission of DC values. Thus we have
Fig. 10:
ID
Datum−1
Datum−N
Frame structure used on cross-bus.
to encode data in order to reduce DC component in order to allow correct data transmission. This can be done in two different ways: • encoding each bit in a way that includes always a signal transition, e.g. using Manchester-like codes; • encoding each word of data in a DC-balanced form which reduces the continuous component on the bus lines, e.g. with 8b/10b encoding. The former has a great overhead in terms of bandwidth, since it uses a frequency on the bus double than the datarate. The latter option is more suitable since it wastes less bandwidth for communications than the Manchester encoding. Both increase the communication complexity since they are not available on normal micro-controller. We have to fully implement one of these solutions. Another characteristic of this hardware structure is at the lowest electrical specification. We use signal differentially encoded over a couple of communication lines (plus ground signal), so even if a fault shorts one of these lines, the other still remains available and still continues transmitting data. 2) Data-Link Layer: The data-link layer aims to transfer data across the physical medium in a reliable manner inserting collision avoidance and error detection and correction. Frame synchronization is achieved putting before each frame a simple preamble composed by alternating 0s and 1s (see Fig. 10). Both data and prologue are sent using the encoding specified above, in order to transfer data across coupled inductors, without inserting bit stuffing. Since the bus is multi-master we have to deal with data collisions. To overcome such problem, each master listens to the bus and it starts sending data only if it is free. Every data sent contains as the first part the master ID, which is univocal. The master, when it is driving the bus lines, also listens for the data on it, to 6
detect collisions. If a collision occurs, all the masters involved wait for a random period before starting a new bus access. The data-part is sent after the ID for a fixed length of 8 packet of 8-bit-wide data. This layer can be built in hardware or in software, depending on the performances required. 3) Bus Properties: The obtained infrastructure intrinsically embeds these properties: • robustness since any node is connected to the bus through 4 different points, each node tolerates up to 3 faults on medium access, but this still does not block the whole bus: all the remaining nodes are still available and fully connected; • safeness a stuck node does not block all the bus since only signal transitions are transmitted along the medium (thanks to the coupled inductors); • fairness the bus is intrinsically fair, since all the nodes have the same priority in bus access. All these features made the cross-bus very suitable for space applications. 4) Magnetic Bus: On cross-bus we can tolerate many faults, due to its intrinsic redundancy, but still one fault is not managed: the babbling-idiot failure [8]. This problem arises when a node starts using the bus sending data without releasing it. This is very dangerous, since when the bus is busy no-one can use it anymore. For this reason we need a way for communicating also in this abnormal situation. The magnetic bus takes advantage of attitude control presence. It uses the magnetic coils powered to generate a magnetic field and orienting the satellite, which can also be used as antennas to communicate with the other tiles.
to the satellite could know the status of health of the satellite. The attitude control algorithm is the most time consuming task the OBC should perform: it takes data from the magnetic field ad sun sensors on the Power Management tile and it controls the actuators. The main purpose of this system is to first detumble the satellite after the detachment from the launch vector and to keep antennas aiming the earth. Data storage is accomplished with a set of commercial Secure Digital Flash card: these cards were developed for portable devices such as digital cameras and are suited for low power, small dimensions applications. To ensure also radiation hardness we developed a system that is similar in principle to RAID-1 storage units in commercial PC: data are stored at the same time in multiple Flash cards and they are then read and compared to each other to correct errors. Since the capacity of these devices is high (it easier to find 1 GB devices than for example 16 MB ones) it is also possible to store multiple copies on the same card also because housekeeping data to store per single orbit are only approximately 10 KB. The OBC is also responsible of controlling Payload boards which should perform all the operations needed to accomplish the mission: OBC has also the possibility to perform some mission specific tasks even if it was not developed for this purpose. The unit is made by 3 TI MSP430[6] devices connected in a triple modular redundant structure, used to correct Single Event Upset errors originated from high energy particles. VIII. PAYLOAD The payload is usually a mission dependent module that cannot generally be fully pre-designed. However, a number of applications often share a similar structure, where a central processor is used to control one or more instruments, translate commands from ground into actions, provide on-board storage capacity and communication facilities. Although some very small applications may leverage the presence of the OBCs described in Section VII, these tasks typically require a moderate to fairly powerful processor which exceeds to computational power supplied by the OBCs themselves. Therefore, we decided to provide a reference design of a processor board which seamlessly interconnects with the rest of the satellite, as a starting point for a more detailed design which takes into account all the requirements of the applications. Nonetheless, the reference design can be used as-is in those cases where no additional features are necessary and design time should be short. While designing the board, we tried to follow AraMiS philosophy as much as possible, resulting in a set of characteristics that the board should satisfy:
VII. O N -B OARD C OMPUTING In AraMiS the On-Board Computing (OBC) unit is mainly responsible of managing the system, in particular of: • creating and transmitting (by Transceiver board) Beacon packets, • decoding and executing commands, • executing attitude control algorithm, • storing housekeeping data, • controlling Payload boards. Every time the OBC unit is turned on, its task is to verify if a command had been received by the Transceiver board: if so, it has to issues the corresponding commands to the other sub-systems of the satellite, gather replies from them and send data to ground. If no command was received the OBC starts gathering housekeeping data from all the boards (for example boards temperature, solar panels output power and other parameters) and creates the beacon packet which will be sent again with the Transceiver board. In this way all the people listening 7
SDRAM
Peripherals UART, I2C, SPI, USB, ...
FPGA Processor
Debug
Video codec
RS232, JTAG, Eth, ...
Digital I/O
Fig. 11:
•
•
•
•
•
by configuring a Compact Flash peripheral to access a standard CF device. RAM is in the form of external synchronous dynamic RAM (SDRAM), which has been shown to be less prone to radiation induced errors than static RAM ([10]). More high speed volatile memory and caches are possibly available on the FPGA. The memory hierarchy can be customized to suit the application needs, as several different schemes with respect to the amount of memory are pre-designed. One of the most important features in the design is the flexibility of communication of the processor with the rest of the system. We considered four different kind of communication media:
Flash
Analog I/O
Cross−Bus
Reference payload board block diagram
1) A peripheral implementing the Cross-Bus standard defined in Section VI-B is available. Messages from or to the on-board computers and communication boards can be transmitted on this bus. 2) Direct communication using standard peripherals: high priority or low latency messages may require a dedicated path other than the Cross-Bus medium to achieve the desired performance. This is, for instance, the case when the payload processor should have a direct high speed connection with the communication board that drives the antennas. Most of these peripherals are available as IP cores in the Gaisler library. 3) Digital and Analog general purpose input/outputs can be used to interface with some payload instruments. The number and type of I/Os is configurable at system generation time. External AD and DA converters with analog multiplexers are used for analog signals processing. Digital inputs can be configured to generate interrupts, and a set of encoders to count events can be implemented on the FPGA. A simple device driver to access these I/Os is provided in Linux. 4) Debugging of the payload board can be performed using a set of dedicated communication links, such as an RS232 console, a JTAG connector for step-by-step execution, and optionally an Ethernet device. If computational power is sufficient, a built-in web server running on the processor can be used to monitor the system during earth bound test sessions.
Modularity, which in this case does not only correspond to the number of boards that can be plugged in at the same time, but mostly to the ability to customize and expand in several ways the reference platform, both in terms of hardware and software. Standardization of the programming environment, based on the C language and on common operating systems, such as Windows CE or Linux with real time extensions, with hardware abstractions using device drivers. Fault tolerance, based on techniques such as hardware and software redundancy, watchdog timers, and error detection and correction; these methods should operate independently of the user program that controls the application. Low power consumption, through static or dynamic voltage and frequency scaling, as well as selective instantiation and/or activation of peripherals devices. Low cost, by using COTS components and commercial technology.
After considering several possible alternatives, we eventually chose a soft processor to be programmed on an FPGA. This allows us to achieve the maximum flexibility in the processor configuration, while providing spare logic for application specific enhancements. A block diagram of the board is shown in Figure 11: the parts on the colored background are all implemented on the same FPGA, while other components use, at least partially, external circuits. The selected processor is a Leon 2 from Gaisler Research ([9]), running on a Xilinx Virtex2 Pro FPGA. The only operating system which has currently been tested is Linux 2.6, as it is provided by Gaisler itself, with a full development suite. This processor is also available in a fault tolerant version against Single Event Upset (SEU), and can be implemented on a radiation hardened Atmel FPGA. Plans to upgrade to the Leon 3 processor family are under way. Permanent storage capacity is provided by an onboard flash memory, which is also used to hold the processor software. Additional memory can be added
A power regulator which interfaces to the AraMiS power bus is also present, although it is not shown in Figure 11. Additionally, we provide support for video decoders if standard video sources need to be connected to the system. Obviously, any peripheral or component that is not strictly necessary can be omitted, thus saving precious power. Fault tolerance can be both at the hardware and at the software level. The processor can be replicated using Triple Modular Redundancy (TRM) [11] and a voter is used to protect against Single Event Upsets, which 8
can occur both in the internal processor memory and in the FPGA configuration memory. Watchdog timers, on the other hand, allow to stop a faulty execution and restart the system. Upon restart, the FPGA configuration memory is also checked against possible upsets, and reloaded with correct code if necessary. Software can also be replicated, especially the executable code. Error detection techniques, such as CRC, can be used to identify wrong copies and correct them. Data protection is more application dependent, as some errors maybe neglected, while others might have catastrophic effects, and thus should be taken into consideration.
chip implements a complete digital UHF radio, with one output and one input channel, with good input sensitivity and output power in excess of 1mW. To complete the UHF channel it is therefore necessary to connect the transceiver to a microprocessor on the baseband side, to a power amplifier (PA) on the transmit side and to a low noise preamplifier (LNA) on the receive side. An electromechanical switch is used to connect the single AraMiS UHF antenna to the output of the PA or the input of the LNA. This device is more robust than an active switch (no radiation-related problems), and more power efficient than many diode based circuits. The power amplifier selected for the first implementation of the board was RFMD model RF2175, which provides an output level of +34 dBm. This device has several advantages with respect to other solutions: it is very small, it provides enough output power with good efficiency and it is latch-up free. Depending on the amount of power available for communications (i.e. essentially on the size of the satellite), an optional power module can be cascaded to the PA to attain an output power in excess of 8 W. The processor supervising the UHF link is a TI MSP430. Its functions are essentially: • to exchange baseband command/status/telemetry packets with OBC and Payload processors; • to encode/decode packets, by performing scrambling/descrambling, bit-stuffing, insertion and removal of prologue and header information, so that OBC and Payload to not need to cope with communications details; • to supervise operation of the transceiver and RF subsystem (power sequencing, antenna switching). The S-band link is based on the transceiver TI/Chipcon CC2510. This device incorporates a complete radio modem and a processor kernel of the 8051 family, with a certain amount of memory, thus it is not necessary to use an external processor as in the UHF subsystem. The CC2510 is not optimized for high power operation. In details it uses the same pin as the output of the internal PA (output power: 0 dBm) and the input of the internal LNA. It is obviously possible to design an external architecture, that includes at least two switches, to drive an external PA and an external LNA, but we decided to use two different devices, one as receiver, the second as transmitter. This choice enabled us to greatly simplify PCB design, eliminating the risk of unwanted coupling between transmit and receive paths with associated oscillations or instability. The amplification chain on transmit side is composed of two stages, the first being a NEC model UPC2762, the second a RFMD model RF5189. The output power is about +32 dBm. The power amplifier is pushed to its linearity limits, but this is not a problem because the GFSK modulation adopted in the link is not sensitive
IX. T RANSCEIVER AND C OMMUNICATIONS The communications subsystem of AraMiS follows the modularity philosophy of the satellite. In fact, a basic communication tile is provided as standard, while dedicated tiles are foreseen in case of special applications. The basic system is connected to the cross-bus architecture. It is used to receive command and control packets from the Ground Station and to send back telemetry and status information. The bandwidth needed to exchange this kind of information is usually low, so the RF link was designed for low speed and low power. In order to achieve fault tolerance, two different channels are used, in the bands allocated by ITU for satellite communications. The first channel lays in the UHF 437MHz band, the second in the SHF 2.4GHz band. The data contents of the two links are equivalent, thus providing two interchangeable possibilities to communicate with the satellite. To reduce occupied bandwidth, both channels implement an half-duplex protocol, sharing the same frequency for downlink and uplink. The UHF downlink was designed to be compatible with the amateur PK96 packet radio. It uses the UI frame defined in the AX.25 standard, following the subset for APRS. The reason for this choice was to enable the reception of AraMiS telemetry by radioamateurs around the World, to collect data from orbits unreachable from our Ground Station. The telemetry data packet format for each AraMiS satellite will be publicly available from our site. The S-Band link data are organized in a similar way but, to avoid the computational overhead of some of the operations required by AX.25 (scrambling and bit-stuffing), the transceiver uses a modulation scheme which is not directly compatible with amateur stations. External users are not allowed to issue commands to the satellite, because of the stringent power budget and for security reasons, so the format of the uplink data packet will not be published. To reduce the probability of false command detection, data are strongly encoded. As already mentioned, the basic RF subsystem is built on a standard AraMiS tile. The UHF link is based on a transceiver from TI/Chipcon, model CC1020. This 9
to nonlinearity. As for the UHF subsystem, the antenna switch is an electromechanical relay. On the receive side we inserted a low noise amplifier, Maxim MAX2644, and obtained a sensitivity of about −120 dBm. An optional power module is available to increase output power to about 7W at the expenses of a much higher power consumption, compatible only with non minimum-size satellites. The UHF system is equipped with a helical antenna, while S-band uses a Planar Inverted-F Antenna (PIFA). The radiation diagrams of the two antennas are by some extents complementary, to give a better chance of communicating with the satellite independently of its orientation. As previously stated, the bandwidth of the standard RF links is quite low. The UHF connection data rate is 9.6kbps, while the SHF rate can be set from 10kbps to 1Mbps, but analyzing the link budget it is possible to show that only using the lower speeds a reliable communication is attained. Some of the foreseen applications require a large bandwidth downlink, for example in case of high resolution or real-time imaging. In this case the performances of the standard links are not sufficient, even increasing the output power. To address this case we are designing a large bandwidth downlink tile that will overcome the problem. This tile will not use an integrated transmitter but instead a large FPGA for baseband processing, a TxDAC, that is a high speed dual channel Digital to Analog converter with internal digital filtering and oversampling, a PLL, an I-Q modulator, followed by a PA. The architecture is much more complex than the standard one, but it has the advantage to allow for Software Defined Radio implementation, to match the characteristics of the transmitter to those of the application. The obvious disadvantage of this solution is increased power drain from the satellite’s resources and increased complexity, so its use will be limited to very demanding applications.
hoc for testing (both mechanical and functional and electrical); ii) using smaller equipment (especially for mechanical and radiation tests). As standard testing strategies are often redundant for nano- and micro- satellites, we are also studying and developing appropriate testing strategies aimed at cheap satellites, as part of the AraMiS project. The details of such strategies are not yet available. On the other hand, since each module contains a micro-controller, we also plan to embed automatic test functions (e.g., BIST), in order to simplify verification of correct satellite operation. XI. C ONCLUSIONS The AraMiS architecture we present in this paper represents a fundamental step in creating low-cost satellites that could open the space market to SMEs and Universities. The first elements of the architecture are the Power Management tile and the basic communication tile. These elements are now under final development and testing. We are designing the first satellite built on AraMiS concepts, and we plan to launch in the next two years. R EFERENCES [1] D. D. Corso, C. Passerone, L. M. Reyneri, C. Sanso`e, M. Borri, S. Speretta, and M. Tranchero, “Architecture of a Small LowCost Satellite,” 10th Euromicro Conference on Digital System Design, pp. 428–431, August 2007. [2] PiCPoT. [Online]. Available: http://polimage.polito.it/picpot [3] AraMiS. [Online]. Available: http://polimage.polito.it/aramis [4] Cubesat Community Website. [Online]. Available: http://cubesat.calpoly.edu [5] S. Mitra, N. Saxena, and E. McCluskey, “Common-mode failures in redundant vlsi systems: a survey,” vol. 49, no. 3, September 2000. [6] Texas Instruments. [Online]. Available: http://www.ti.com [7] OS1 Reference Model-The IS0 Model of Architecture for Open Systems Interconnection, 1980. [8] C. Temple, “Avoiding the Babbling-Idiot Failure in a TimeTriggered Communication System,” in FTCS ’98: Proceedings of the The Twenty-Eighth Annual International Symposium on Fault-Tolerant Computing. Washington, DC, USA: IEEE Computer Society, 1998, p. 218. [9] Gaisler research. [Online]. Available: http://www.gaisler.com [10] J. F. Ziegler, H. W. Curtis, H. P. Muhlfeld, C. J. Montrose, B. Chin, M. Nicewicz, C. A. Russell, W. Y. Wang, L. B. Freeman, P. Hosier, L. E. LaFave, J. L. Walsh, J. M. Orro, G. J. Unger, J. M. Ross, T. J. O’Gorman, B. Messina, T. D. Sullivan, A. J. Sykes, H. Yourke, T. A. Enger, V. Tolat, T. S. Scott, A. H. Taber, R. J. Sussman, W. A. Klein, and C. W. Wahausand, “IBM experiments in soft fails in computer electronics,” IBM Journal of Research and Development, vol. 40, no. 1, January 1996. [11] D. K. Pradhan, Fault-Tolerant Computer System Design. Englewood Cliffs, NJ: Prentice Hall, 1996.
X. T ESTING The idea of using modular and flexible intelligent tiles also aims at a cheap testing strategy. Each manufactured tile shall be tested mechanically, functionally, and under radiation. Being tiles small, simple and standardized allows reducing the cost of testing significantly by: i) reusing the equipment which has to be developed ad-
10
