Design Solutions for Modular Satellite Architectures

1. Introduction

The cost-effective access to space envisaged by ESA would open a wide range of new opportunities and markets, but is still many years ahead. There is still a lack of devices, circuits, systems which make possible to develop satellites, ground stations and related services at costs compatible with the budget of academic institutions and small and medium enterprises (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 €), appropriate business models will likely develop to ensure a cost-effective and pervasive access to space, and related infrastructures and services.

These considerations spurred the 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 fully exploited due to the belief that COTS devices are not reliable enough for this kind of applications;

2. developing a flight model of a flexible and reliable nano-satellite with less than 25,000€;

3. training students in the field of avionics space systems: the design here described is developed by a team including undergraduate students working towards their graduation work. The educational aspects include the development of specific new 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. gather and cluster expertise and resources available inside the university around a common high-tech project;

6. creating a working group composed of both University and SMEs devoted to the application of commercially available technology to space environment.

The first step in this direction was the development of a small low cost nano-satellite, started in the year 2004: the name of this project was PiCPoT (Piccolo Cubo del Politecnico di Torino, Small Cube of Politecnico di Torino). The project was carried out by some departments of the Politecnico, in particular Electronics and Aerospace. 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 design exploited internal subsystems modularity to allow reuse and further cost reduction for future missions.

Starting from the PiCPoT experience, in 2006 we began a new project called ARaMiS (Speretta et al., 2007) which is the Italian acronym for Modular Architecture for Satellites. This work describes how the architecture of the ARaMiS satellite has been obtained from the lesson learned from our former experience. Moreover we describe satellite operations, giving some details of the major subsystems. This work is composed of two parts. The first one describes the design methodology, solutions and techniques that we used to develop the PiCPoT satellite; it gives an overview of its operations, with some details of the major subsystems. Details on the specifications can also be found in (Del Corso et al., 2007; Passerone et al, 2008). The second part, indeed exploits the experience achieved during the PiCPoT development and describes a proposal for a low-cost modular architecture for satellites.

2. The PiCPoT satellite

The PiCPoT design activity carried out at Dept. of Electronics, in tight cooperation with the Dept. of Aerospace Engineering and other departments of Politecnico, was aimed at developing and manufacturing a low-cost prototype of a fully operational nano-satellite. The design activity started in early 2004 and gathered about 10 people among professors and Ph.D. students, plus about 20 undergraduate students (the former for the whole Ph.D. program duration, the latter for shorter period, between 6 and 12 months each). The total effort of the project can be estimated as about 12 man-years (staff + student) for design, manufacturing and testing; a flight model and two engineering models of the PiCPoT satellite, shown in Figure 1, have been built.

Figure 1.

PiCPoT engineering model.

The satellite has been completely designed using COTS devices, with the exception of solar panels. The basic architecture consist of five solar panels; six battery packs; three cameras with different focal lengths; five processors in full redundancy; two RX-TX communication modules with antennas operating at 437 MHz and 2.4 GHz, respectively. The on board electronics uses six PCBs hosted in a cubic aluminum case (developed by Dept. of Aerospace Engineering), 13 cm in side and 2.5 kg total mass. The main mission was to send telemetry data (temperatures, voltages and currents) to ground, and to take, store and transmit pictures of the Earth at different spatial resolutions.

The satellite was launched on July 26th 2006, from Baykonour. Unfortunately a failure of the launcher forced its destruction before being released in the planned orbit.

3. Design constraints

An airborne satellite must comply with hard constraints related to the severe space environment and the inability to repair the system in case of failure. Therefore, the design and the assembly of the device must abide by tighter rules than usual good and safe design criteria applied for any electronic system. This is particularly true when using COTS components and technology, which require the adoption of design techniques which guarantee system operation even in the presence of limited faults at the device level.

Other specific characteristics of a space application, although not directly related to failures of the system, further constrain the possible design solutions that can be adopted. These include the need to autonomously produce power, the limited visibility of the satellite from a ground station and the distance from it, the length of the mission, and so on.

In the following, the constraints and their implications that were considered in the design of PiCPoT, along with some solutions and ideas, are outlined.

3.1. Radiation

The planned orbit is close to the Van Allen belts, where a limited amount of radiation is present. This radiation might be in the form of high energy particles (protons, neutrons, alpha and beta particles) or ionizing electromagnetic rays from ultraviolet to X-rays. Due to the low orbit (polar, at 600km of altitude), and to the short lifetime assumed for the mission (3 months), total dose effects have not been considered. However, single-event effects (SEE) such as latch-up occurring in CMOS devices, and state upsets in memories and/or registers of digital circuits, might indeed induce wrong behaviors or even permanent faults. Thus the satellite circuits have been protected at the logical and system level against these events. Techniques that have been used include latch-up protection circuits, watchdog timers and redundancy at various levels. More details can be found in Sec. 4.

3.2. Electro-magnetic interference and signal integrity

Noise at various frequencies may come from both internal and external sources. However, the satellite outer structure is completely metallic, and all inner circuits are therefore well shielded against electro-magnetic interference (EMI) from the outside. Internal interference between different boards or within a single board is addressed by properly designing ground planes and the printed circuit board (PCB) layout of RF and digital units.

3.3. Temperature ranges

While it cycles through its orbit, the satellite alternates from broad daylight to deep Earth shadow. In these conditions, temperature may vary considerably. However, the orbital period is fast enough not to allow too much heat to build up or be released into space, preventing burning or frosting of the satellite. Thermal simulations allowed us to predict the actual temperature ranges for the outside and the inside faces of the aluminium plates that constitute the external structure of the satellite, and for the internal electronic boards. We considered the cases when the electronic boards are inactive, as well as when they are active and dissipating power (Caldera et al, 2005). The predicted outside temperature range with active electronics is [5, +50] C; the parts subject to this range are external ones, such as solar panels and antennas. The temperature range inside the satellite is [+20, +70] C, as shown in Figure 2, where the different curves represent the temperature of each board; all electronic circuits must comply with this range, which is compatible with standard commercial devices.

Figure 2.

Thermal analysis for powered electronic boards in the satellite

3.4. Vacuum

Vacuum is not a problem for sealed electronic components, but reduces the power dissipation capability due to missing convection, leaving only conduction and radiation to the outside. This problem is related to the temperature ranges outlined above. The board that dissipates more heat is the one responsible of data transmission, as it hosts the power amplifiers; we successfully tested it in a thermal vacuum chamber, with a temperature range of [-20, +50] C and a pressure of 10Pa. While the expected pressure at the orbit altitude is some order of magnitude lower, we considered the level that we could achieve with in-house equipment sufficient to assess the board reliability. Other boards were simulated using their nominal characteristics, taking into account de-rating because of the absence of convection.

3.5. Vibrations

Forces and vibrations applied to the satellite during the launch are very high, and might cause physical damages, as well as disconnection of electronic devices and disengage of electrical connectors. A careful choice of packages (i.e., no BGA devices, more sensitive to vibrations), mounting technologies and overall structure is therefore mandatory.

PCBs (see Figure 3 for an example) have small size (about 12 8 cm²), and are mechanically blocked at the four edges, therefore vibrations are kept within acceptable limits. More bulky components are secured to PCB, but connectors represent a critical point. Direct board-to-board connectors are kept in place by the mechanical fixture of boards. Other connections use flexible PCBs or small flat cables; in these cases silicon glue is used to keep in place the movable part.

Specifications and requirements with respect to static loads and vibrations were established by the launcher company (Kosmotras and Yuzhnoye Design Office, http://www.yuzhnoye.com), and verified by simulations and ground tests. Mechanical tests for the maximum longitudinal g-load of 10.0g were conducted at Thales Alenia Space facilities in Torino, including random and sinusoidal vibrations. Shock and acoustic loads tests have been carried out by Yuzhnoye in Ukraine.

Figure 3.

An example of the PCB developed and used in PiCPoT

3.6. Orbit

The predicted polar orbit is at a height of around 600 km (370 miles) and takes roughly 90 minutes to complete one revolution. In optimal conditions (i.e., when the satellite passes through the zenith), the line-of-sight visibility of the satellite from any given point on the Earth lasts about 10 minutes. If we take into account the distance (which varies depending on the altitude of the satellite over the horizon) and absorption due to the atmosphere, an electromagnetic signal would on average be attenuated 160 dB. Given the available power at the transmitter on the satellite, the transmitting and receiving antenna gains, and the receiver characteristics, the maximum transfer rate, assuming a certain bit error rate, can be computed.

3.7. Power

The satellite has to generate its own power to function properly. The Sun is the only power source, and solar panels are used to transform light into electricity. At the Earth-to-Sun distance, the total power per square centimeter potentially available is 0.135 W. 5 out of 6 faces of the satellite are covered with solar panels, and only 3 of them are facing the Sun, with varying form factors (i.e., the angle between the solar panel and the incoming light ray). From these information, combined with orbit data the efficiency of the transformation process, the total available power can be computed. Since the satellite spends most of the time in a semi-idle state, power can be accumulated in batteries, to make it available at a later time. Our calculations show that solar panels provide an average of 1.68W of power, that we use to charge six battery packs, and gives an average power available for all electronic systems of 820mW, when worst case efficiencies of both the battery charger and the batteries themselves are taken into account. Total charge time is 63.4 hours (roughly 2.5 days), and the maximum available energy is 202kJ. Peak power consumption of the electronic subsystems can obviously exceed 820mW, provided that they are not used continuously.

3.8. Size and weight

Launch costs make a considerable fraction of the total costs of a small satellite, and are directly related to the size and the weight of the satellite itself. The shape and size of the external enclosure should comply with requirements imposed by the launch vector (Kosmotras DNEPR LV, in our case), and in particular with the technique used to hold the satellite in place during launch and the way it is released when proper orbit is reached. Weight is the most important variable in computing the launch costs, since the amount of fuel needed to bring the satellite in orbit is directly proportional to it. The weight and size costs are grouped in “classes” (upper limit for weight and size); hence, the design constraint was to fit within the selected class limit, not true weight and size minimization. normal good design practice were applied in selecting components and sub-systems.

4. Design solutions

Most of the design efforts for using COTS components in a satellite are aimed to protect the system from fatal events. Techniques to achieve this goal can be classified as either physical or logical. The former includes shielding the sensitive parts and choosing devices that are less prone to errors due to radiation at a comparable price tag. The latter, while allowing events to take place, mitigates or completely eliminates their effects by acting at the system level. Examples of such techniques include error correction (i.e., in memories), redundancy at several abstraction levels, and watchdog timers to reset misbehaving devices or boards. We applied several such techniques in the design of the satellite, as described in the following.

Figure 4.

latch-up protection circuit

4.1. Single Event Latch-up (SEL)

Latch-up (LU) occurs when a parasitic SCR made by the couple of complementary MOS devices is turned on by high input voltages (LU in ICs, caused by input over-voltages) or by high energy particles which induce a small current (this is the case for a space device) (Gray et al., 2001). The effect is a high, self-sustaining current flow, which can bring a high power dissipation and, in turn, device disruption.

LU-free circuits can be designed by avoiding CMOS all-together, or by using radiation hardened devices. Since one of the goals of PiCPoT is to explore the use of COTS components for space applications, we decided to keep only some critical parts LU-free by proper device selection, and to use standard CMOS devices in other circuits, made LU-safe with specific protection circuits.

The basic idea behind protection is to constantly measure current and to immediately turn the power off as soon as anomalous current consumption is detected. Once the transient event is over, normal operation can be restored. This technique is analogous to a watchdog timer, except that it actively monitors the circuit to be preserved, rather than waiting for the expiration of a deadline. Each supply path should have its own protection circuit, which should itself be LU-free, e.g. by using only bipolar technology.

The block diagram of the protection circuit of a single supply path is shown in Fig. 4, and includes:

• a current sense differential amplifier (CSA),

• a mono-stable circuit with threshold input,

• 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 mono-stable is triggered and isolates the load from the power sources 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 is activated before the LU, the current is limited but not brought to 0, and LU continues for indefinite time.

4.2. Single Event Upset (SEU)

PiCPoT contains several digital circuits, including 5 processors, different kind of memories and programmable logic devices. When a high-energy particle hits a circuit, it may cause a transient change in voltage levels. While this is usually not considered a problem with analog circuits, it might adversely affect digital circuits which typically involve high speed signals with steep edges, and especially memories that rely on tiny voltages to carry their information. If the final effect results only in a glitch (Single Event Transient, SET), then it can safely be ignored; however, if the event is latched, or directly upsets a bit (or multiple bits) in a memory or a register, it will probably lead to incorrect behaviors (soft errors). In extreme cases, such as when a configuration bit of a programmable logic device turns an input into an output, it can even cause severe damages.

In the less dramatic case of a soft event, we distinguished between three different kind of errors:

1. errors on dynamic data and/or in code segments resident in volatile memory;

2. errors on data stored in non-volatile memory;

3. errors on program code stored in non-volatile memory.

The outcome of such events may be wrong data, wrong behavior (if the event affects some data dependent control, for instance) or even a crash (i.e., if the upset results in a non-existent op-code for a processor).

The available solutions to address the problem are very diverse, each with its own advantages and shortcomings. Some cope with all three kind of errors, others address only some of them. We applied different techniques in various parts of the satellite, depending on the kind of protection we wanted to provide. The selection was driven by the need to keep the design simple and power consumption and total budget low. We did not employed radiation-hardened devices (which are too expensive and against the whole philosophy of the project to use COTS components), and memories with error corrections code (ECC, which are only useful for dynamic data and do not protect against multiple bits upsets).

The susceptibility of COTS components to radiation can be very different. Careful selection of the best devices for the application allows us to strongly reduce the probability of single event upsets. We examined several kind of memories in search for the best ones, and in particular we considered:

• Dynamic RAM (DRAM): it is the most dense memory, used when large amount of memory is required. Being based on charge held on a capacitor, it is rather sensitive to radiations. Those parts of the satellite that depend on this kind of memory must be protected in some other way.

• Static RAM (SRAM): the information is stored into a two-state device (flip-flop); it has been shown that these are more sensitive to radiation than dynamic RAMs (Ziegler et al., 1996), but have the advantage of consuming less power. Processor registers also use the very same technology.

• Flash: even more energy than conventional static RAM is needed to change the state of a bit. For this reason, flash devices are more tolerant to radiation and are a good candidate for important data and code. They are also non-volatile and cheap, but cannot be used for normal processor operations, since writing performance are extremely poor.

• Ferro-electric RAM (FeRAM): this is a kind of memory (Nguyen & Scheick, 2001) based on ferro-electric phenomenon. A ferro-electric material (usually an alloy of zirconium or titanium) can be polarized by applying an external electric field. The polarization hysteresis allows to store information. Writing operations on an FeRAM require lower voltages (3.3 V, for instance) and are 2 to 3 order of magnitude faster than in flash memories. This allows energy saving and at the same time maintains the good tolerance to radiation of flash devices. Since few information about the behavior of FeRAM in space is available in the literature, its use on PiCPoT was limited to a single board.

We used a mix of all the above memories because strengths and weaknesses were often complementary. Dynamic and static memories were used for program execution, while Flash and FeRAM were used for permanent data and program storage. Being highly experimental, FeRAM was only used to hold non-vital data, such as the telemetry stream acquired from sensors.

Another technique to handle the problem of SEU is to use redundancy. In general, at least three replicated units are necessary to implement a voting mechanism, where the majority wins and allows correction of a fault. The replicated unit can be a complete board (processor, memories and peripherals), a physical device on a board (three instances of the same component) or an abstract unit within a device (three memory segments in the same chip, holding identical information). This method potentially allows active identification of an SEU even in RAMs during the execution of a program, and to promptly act to correct it. However, the space available inside the satellite did not allow us to replicate identical boards, or even devices within a board. Nonetheless, in some of the processor boards the program stored in flash memory is maintained in multiple copies and a procedure to search for SEUs can be explicitly activated. Data, such as pictures or telemetry, on the other hand, is not protected and if an SEU occurs, the information downloaded to ground will simply be incorrect.

Since RAMs, both static and dynamic, including registers inside the processors, are the most sensitive devices to SEU, and they are not replicated, other techniques must be used to ensure proper behavior. Our solution is to periodically turn off processor boards and start a complete boot procedure. Given that the program is stored in flash memory (possibly with some duplication) and that RAMs go through a power cycle and reset, the soft error will be completely eliminated. Obviously, whatever command was being executed at the instant the SEU occurred will potentially result in wrong data or a crash. This however does not preclude the system to work correctly at the successive re-boot. The periodicity that was selected is 60 s: it allows all but the longest command to be executed with a good margin; the notable exception is the download of a picture to ground, which might need to be split into multiple commands acting on different portions of the image, if it is too large to be transmitted in 60 s at the available bit rates. This technique is similar to a watchdog, but the chosen periodicity is a hard deadline and cannot be extended by the controlled processor boards.

Communication between boards may also be affected by SEU, as well as by other noise sources. Long data streams (tens or even hundreds of kbytes), such as when transmitting a picture from one board to another for successive download to ground, are more subject to problems than very short (a few bytes) commands. For this reason, long communications are protected by a protocol that involves CRC computation and retransmission. Among the various alternatives, the X-modem protocol has been selected for its simple implementation and because it is often a standard feature of terminal emulation programs on PCs, which allowed easy testing of the boards before they were connected and assembled together.

4.3. Cumulative effect of radiations

Although in Section 3.1 we stated that total dose effects have not been considered, in fact we do provide protection against possible permanent failures, as opposed to the single event effects described in previous sections, in the satellite electronic boards. This is mainly achieved through three orthogonal techniques:

1. replication of functional chains;

2. differentiation of the replicated units with respect to the algorithms, topology, architecture and technology;

3. graceful performance degradation.

The former provides multiple alternative units to perform the same functionality. Any unit can be used, but only one should be selected. Unlike replication used to address single event effects, where all units work at the same time and on the same data, this technique does not provide the ability to correct a failure. Simply, if one chain fails for any reason, one or more backups exist to take over. In some cases, multiple units can be used to reach a particular goal, but failure of any of them does not preclude the overall system to work, although functionality and/or performance might be affected.

In order to prevent similar problems from affecting all the replicas, different implementation solutions are used in the various chains. We considered using different technologies (CMOS versus Bipolar, Flash versus FeRAM, NiCd versus LiPo), architectures (two different processors and instruction set, different memory hierarchies) and algorithms (chains were developed independently by different groups, so that bugs in the software, for instance, did not show up identical in replicas).

Examples of replication with differentiation are the power supply, which can survive several failures, although with performance degradation (less available power), the on-board computers, the timing unit and the communication unit. The latter provides two communication channels using separate antennas, at frequency of 437 MHz and 2.4 GHz respectively. More details about the implementation can be found in Section 5.6. The only non replicated unit is the camera control board (payload).

4.4. Shielding

In a satellite two kind of EMI must be handled: radio-frequency interferences and radiation. We developed special solutions to reduce problems related to RF phenomena. The outer structure is based on six aluminum alloy faces, electrically connected together, using screws which are less than λ/4 apart for the highest used frequency (2.4 GHz). The wires connecting solar panels (external) and switching converters (inner part) go through special feed-through filters.

Internally, only one board deals with RF and it is structured to limit interactions with other subsystems. The board is isolated from the others using multiple ground planes and placing the RF components on the face opposite the other modules.

There is not enough space to use thick shields to protect from high energy particles, so we used internal placement of boards, batteries and panels to reduce its influence. PCBs are lodged in the inner part surrounded by a “sandwich” made of solar panels, aluminum panels (external structure), battery packs and aluminum panels (internal structure), which reduces radiation effects. Other techniques, such as the one described in previous sections, further mitigate radiation induced problems, like latch-up and single event upsets.

4.5. Power consumption and dissipation

Being a battery-based system, the whole PiCPoT project was made on low-power concept. In order to reduce power consumption every component has been chosen in commercial low-power domain. When low-power commercial components were not readily available, such as in the case of the high performance image processing sub-system, our solution was to keep them either in idle state or completely switched off when not in use, or with reduced performance if allowed by the application.

Typical power consumption of on-board systems is summarized in Table 1, where both peak and average power are indicated in column 3 and 4, respectively. Column 2 shows, in percentage, the fraction of time each subsystem is expected to be turned on. Power Management is always on, while on-board processors, payload and communication are used only when necessary. Total average power is around 0.5W. Since the average power generated by solar panels is about 820mW, we have an average margin of about 300mW. The extra power is dissipated on shunts (zener diodes) inserted on the power subsystem to avoid over-voltages on the power bus.

RF transmission is the only part which needs a lot of power for a medium-long period, since the power level is related to the satellite distance from the Earth. On the RF board we have two different devices, each of them dealing with a different band (437MHz and 2.44GHz). Power amplifiers are the most power-hungry elements, as they have to generate an output power of about 2W each. The most critical is the 437MHz one whose efficiency is only 25%, while for 2.44GHz it raises to 40%. For these reasons we had to dissipate about 6W in the worst case. This has been met using different solutions:

• The PCB contains 3 ground-planes that extend their own area to all the space available, in this way heat generated by the PAs is distributed to the entire board.

• The PCB surface is covered with high-thermal-conductivity coating.

• Chip body is connected to metal face through a thermal conductive mat. The panel is aluminum black-anodized in order to allow maximum radiation.

Thermal analysis had shown that our satellite, in its orbit can reach at most 80 C. Boards have been tested in thermo-vacuum environment, showing good performances also in corner cases.

Device	Duty Cycle	Peak Power	Avg. Power
Power Mgmt.	100%	20mW	20mW
Proc A&B	6%	200mW	12mW
Payload	0.5%	3.84W	21mW
TxRx	2.6%	17.2W	443mW
Total			496mW

Table 1.

PiCPoT power budget.

4.6. Interconnection solutions

When the amount of space available is small the problem of interconnecting a complex system like a satellite can be hard. In our case we had to share multiple connections among the boards in order to allow:

• digital communications (for actuators, house-keeping, …);

• analog signals acquisition (mainly for sensors);

• power connections;

• RF communications links.

When using connectors for these links, care should be taken to avoid detachments caused by strong vibrations during launch.

This issue was solved using a series of stackable connectors, as shown in Fig. 5, which represent a CAD model of the mounted boards. This solution leads to a pseudo-shared bus, which ensures communication among modules and reduces problems related to vibrations. The connector is tightly connected to the board, ensuring the electrical link. On this connector were channelled all the communication signals among tiles and many of the analog signals (used to acquire sensors values). In this way we obtain an efficient vibration-proof connection for digital and analog signals. For this goal we use a main stack of indirect narrow-pitch 140 pin connectors, and a second 60 pin connector for selected signals.

Figure 5.

CAD model of wirings: RF and batteries connections (a) and stackable connections among boards (b).

On the remaining signals (especially for power lines, and RF connections), instead, we have to use special media:

• SMA and coaxial cables for RF, in order to guarantee a controlled impedance and low losses between boards dealing with radio-frequency signals and antennas;

• multiple cables for connecting solar panels, batteries and power suppliers board, for achieving redundancy on these critical connections;

• flat cables to connect analog and digital signals to a board that was not stacked with the others.

Figure 5 shows the organization of the signal cables; it also includes a test connector which is available on one of the external plates of the satellite, in order to allow verification of the satellite electronics while it is closed inside its enclosure. Figure 6 illustrates the wiring of power cables when all the electronic boards are mounted in the satellite structure, and shows the test connector and cable, as well. Two sets of power cables are necessary: one to link solar panels to the batteries, and another to bring power from the batteries to the electronic boards.

Figure 6.

Power cable wiring in the mounted satellite

5. Architecture and functional units

5.1. Satellite architecture

The complete architecture of PiCPoT is shown in Fig. 7. The core of PiCPoT satellite is a redundant central power management and timing unit (PowerSwitch) which drives two processing chains (A/B). Every minute the timing unit selects the most charged battery and turns chain A on.

The processor waits for a command from ground, which is decoded and executed. If no command is received within 5s, telemetry is sent to ground anyway and the chain power is turned off. If a latch-up occurs, power consumption rises quickly, and power is turned off to extinguish the latch-up.

A similar sequence of actions takes place at time shift of 30s on chain B, which implements the same functionalities as chain A, but with different components and using the other radio link.

5.2. Power supply

The main power sources are 5 triple junction GaAs solar panels. Each of them has a dedicated Maximum Power Point Tracker (MPPT) made with a switching power converter, using only bipolar IC, not sensitive to latch-up. The five converters allow the system to survive, even if four of them got damaged.

Figure 7.

Architecture of PiCPoT satellite

The satellite uses 6 battery packs (2×7.2V900mAh Ni-Cd, 4×7.2V1500mAh Li-Po), which feed two independent power busses.

5.3. Power switch

This board is composed of two (A/B) independent subsystems responsible for:

• Battery selection

• Voltage regulation

• Schedule the power up

• Latch-up events count

For design diversity, the A chain uses a Microchip PIC microcontroller, while chain B uses a Texas Instrument MSP430. The two power on cycles are shifted 30". Latch-up events are counted and transmitted to the ground station.

5.4. On-board processors A and B

We used two different commercial low-power processors: a Chipcon CC1010 (ProcA), and a TI MSP430 (ProcB). They have similar tasks but different design solutions to increase system reliability and to prevent a single bug to crash both chains.

The functions performed include: data acquisition, battery management, interpreting and executing commands received from ground.

5.5. Camera handling

The main payload is a set of three color cameras (commercial units with a standard PAL video output), with different focal lengths. The analog video is converted into a standard ITU-R BT.656-4 digital stream, then the interlaced raw image is converted into a compressed JPEG picture, which is divided into 9 zones and individually sent to ground. An Analog Devices Blackfin DSP manages the board and implements the compression algorithm and permanent storage of the pictures.

5.6. RF transceivers

The satellite operates on two different frequencies: UHF at 437.480MHz and S-Band at 2440MHz (radio amateur satellite bands), connected respectively to the A + B chains. The UHF downlink is compatible with the amateur PK96 packet radio.

The S-Band link data are organized in a similar way but uses a modulation scheme not directly compatible with amateur stations. Link budget is summarized in Table 2.

The UHF link is based on the transceiver included in the ProcA OBC, Chipcon CC1010. The S-band link is based on Chipcon CC2400 transceivers. Two separate devices are used for TX and RX. The UHF system is equipped with a folded double helical antenna (Orefice & Dassano, 2007), while S-band uses a Planar Inverted-F Antenna (PIFA), as depicted in Figure 1; the same figure also shows the three on-board cameras.

Link	437 MHz Uplink	437 MHz Downlink	2.4 GHz Uplink	2.4 GHz Downlink
TX Antenna Gain	24 dBi	1.5 dBi	25 dBi	4 dBi
Output Power	47 dBm	30 dBm	40 dBm	33 dBm
Attenuation	154 dB	154 dB	169 dB	169 dB
RX Antenna Gain	1.5 dBi	24 dBi	4 dBi	25 dBi
RX Sensitivity	-103 dBm	-115 dBm	-118 dBm	-130 dBm
Noise Temp.	450 K	450 K	400 K	400 K

Table 2.

PiCPoT link budget

5.7. Attitude measurement and control

No orbit control is provided in PiCPoT, as there is no room for an orbit-correction propulsion system. Anyway, the short predicted life-time (3 months) does not require adjusting the altitude of the satellite. Moreover, past university satellites with no orbit control showed a long period of activity with no correction at all.

On the other hand, attitude control is necessary for two reasons:

• Aiming the antennas to ground for communication.

• Aiming the cameras toward the earth for taking pictures.

The large field of view of even the highest resolution on-board camera allows a low pointing accuracy. Also, antennas are studied such that the transmission lobe spans a wide area. We therefore looked for low cost and easy technological solutions, which could exploit the favorable orientation of the Earth magnetic field in the geographical area of Europe. We provide two ways of controlling attitude:

• A passive mechanism based on permanent magnets to align the satellite with the Earth magnetic field, with hysteresis plates as dampers to minimize oscillations.

• An active reaction wheel driven by a brushless Maxon EC 32 motor, controlled through commands from Earth.

The permanent magnets (four Neodymium 35) can only control the satellite attitude around two axes perpendicular to the Earth magnetic field. The magnets are positioned and oriented such that the bottom panel, where the antennas and camera lenses are mounted, will face the Earth over the northern hemisphere, and space over the southern hemisphere (Fig. 8). The reaction wheel is mounted such that its axis is parallel to the magnetic field: by acting on it we can reduce the spin-axis rotation of the satellite. However, given the symmetry along the vertical axis of both pictures and radio communications, this last control was not strictly necessary.

Figure 8.

Satellite orientation over our base-station.

6. The ARaMiS modular architecture

The PiCPoT project was carried out as a dedicated design, aimed to the development of a single small satellite, with specific characteristics. For the design of other satellites, with different size and payloads, the design must be repeated from scratch. A more effective way to reduce the cost of a nano- or micro-satellite mission is to reduce design and non-recurrent fabrication costs, which usually account for more than 90% of the overall budget, by sharing the design among a large number of missions. Design reuse and modularity are 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.

6.1. General description

The first step in the ARaMiS project has been to identify the subsystems which are used on every satellite and provide critical functions. We have then concentrated our efforts on these subsystems, i) mechanical subsystem; ii) power management subsystem; iii) telecommunication subsystem; iv) on-board processing subsystem; v) payload support; vi) ground segment.

The architecture of ARaMiS is based on modular smart tiles. They are placed on the outer surface of the satellite and have also mechanical purposes (Fig. 9). The inner part of the satellite is mostly left empty, to be filled by the user-defined payload. This last is the only part to be designed and manufactured ad-hoc for each mission; thanks to modularity and reuse, each tile is designed only once, but manufactured and tested in relatively large quantities.

Figure 9.

Example of modular composition of developed tiles (a) and Power-Management tile, external view. (b)

Communication and power distribution among tiles and other units are also “standardized”, and can exploit the same interfaces. 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:

• Power management (see Sec. 7 and 8), which are composed 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. A 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.

• Telecommunication (see Sec. 10), which are composed of: i) a microcontroller-based programmable transceiver; ii) a 437MHz 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 satellite face, 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, to/from this tile and, consequently, to/from ground, in a completely transparent manner.

The inner modules can be of many types. At present we are developing only one of them: the on-board processor and payload support (see Sec. 9 and 11), which takes care of all data handling for housekeeping, and interfaces to the user-defined 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.

6.2. Mechanical subsystem

To make the mechanical structure of ARaMiS as simple as possible, the tiles have also structural properties, that is, they are a significant part of the mechanical subsystem. This allows to reduce the overall weight and cost and simplifies assembling and testing of the satellite. This approach applies to small satellites (that is, with side not longer than 50 cm), while larger one should have a stiff frame to carry the many modular units.

We have achieved this goal by:

1. standardizing the size of the tiles: 15×15 cm². We have decided not to use the CubeSat (Heidt et al., 2001) 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.5mm 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 15mm 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 × 6mm² Al square rod per edge, which is screwed to the outer tiles, fixing them together;

5. having a very simple internal mechanical frame, which is fixed to the external mechanical frame, 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:

• smallest cubic shape (15 × 15 × 15 cm³): 5 power management tiles plus one telecommunication tile; one internal processing tile and the user-defined payload. About 1,000 cm³ are available for the payload.

• larger cubic (or prismatic) shape: 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 (see Fig. 9-a).

• small hexagonal/octagonal satellite: six/eight power management or telecommunication tiles with two hexagonal/octagonal Al sides (possibly telecommunication or payload-specific).

• larger satellites (larger than 50 cm in side) will require a stiffer mechanical frame to survive vibrations during launch.

6.3. Attitude Control System

The Attitude Control System (ACS) is used to stabilize the spacecraft and to orient the satellite in the desired direction. First of all, it is necessary to define the modes of operations of this system: De-tumbling, Stabilization, Spin compensation.

Figure 10.

Power generation and distribution.

In de-tumbling 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: each tile operates only on one axis but, using all the tiles together we get the 3 axis stabilization.

7. Power management

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.

7.1. Power generation and storage

As for most satellites, the main power sources in ARaMiS are solar panels mounted all around the satellite (see Figure 9-b). Their output power is highly variable: we therefore need a separate solar panel controller for each of them. Since our goal is to use COTS components to build a highly reliable system we need to implement different strategies to increase fault tolerance.

The basic Power Management tile is made of a solar cell, its control electronics, a rechargeable battery and the Al-alloy panel which holds everything together and encloses the satellite (as shown in Fig.10). 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 Sec. 8.1 and 8.2 respectively). The power generation system 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 faults with graceful performance degradation.

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, requires fewer components and can 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 requires the precise knowledge of the temperature/ voltage plot at the maximum power point: with this strategy solar cells should be precisely characterized and changing the solar cell means 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 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 reduces the probability of common mode faults. We in fact developed an analog temperature MPPT, built with bipolar devices to avoid latch-up events, and a digital maximum power MPPT implemented using TI MSP430 microcontroller: 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 estimated by the other controller to reduce losses.

7.2. Latch-up protection

Uses the same “anti-latch-up” circuit developed for PiCPoT, which become a library component block in the new modular design, in order to maintain the circuit safe even if based on COTS components. The circuit is described in Sec. 4.1.

8. Signal and power busses

On ARaMiS power distribution and system communications are shared infrastructures, and it is necessary to avoid a single faulty user to block the others or to damage the infrastructure.

8.1. 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 to provide the power path from the solar panels to the users. This structure is replicated in each external tile, with redundant connections to increase fault tolerance. Joining 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, but we have to introduce extra-hardware to manage multiple panels and we dramatically increase the number of connections among modules and software complexity for SPC;

2. if we allow each 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;

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, with small extra-hardware overhead.

For the above reasons we keep separate power paths, merged towards the load with active switch circuits, to avoid power loss caused by diode voltage drops.

8.2. Communication bus

Each ARaMiS module needs to communicate with the others and with the radio-frequency transceiver. We need high reliability, some degree of fault tolerance, multi-master protocols, and a bit-rate of about 200 kbps. We use an isolated redundant bus as shared medium. Each tile is coupled to the others by means of isolation transformers, and data are encoded to remove DC component. We use differential signaling, so even if a fault shorts one of these lines, the other still remains available and continues transmitting data.

Since the bus is multi-master we use Carrier Sense and Collision Detection to deal with data collisions. Every data packet contains as the first part the univocal master ID. If a collision occurs, all the masters involved wait for a random period before starting a new bus access.

9. On-Board Computing

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.

At turn on, the OBC unit verifies if a command had been received by the Transceiver board: it 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 gathers housekeeping data from all the boards and creates the beacon packet which will be sent again with the Transceiver board. In this way any people listening to the satellite could know the status 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 de-tumble the satellite after the detachment from the launch vector and to keep antennas aiming the earth.

Data storage is accomplished with commercial Secure Digital Flash card 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 1GB devices than for example 16MB 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 10kB.

The OBC is also responsible of controlling Payload boards, with the possibility to perform some mission specific tasks. The unit is made by TI MSP430 devices connected in a triple modular redundant structure, used to correct Single Event Upset errors originated from high energy particles.

10. Transceiver and communications

The communications subsystem of ARaMiS follows the modularity philosophy of the satellite: a basic communication tile is provided as standard, while dedicated tiles are foreseen in case of special applications. The communication 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 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. Both channels use 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. Enabling the reception of ARaMiS telemetry by radio-amateurs around the World makes possible to collect data from orbits unreachable from our Ground Station. The telemetry data packet format for each ARaMiS satellite will be publicly available from the web-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 not directly compatible with amateur stations. External users are not allowed to issue commands to the satellite, and the format of the uplink data packet will not be published. To reduce the probability of false command detection, data are strongly encoded.

The UHF link is based on a TI/Chipcon transceiver, model CC1020. This 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 base band side, to a Power Amplifier (PA) on the transmit side and to a Low Noise Amplifier (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 is the RFMD model RF2175, which provides an output level of +34dBm. This device is very small, provides enough output power with good efficiency and is latch-up free. Depending on the amount of power available for communications, a power module can be cascaded to the PA to attain an output power in excess of 8W.

The processor supervising the UHF link is a TI MSP430. Its functions are essentially:

• to exchange base-band 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, thus it is not necessary to use an external processor as in the UHF subsystem. The CC2510 is not optimized for high power operation: it uses the same pin as the output of the internal PA (output power: 0dBm) and the input of the internal LNA. It is possible to build an external circuit to drive an external PA and get RF signal from an external LNA, but we decided to use two devices, one as receiver, the second as transmitter. The PCB layout is very simple, removing the risk of unwanted coupling between transmit and receive paths.

The amplifier on transmit side includes two devices, a NEC UPC2762 followed by a RFMD RF5189, with an output power about +32dBm. 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 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 -120dBm. An optional power module is available to increase output power to about 7W at the expenses of a much higher power consumption.

Antennas are strongly dependent on the satellite dimension and on the desired bandwidth. Many solutions are possible, but are not taken into consideration here.

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 (for example high resolution or real-time imaging) require a large bandwidth downlink. 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, based on a large FPGA for base-band processing, a high speed dual channel DAC converter with internal digital filtering and over-sampling, a PLL, an I-Q modulator, followed by a PA. The architecture is much more complex than the standard one, but allows 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.

11. Payload

The payload is a mission dependent module that cannot 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 Sec. 9, 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:

• Modularity here intends as 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.

The selected processor is a Leon 2, running on a Xilinx Virtex2 Pro FPGA. The only operating system which has currently been tested is Linux 2.6 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.

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:

1. A peripheral implementing the telemetry bus standard defined in Sec. 8.2 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 telemetry bus. 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.

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.

Additionally, we provide support for video decoders if standard video sources need to be connected to the system. 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) (Mitra et al. 2000) and a voter is used to protect against Single Event Upsets, which 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.

12. Testing

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-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.

On the other hand, since each module contains a micro-controller, automatic test functions (e.g., BIST) can be embedded without any extra hardware, in order to simplify verification of correct satellite operation.

13. Conclusions

The paper presents the design issues of two small satellites, developed with different approaches.

The first one (PiCPoT) was a "custom" design: a unique set of specifications identifies size and functions of the satellite, and the design was developed following these "hard" constraints.

The second one (ARaMiS) rather than a single satellite represents an architecture: a fully modular approach brings to the development of fully reusable units (the "tiles"), which allows to build a variety of small satellites with different size, weight, and functionality. This work is supported by “Regione Piemonte” within the MAESS-2006 project.

Both projects share some common issues, such as

1. emphasis on education: the design teams include students at various levels (master and Ph.D.), and specific units or subsystems are developed within final projects;

2. use of commercial devices (COTS), with proper selection and design choices to achieve the required reliability.